猜想

根据想象产生的几个猜想:
1.etcd集群出现分裂,三个节点分裂成为两个集群。APIServer不会检测各节点集群ID是否一致,因此会出现数据消失现象。
2.Raft日志同步异常,其他节点会不会因为Raft模块存在特殊Bug导致未收到相关日志条目?通过etcd自带的WAL工具来判断,可以显示WAL日志中收到的命令。
3.如果日志同步没问题,有没有可能是Apply模块出现了问题,导致日志条目未被应用到Apply模块？
4.若Apply模块执行了相关日志条目到MVCC模块,MVCC模块的treeIndex子模块会不会出现特殊bug,导致更新失败？
5.若MVCC模块的treeIndex模块无异常,写请求到了boltdb存储模块,有没有可能boltdb出现了极端异常导致数据丢失？

通过使用日志工具来分析日志,出现required revision has been compacted信息,说明APIServer 请求etcd版本号被压缩了。

通过命令:

etcdctl endpoint status --cluster -w json | python -m  json.tool

1.如果节点之间的cluster_id是一致的,就可以排除集群分裂。
2.初步判断集群Raft日志条目同步正常,raftIndex表示Raft日志索引号,raftAppliedIndex表示当前状态机应用的日志索引号。如果差距很小,说明没问题,
如果差距大,说明Raft同步出现异常。
3.观察节点的revision值,相互差距很大,明显偏离标准值,使用WAL工具etcd-dump-logs搜索关键字,例如Hello,如果都能找到,就是Raft日志同步没有异常。
在Apply模块出现问题,但是各节点raftAppliedIndex几乎无差异,Apply流程出现逻辑错误的时候,没有重试机制。Apply流程无论是成功还是失败,都会更新
raftAppliedIndex值。Apply输出的日志:auth:revision in header is old,出现鉴权版本号不一致的问题。
consistent index的未持久化最终导致鉴权命令重复执行。鉴权模块的RoleGrantPermission接口未实现幂等,一连串的bug导致鉴权出现不一致,随后有放大
成MVCC模块的key-value数据不一致,导致严重的数据损坏。