12 | 一致性：为什么基于Raft实现的etcd还会出现数据不一致？
该思维导图由 AI 生成，仅供参考
从消失的 Node 说起
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文以作者唐聪的经历为例，分享了在Kubernetes集群中遇到的etcd数据不一致问题。作者描述了遇到的问题，包括Deployment控制器失效、Node节点消失等诡异现象。经过排查，发现基于Raft实现的etcd出现了数据不一致和数据丢失的情况。在排查过程中，作者提出了多种可能的原因，并逐一验证排除。最终，通过对Apply流程的深入分析和测试，发现数据不一致是由鉴权版本号不一致导致的，而这一问题影响了etcd v3所有版本长达3年之久。作者成功复现并解决了这一Bug，并将解决方案提交给了社区。文章强调了对于分布式系统开发和运维人员的重要性，以及即使是基于Raft实现的强一致存储系统，也可能出现数据不一致的情况。此外，文章还总结了etcd数据不一致的风险和原因，并提出了一些最佳实践，如开启etcd的数据毁坏检测功能、应用层的数据一致性检测、定时数据备份等。总体而言，本文展示了技术问题排查的复杂性，对于从事分布式系统开发和运维的技术人员具有一定的参考价值。文章内容涵盖了作者在Kubernetes集群中遇到的etcd数据不一致问题，以及对应的排查和解决过程，强调了分布式系统开发和运维的重要性，同时提出了一些实用的最佳实践，为读者提供了宝贵的实践总结和技术参考。
《etcd 实战课》，新⼈⾸单¥59
全部留言(7)
- 最新
- 精选
Coder精彩，总体上获得以下收获: 1. 基础篇知识学以致用，问题定位、分析思路 2. 不一致bug原因，复制状态机模式的问题，应用日志条目到状态机时，因etcd里面含有各种业务逻辑，无法保证各个节点都成功 3. 了解几个常见不一致的bug， 这个老师能给下详细的github issue、pr地址，还需要深入消化小才能彻底搞懂 4. 最佳实践干货满满，感受到了老师在这块的丰富经验，我感觉监控key数挺好用的，也简单，数据安全是红线，定时备份太重要了，否则遇到老师说的数据不一致bug，就欲哭无泪了作者回复: 赞，有收获就好，总结到位，地址我给下： https://github.com/etcd-io/etcd/issues/11651 https://github.com/etcd-io/etcd/pull/11613 https://github.com/etcd-io/etcd/issues/11689
2021-02-159
yangf在项目中大量使用了 etcd，这里介绍两个曾经遇到的问题。 1. 使用 etcd watch，在 go watch client 中出现大量内存堆积的问题，一度怀疑是 etcd lib 的问题，深入定位后发现是从 watch channel 中消费速度小于 key 变更速度导致。（在我的个人博客里记录了这个问题：https://amyangfei.me/2020/12/19/best-practice-with-go-etcd/#Consume-data-from-the-watch-response-channel-ASAP ） 2. 使用 etcd lease 的一系列问题，包括 concurrency 包提供的 `session.Done` 通知存在延迟问题，etcd lease 删除 key 也存在的延迟删除问题。（个人博客里还有一篇文章对 lease 的一些实现原理和使用注意点做了分析：https://amyangfei.me/2020/12/27/thinking-about-etcd-lease/） 遇到 etcd 使用问题经常搜索，还见到过唐老师提的 issue/pr :-)作者回复: 赞，优秀，总结得挺好，watch这个案例我觉得可以给社区提个PR，在Watch API增加下说明，lease的实现的确会导致删除key存在延迟，甚至在高负载、磁盘IO异常等情况下会导致old leader也会触发撤销lease操作。
2021-02-1838
春风老师，leader需要法定人数，脑裂在什么情况下发生呢作者回复: 如果出现网络分区故障，旧的leader和集群其他节点出现了网络隔离，其他节点选出了新leader，旧的leader也没有感知到新leader, 这时会出现短暂双leader。如果使用的串行读，那么旧的leader也能提供读取数据，线性读因需要获取集群共识数据，因此是无法读取的，旧的leader也是无法写入的。 严格意义上来说，这种情况不能称之为脑裂，就目前来说，如果不存在任何未知的bug, 基于Raft共识算法实现的etcd, 是可以防止脑裂发生的。
2021-02-2222
shp请问老师，每隔30分钟备份一次，如果需要使用备份恢复数据，那么在备份后到使用备份恢复前这段时间的数据操作是不是会全部丢失，还是有什么方法只恢复损坏的数据？作者回复: 是的，会丢失数据，备份可缩短到3-10分钟一次，etcd 3.5已经支持在learner节点上进行备份，对读写性能不会有任何影响，如果想恢复损害的数据要看具体情况了（比如什么bug触发的、是否某个节点有完整数据、业务client是否有打印写请求日志等），操作起来有不少复杂度，自从我文中所列的几个可能导致不一致bug被修复后，最近一年多社区已经没有报任何不一致的问题啦，如果担心不一致，可升级到3.4较新版本。
2021-08-021
写点啥呢请教唐老师，04节内容中介绍etcd写请求流程中涉及到多个log，不稳定raft log->wal -> 稳定raft log，能不能请老师进一步介绍下这三个日志的用处和关系呢？特别是在涉及到节点崩溃数据恢复时候这几个日志是如何配合恢复数据的？ 谢谢老师作者回复: 好的，等我忙完专栏目录计划的内容，答疑篇预计会增加一篇etcd启动后发生了什么，可以在这篇里面，增加相关内容，稍等哈
2021-02-151
Tachoneapply 失败为啥不强制设置raft状态机为error呢，拒绝写入，这样应该是最安全的，不会出现数据不一致了还在写入2023-11-29归属地：北京
yybear获取各个节点的 revision 和 boltdb hash 值，若出现 Follower 节点的 revision 大于 Leader 等异常情况时，就可以认为不一致 --------------------------------- revision 是apply时递增的，如果follower的apply处理速度大于Leader 的速度，是存在Follower 节点的 revision 大于 Leader的情况吧？2021-10-08
