原因：
部分节点数据主副本不一致导致。
已知触发原因包括断电，OS重启，数据库服务宕机(包括BUG)或重启，网络断开或操作timeout，CPU或磁盘太繁忙导致timeout等。
解决：
如节点离线，或者服务为CLOSE,先将节点的服务恢复。
如服务已经恢复，数据库会自动进行同步，具体过程可以查看后面的排查过程
排查样例：
查看不一致的信息
gcadmin showdmlevent
比如
可以看到有1个不一致的情况，是testdb.t1表，处于10.0.2.102的n1分片。
而根据上面的信息，【当前是因为集群服务离线了】，要先解决服务问题。具体请根据实际故障情况解决。
然后我们去10.0.2.102节点，查看数据自动同步的情况。需要转到gnode节点目录，比如 /opt/gbase/gnode/log/gbase/
可以看到比较新的syncclient开头的，包含testdb_t1_n1字样的日志文件
我看看一下文件内容
注意最末尾的
Sync Table vcname000001.testdb.t1_n1 Success
字样(V8版本没有vcname000001字样,这是V9虚拟集群才有的)，表示本次同步是成功的，也就是不一致的状态，应该恢复了。查看集群状态
已经恢复。
如果日志显示恢复失败，需要查看这部分日志的报错部分，是什么原因导致无法自动恢复的。排除硬件和操作系统故障，比如文件损坏，空间慢，目录权限不对等情况，大部分是数据库产品bug。
还有一种情况，如果这个表是一个频繁加载的表，在恢复过程中，又有新数据入库，则虽然本次同步成功了，但再次检查时，还是发现数据不一致，也就造成了这张表，会一直在同步，且每次都成功，但就是【追不上】。
可以强行停了这个表的加载一段时间，等同步完成且不一致标志消失后，再恢复加载或变动。
也可以参考
GBase数据库同步强制锁表的参数
在集群层的日志里，可以看到恢复的记录(gcrecover_taskrecord.log)和调度过程(gc_recovery.log)。注意如果有多个管理节点，恢复记录会出现在任何一台上面。
如上可以看到，eventid=4，目标testdb.t1, n1分片的同步。在在2020-07-07 08:50:12.256完成。
在gc_recovery.log里有整个调度过程
其中第一行表名调度的是eventId=4
请注意其中session:8字样，如果有多个同步一起调度，日志是混在一起的，可以通过这个特征字符串来过滤日志，确保看到的是一个调度session的过程。
如果dmlevent 和 dmlstorageevent处理失败，会继续处理后面的eventid, 但对于ddlevent, 则会一直处理eventid最小的那个。
如果一张表记录了多个eventID, 会先做最小的那个，后面的event在处理时，会被忽略掉，因为有更小的event要处理。
