南大通用GBase 8a集群文件系统故障后判断主备是否一致的方法和恢复处理建议

GBase 8a是通过副本来确保高可用,当某部分数据(分片)所在节点故障时,由副本节点继续提供服务。但如果发生一些意外故障,比如服务器断电,导致文件系统故障,出现过文件丢失,目录变文件等问题,此时主备分片是否一致?如果不一致如何处理?本文介绍此类问题的一个排查和处理方案。

另外,如果损坏严重,故障表很多,预计修复耗时太长,建议设置为unavaliable, 做节点替换。 如果主备分片都故障了,那这个表将丢失这部分数据。

参考

GBase 8a发生主副本都损坏状态为1的几种原因
GBase 8a手工设置表某个分片为故障状态的方法
GBase 8a集群表重建方法
GBase 8a查看和修改表的拥有者UID

故障现象

如下现象可能同时发生,也可能只有几种,取决于文件系统损坏的程度。其中常见的是文件丢失,文件类型变动,会造成数据建出现各种奇怪的报错。

集群无event

因为GBase 8a是直写数据到磁盘的,不使用操作系统缓冲,且操作系统返回成功后才做后续处理。而文件系统导致数据文件错误,并不会通知GBase,也就没有evnet。

查询时报错

报错类别包括:表不存在,分片表不存在,分片表文件损坏

DML操作时报错

报错类别包括:分片表不存在,分片表文件损坏,主备分片元数据不一致,主备分片数据不一致。

排查方法

排查调度节点

在每个调度节点通过gccli执行

select count(*) from gbase.table_distribution

如果行数不同,则需要对比差别,将有问题的节点的设置为不一致状态,等集群自动同步。

也可以在正常节点执行表【重建】

select * from gbase.table_distribution order by dbname,tbname

排查数据节点主备分片表元数据

表结构是否可用并且相同

在每个计算节点查看表的每个分片的主副本是否一直,包括分片表是否存在,表结构是否一致。

注意用gncli连接

show full create table dbname.tbname

主备分片必须完全一样,包括后见的UID, TID等。 参考 GBase 8a查看和修改表的拥有者UID

如果行数不一致,要判断哪个备份是准确的,如人工无法确定,可以考虑保留行数多的。

SCN和行数是否一致

查询每个分片的SCN和行数,并和副本比对。 注意用gncli连接

 select table_rows,scn,table_id from information_schema.tables where table_schema='dbname' and table_name='tbname'

排查数据节点主备分片表数据

可以通过查询这个表,并对比结果是否一致来判断

select * from dbname.tbname where rowid%65536=0

如果某个分片查询报错,则判断故障,设置event, 让集群自动同步。

处理方案

手工重建

如果集群层还能查询,且结果正确,可以通过重建该表。 该方法适合快速处理重要的,且重建时间可接受表,因为全面的排查都是需要时间的,特别是数据排查要扫描这个分片表。

设置不一致标志

将查询到的有问题的表,设置不一致标志,由GBase的同步机制自动完成恢复。 被设置标志的表分片不会再参与后续SQL,直到修复完成。

清空分片表

如果主副本都丢失或者坏了,为了其它分片还能继续查询,可以清空故障的分片(truncate table), 这个分片的数据将丢失,建议和用户协商。