升级至 etcd v3.6 时避免僵尸集群成员

本文是近期发布于官方 etcd 博客的原版文章的镜像。关键要点是什么？在升级至 v3.6 之前，请务必先升级至 etcd v3.5.26 或更高版本。这将确保您的集群被自动修复，并避免僵尸成员的出现。

问题概述

近期，etcd 社区解决了一个在用户从 v3.5 升级至 v3.6 时可能出现的问题。该缺陷可能导致集群报告“僵尸成员”，即一些此前已从数据库集群中移除的 etcd 节点重新出现并加入数据库共识。在移除这些僵尸成员之前，etcd 集群将无法正常运行。

在 etcd v3.5 及更早版本中，尽管 v3store 已存在，但成员数据的权威来源仍是 v2store。作为我们 v2store 弃用计划的一部分，在 v3.6 中，v3store 成为集群成员关系的权威来源。通过一份错误报告我们发现，在某些较旧的集群中，v2store 和 v3store 可能会变得不一致。这种不一致在升级后会表现为：已被移除的旧“僵尸”集群成员在集群中重新出现。

修复方案与升级路径

我们在 etcd v3.5.26 中引入了一种机制，可自动从 v2store 同步数据至 v3store，确保受影响的集群在升级至 3.6.x 之前得到修复。

为支持当前大量正在升级至 3.6 的用户，我们提供了以下安全升级路径：

1. 将您的集群升级至 v3.5.26 或更高版本。
2. 等待并确认更新后所有成员均处于健康状态。
3. 升级至 v3.6。

对于因某些障碍无法更新至 v3.5.26 的用户，我们无法提供安全的替代路径。因此，如果您的软件包源或供应商尚未提供 v3.5.26，请推迟升级至 v3.6，直至可以获取该版本。

更多技术细节

以下信息仅供参考。用户无需了解以下细节即可遵循安全的升级路径。

该问题出现在生产环境中运行于 etcd v3.5.25 或更早版本的集群中。这是向集群添加或移除成员，或从故障中恢复集群时产生的副作用。这意味着 etcd 集群运行时间越长，出现此问题的可能性越大，但无论集群新旧，任何用户均无法完全排除该风险。

etcd 维护者与问题报告方协作，根据问题症状及对 etcd 代码和日志的分析，确定了该问题的三种可能触发因素：

1. etcdctl snapshot restore 中的缺陷（v3.4 及更早版本）：使用 etcdctl snapshot restore 恢复快照时，etcdctl 本应在添加新成员前移除现有成员。但在 v3.4 中，由于存在缺陷，旧成员未被移除，从而产生了僵尸成员。请参阅 etcdctl 上的相关评论。
2. --force-new-cluster 在 v3.5 及更早版本中：在极少数情况下，强制创建新的单成员集群未能完全移除旧成员，导致留下僵尸成员。该问题已在 v3.5.22 中修复。有关详细技术信息，请参阅 Raft 项目中的此 PR。
3. 启用 --unsafe-no-sync：若启用 --unsafe-no-sync，在极少数情况下，etcd 可能会将成员变更持久化至 v3store，但在写入 WAL 前发生崩溃，从而导致 v2store 与 v3store 不一致。这对单成员集群构成问题。对于多成员集群，从崩溃节点的数据强制创建新的单成员集群可能会导致僵尸成员。

重要的是，可能还存在其他导致 v2store 与 v3store 成员数据不一致的触发因素，我们尚未发现。这意味着，即使您未执行上述任何操作，也不能认为系统绝对安全。一旦用户升级至 etcd v3.6，v3store 将成为成员数据的唯一来源，且不再可能发生进一步的不一致。

希望验证 v2store 与 v3store 一致性的高级用户，可按照此评论中描述的步骤进行操作。此检查并非修复该问题的必要步骤，且无论检查结果如何，SIG etcd 均不建议跳过 v3.5.26 版本更新。

关键要点

在迁移至 v3.6 之前，请务必先升级至 v3.5.26 或更高版本。这将确保您的集群自动修复，并避免产生僵尸成员。

致谢

我们感谢 Christian Baumann 报告了这一长期存在的升级问题。他的报告及后续跟进工作帮助我们注意到了该问题，使我们得以向上游进行调查并解决。

• ← 上一篇
• 下一篇 →