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), 这个分片的数据将丢失,建议和用户协商。