背景介绍：在xxx项目（项目使用集群版本为953）中处理数据查询业务时，偶然发生主备数据不一致导致表不能访问，经过手动处理方法解决，现在把处理思路和过程介绍一下，供大家参考。
一、问题报错如下：
1.针对以上问题，现梳理下解决思路：
1>查看集群event信息锁定该表的不一致类别。
2>查看不一致表的node分片进行分析。
3>revert问题分片的表信息。
二、具体操作如下：
这种情况下gcadmin信息展示集群信息肯定会存在state为1，且gcadmin showddlevent，gcadmin showdmlevent或者gcadmin showdmlstorageevent三条命令
来判断是否是元数据信息不一致，还是单纯的数据信息不一致。经过判别此问题不包含ddl信息不一致，只是单纯的数据信息不一致。
1.按照提示命令查看相关信息：
集群采取1分片1备份部署，集群存储两份数据，主备两份数据不一致，考虑集群无法认为哪份数据是正确的进行自动恢复，需人工干预帮助判别进行恢复。
2.查看下主备分片分别存在节点，gcadmin showdistribution 查看 n25，n26所在实例ip
考虑从两个角度判别哪个分片是正确的：
a)表的条数。
分别针对n25主备分片上的该数据表条数进行统计，正常情况下主备分片上两份表的条数应该一致。
发现上面主备分片条数不一致，确实存在问题。
b)node层表分片的scn号。
了解数据库的人都知道，一般情况下scn大的可能是错误(scn号是单调递增的，一般情况下scn号小的是正确的)。
下面先针对n25分片进行手动恢复，n26分片解决思路和你n25一样即可。
分别针对n25主备分片上的该数据表scn号进行统计，正常情况下主备分片上两份表scn也应该一致。
以上查询完成后进行判别解决(可参考其他node层信息表的scn进行判别) 发现172.19.54.25 节点上该表的scn号大于172.19.54.73上该表的scn号。
三、解决问题
1.需要将172.19.54.25分片上改变进行revert处理。之后将node层表进行刷新即可。
将n26分片进行如上操作即可，该表就可以访问了。后续将集群event清空即可。
