背景介绍:在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清空即可。