上周六参加了PostgreSQL社区在成都举办的交流会,这事放在后面将。
然后感觉这周就在疯狂的割接中,一共5次,全都跟IPv6有关,一大堆问题。
本期就对这些问题进行分享
技术向,知道写了些啥。
首先针对两套一体机,X8M-2(19.13)、X9M-2(19.16)完成了IPv6改造,非常成功,具体操作步骤详见上一期(有坑,后面小节会讲)。
我手上基于X86服务器的12.2四节点RAC集群,改IPv6失败了,也不能说是完全失败吧,配置了子网掩码为120的IPv6地址之后,集群能正常启动IPv6的VIP和SCANIP。但是外部访问不能通过IPv6的SCANIP来访问数据库,只能通过VIP。在尝试修改各实例的local_listener和集群的remote_listener参数后仍然无法通过IPv6的SCANIP访问数据库。
在尝试relocate SCAN的时候,发现原来承载SCANIP的节点,对应SCAN资源一直显示CLEANING状态,IPv6地址一直保持在这个节点上,只能尝试重启该节点,期间hang了很久,在重启完成后SCANIP才到了另一个节点起起来。
然而发现了另一个问题,漂移走的VIP并没有回到该有的节点,在尝试重新启动这个节点VIP的时候,等待了很久报错了:
srvctl start vip -node xxxx2
PRCR-1079 : Failed to start resource ora.xxxx2.vip
CRS-2680: Clean of 'ora.xxxx2.vip' on 'xxxx3' failed <<<< here
CRS-5804: Communication error with agent process
这个情况下,虽然节点2的数据库实例起起来了,但是VIP没有正确启动,相当于节点仅有3个节点运行,紧急调整了各个PDB的service应急跑着,立马开SR反馈问题。
同时在节点3的crsd_orarootagent_root.trc文件中还发现以下问题:
2022-10-27 02:07:43.611 :CLSDYNAM:765589248: [ora.xxxx2.vip]{0:13:2} [clean] VipActions::stopIpV6 {
2022-10-27 02:07:43.611 :CLSDYNAM:765589248: [ora.xxxx2.vip]{0:13:2} [clean] Deleting ipv6 address '2409:8062:5a10:300::c07', on the interface name 'bondeth0'
2022-10-27 02:07:43.611 :CLSDYNAM:765589248: [ora.xxxx2.vip]{0:13:2} [clean] sclsideladdrsv6 returned
2022-10-27 02:07:43.611 :CLSDYNAM:765589248: [ora.xxxx2.vip]{0:13:2} [clean] Failed to delete 2409:8062:5a10:300::c07 on bondeth0
2022-10-27 02:07:43.611 :CLSDYNAM:765589248: [ora.xxxx.vip]{0:13:2} [clean] (null) category: -2, operation: ioctl, loc: SIOCDIFADDR, OS error: 99, other: failed to delete address
2022-10-27 02:07:43.611 :CLSDYNAM:765589248: [ora.xxxx2.vip]{0:13:2} [clean] VipActions::stopIpV6 }
根据上面trc文件中category: -2, operation: ioctl, loc: SIOCDIFADDR, OS error: 99, other: failed to delete address的内容,匹配到一个 Bug 32128969 - Unable to Stop VIP after Modified IP from IPv4 to IPv6 (Doc ID 32128969.8)。具体意思就是在19.11之前,使用子网掩码为非64的IPv6地址时,集群无法关闭VIP及SCANIP。
而我们环境分配的IPv6地址的子网掩码正好是120,且无法分配子网掩码为64的IPv6地址,因此出现了这次IPv6改造的问题。
而针对19.11之前版本的one-off patch也仅在以下版本中有对应补丁:
Version |
---|
12.2.0.1.190115 |
12.2.0.1.190416 |
19.6.0.0.0 |
19.7.0.0.0 |
19.10.0.0.0 |
而我这套数据库的版本则是12.2.0.1.211019,没有相关补丁解决问题。
PS.根据小道消息,据说是某位开发把集群操作IPv6地址的代码写死为子网掩码64。
既然我当前的环境不支持120位掩码的IPv6地址,而且当前集群运行状态也是不正常的,跟后台小哥沟通过后,只能将集群回滚到IPv4单栈运行状态。由于都没做过只能先停数据库在执行下面的命令:
srvctl modify network -netnum 1 -iptype IPV4
本来以为会出现hang住,要通过重启网卡的方式卸载掉IPv6地址,但是没想到集群直接不管已经生效的IPv6地址,只操作IPv4地址了。
尝试启动节点2的VIP也能正常漂移会节点2了,重新启动数据库,修改各实例的local_listener。一切恢复正常。
已经生效的IPv6地址还会在网卡上,但是已经不会影响集群运行了。
但是IPv6是必须的,现在就只有两条路可走:1.将PDB迁移至X9M-2去;2.网络环境支持分配子网掩码为64的IPv6地址。
就目前而言,计划是针对紧急业务,迁移到X9M-2去。
又是两天加班。
眼袋已经彻底黑了,还有两天加班。哎,先这样吧。
老规矩,知道写了些啥。