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