南大通用GBase 8s双主故障分析处理案例.pdf

高燕崧

433

2页

4次

2021-02-24

免费下载

南大通用 GBase 8s 双主故障分析处理案例

GBase 8s 数据库使用 SSC 两个节点和两个 CM，数据库主节点状态异常发生切换，备节点

在接管主服务之后未能成功将原主节点剔除，造成了双主现象，即两节点都存在写操作造

成了数据库索引页以及 CHUNK 的 freelist 页的损坏。应用的直接表现是：

⚫ 表 sg_power_20180625，sg_power_20180626 无法创建，提示表已存在，但 dbschema

或是 systables 表中无相关记录。

⚫ 查询部分表时提示 AF 报错。

⚫ 对表执行 select count(*) from table 和 select count(*) from table where 1=1，两条的

SQL 结果不一致。

解决方法：SSC 环境下的双主对数据库来说是灾难性的，后果是难以预知的。一般来说双主

且双写的时间越长，恢复难度越大，最终的方式只能依靠整库重建甚至整实例重建。

⚫ online 日志分析

两个 SSC 节点时间相差 3 分钟，主节点与 CM1 和 CM2 失联之后，CM1 将备节点提升

为主节点接管服务，但切换过程中，主节点已将备节点剔除，导致备节点在成功接管主服务

后发出的 BldNotification 消息（将原主从集群中剔除的指令），原主无法响应。最终出现了

双主。在切换发生前已连接在主节点的连接在网络或其他故障恢复后，连接继续恢复工作，

出现两节点双写的现象，导致了数据库内部系统页的损坏。

⚫ 故障检查和恢复

集群恢复：采用 onclean 方式将两边数据库关闭，选择一个节点单独启动：

onclean –ky;

oninit –v –SDS=zj_db_db4;

检查 DBspace extend：采用 oncheck 命令逐个检查表空间，根据提示的报错信息，对相关

表重建处理。若是

oncheck –ce dbspace 名

检查库的 catalog：对所有的 DB 检查系统表信息，系统表有损坏，只能通过重建库修复

oncheck –cc 库名

检查表的 data page 和 index page：对所有的 db 逐个检查，根据提示的报错信息，对表

和索引进行重建

oncheck –cDI dbname

⚫ 处理

表 sg_power_20180625，sg_power_20180626 无法创建，提示表已存在，但 dbschema 或

是 systables 等系统表中无相关记录。现场采用 onheck –pp 检查后发现系因为 systables

的索引页中存表名为 sg_power_20180625 和 sg_power_20180626 信息，所以导致了表无

法创建的现象。系统表或系统表的索引损坏最好的修复方式只能是整库重建；

当应用对表 dv_dailystat_rtnet_ems' 进行扫描时，online 日志中频繁出现 AF 报错，通过

oncheck –ce 检查可发现该表的 data page 已经被其他其他表的 page 所覆盖，所以导致

该表的大部分扫描操作都会出现上述 AF 错误。该库的 free list page 已经发生混乱，很容

易出现表 A 的 page 与表 B 的 page 发生重叠的现象。处理方式仍然是整库重建并将该

库建到其他正常的 dbspace 内。已发生重叠的表一定会出现数据丢失的情况无法避免也无

法恢复。在对该表数据进行导出时可以通过 rowid 或者 rownum 逐行尝试的方式，可以尽

可能多的导出未受影响的数据。通过 oncheck –cDI 检查如果发现表的索引页损坏，将索引

删除重建即可恢复正常。