# 理解失败

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

在这节中，我们分类失败的种类并讨论 etcd 是如何设计来容忍这些失败的。大部分用户，不是所有，可以映射一个特别的失败到一种失败。为了应对罕见或者 \[不可恢复的失败]\[unrecoverable], 总是 [备份](https://doczhcn.gitbook.io/etcd/index/maintenance#snapshot-backup) etcd 集群。

## 少数跟随者失败

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

## Leader 失败

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

在 leader 选举的期间， 集群不能处理任何写。在选举期间发送的写请求将排队等待处理知道新的 leader 被选举出来。

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

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

## 多数失败

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

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

一旦成员的大多数可以工作， etcd 集群自动选举新的 leader 并返回到健康状态。新的 leader 自动延长是所有租约的超时时间。这个机器确保没有租约因为服务器端不可访问而过期。

## 网络分区

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

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

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

## 启动期间失败

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

当然，可以像恢复运行中的集群那样恢复失败的启动集群。但是，它大多数情况下总是比启动一个新的花费更多时间和资源来恢复集群，因为没有任何数据要恢复。

\[unrecoverable]: recovery.md#disaster-recovery


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://doczhcn.gitbook.io/etcd/index/index-1/failures.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.