理解失败

在机器的大量部署中失败是很常见的。当硬件或者软件故障时单台机器失败。当电力故障或者网络问题时多台机器一起失败。多种失败也可能一起发生;几乎不可能列举出所有可能的失败场景。

在这节中，我们分类失败的种类并讨论 etcd 是如何设计来容忍这些失败的。大部分用户，不是所有，可以映射一个特别的失败到一种失败。为了应对罕见或者 , 总是 备份 etcd 集群。

当少于一半的跟随者失败时， etcd 集群依然可以接收请求并让程序没有任何大的中断。例如，两个跟随者失败将不会影响一个五个成员的 etcd 集群运作。但是，客户端将失去到失败成员的连通性。对于读请求客户端类库应该通过自动重新连接到其他成员来对用户隐藏这些中断。运维人员应该预期其他成员上的系统负载会因为重新连接而提升。

当 leader 失败时， etcd 集群自动选举一个新的 leader 。选举不会在 leader 失败之后立即发生。大约需要一个选举超时的时间来选举新的 leader ，因为失败选取模型是基于超时的。

已经发送给旧有 leader 但是还没有提交的写请求可能会丢失。新的 leader 有能力重新写入从之前 leader 而来的任何未提交的条目。从用户的角度，在新的 leader 选举之后某些写请求可能超时。无论如何，已提交的请求从来不会丢失。

新的 leader 自动延长所有的租约(lease)。这个机制保证足浴将不会在准许的 TTL 之前过期，即使它是被旧有的 leader 准许。

当集群的大多数成员失败时，etcd 集群失败并无法接收更多写请求。

etcd 集群仅在成员的大多数可用时可以从多数失败中恢复。如果成员的大多数无法回来上线，那么运维必须启动 来恢复集群。

网络分区类似少数跟随者失败或者 leader 失败。网络分区将 etcd 集群分成两个部分; 一个有多数成员而另外一个有少数成员。多数这边变成可用集群而少数这边不可用。在 etcd 中没有 “脑裂”。

如果 leader 在多数这边，那么从多数这边的角度看失败是一个少数跟随者失败。如果 leader 在少数这边，那么它是 leader 失败。在少数这边的 leader 辞职(step down)然后多数那边选举新的 leader。

一旦网络分区清除，少数这边自动承认来自多数这边的 leader 并恢复状态。

集群启动时仅仅当所有要求的成员都成功启动才视为成功。如果在启动期间发生任何失败，在所有成员上删除数据目录并用新的集群记号(cluster-token)或者新的发现记号(discovery token)重新启动集群。