数据库管理-第四十一期 一堆问题（20221029）

第四十一期 一堆问题

上周六参加了PostgreSQL社区在成都举办的交流会，这事放在后面将。
然后感觉这周就在疯狂的割接中，一共5次，全都跟IPv6有关，一大堆问题。
本期就对这些问题进行分享
技术向，知道写了些啥。

1 成功了啥？

首先针对两套一体机，X8M-2（19.13）、X9M-2（19.16）完成了IPv6改造，非常成功，具体操作步骤详见上一期（有坑，后面小节会讲）。

2 失败了啥？

我手上基于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 }

3 发生了啥？

根据上面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。

4 咋个处理？

既然我当前的环境不支持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去。
又是两天加班。

总结

眼袋已经彻底黑了，还有两天加班。哎，先这样吧。
老规矩，知道写了些啥。