【ETCD】【实操篇（四）】etcd常见问题快问快答FAQ

原文：https://etcd.io/docs/v3.5/faq/

客户端必须发送请求到 etcd 领导者吗？
Raft 是基于领导者的；领导者处理所有需要集群共识的客户端请求。然而，客户端不需要知道哪个节点是领导者。任何需要共识的请求发送到跟随者时，都会自动转发到领导者。那些不需要共识的请求（例如序列化读取）可以由集群中的任何成员处理。

配置相关

listen-<client,peer>-urls、advertise-client-urls 或 initial-advertise-peer-urls 之间有什么区别？

listen-client-urls 和 listen-peer-urls 指定 etcd 服务器绑定的本地地址，用于接受传入连接。若要监听所有接口上的端口，请指定 0.0.0.0 作为监听的 IP 地址。
advertise-client-urls 和 initial-advertise-peer-urls 指定 etcd 客户端或其他 etcd 成员应使用的地址来联系 etcd 服务器。广播地址必须可以从远程机器访问。不要在生产环境中使用 localhost 或 0.0.0.0 作为广告地址，因为这些地址无法从远程机器访问。

为什么更改 --listen-peer-urls 或 --initial-advertise-peer-urls 不会更新 etcdctl member list 中的广告 peer URLs？
成员的advertise peer URLs 来自于集群启动时的 --initial-advertise-peer-urls。在启动后更改监听的 peer URLs 或初始的advertisepeer 地址不会影响已导出的advertise peer URLs，因为更改必须通过仲裁（quorum）以避免成员配置的分裂。可以使用 etcdctl member update 来更新成员的 peer URLs。

部署相关

系统要求
由于 etcd 会将数据写入磁盘，因此其性能高度依赖磁盘性能。建议使用 SSD。可以通过工具（如 fio）进行磁盘性能基准测试来评估磁盘是否足够快。为了防止性能下降或意外地过载键值存储，etcd 强制使用配置的存储大小配额，默认值为 2GB。为了避免交换或内存不足，机器应该至少拥有足够的内存来覆盖配额。建议在正常环境下使用 8GB 内存，并且如果配置的值超过 8GB，etcd 会在启动时发出警告。

为什么集群成员数量必须是奇数？
etcd 集群需要多数节点来达成共识（即仲裁）。对于具有 n 个成员的集群，仲裁要求 (n/2)+1 个成员同意。对于奇数大小的集群，添加一个节点总是会增加达成共识所需的节点数。虽然增加一个节点可以让集群拥有更多的机器，但故障容忍度可能会变差，因为可以失败的节点数增多，可能会导致集群无法恢复。如果集群无法容忍更多故障，在移除节点之前添加新节点是危险的，因为如果新节点未能成功注册集群（例如地址配置错误），则会永久丧失仲裁。

最大集群大小是多少？
理论上没有硬性限制。然而，etcd 集群应该最好不超过七个节点。Google 的 Chubby 锁服务类似于 etcd，在 Google 内广泛部署多年，建议使用五个节点。一个五成员的 etcd 集群可以容忍两个成员的失败，这对于大多数情况来说足够了。虽然更大的集群可以提供更好的故障容忍度，但写入性能会因为数据必须在更多的机器之间复制而下降。

etcd 在跨区域或跨数据中心部署中是否有效？
跨区域部署 etcd 可以提高其故障容忍度，因为成员处于不同的故障域中。缺点是跨越数据中心的共识请求延迟较高。由于 etcd 依赖于成员的仲裁来达成共识，跨数据中心的延迟可能会比较明显，因为至少大多数集群成员必须响应共识请求。此外，集群数据必须在所有对等节点之间复制，因此也会有带宽成本。

操作相关

如何备份 etcd 集群？
etcdctl 提供了一个 snapshot 命令来创建备份。更多细节可以参考备份文档。

在移除不健康的成员之前，我应该添加一个新成员吗？
当替换 etcd 节点时，重要的是先移除成员，然后再添加替换节点。

etcd 使用基于仲裁模型的分布式共识；(n/2)+1 个成员（即多数）必须同意提案才能提交到集群。这些提案包括键值更新和成员更改。这个模型完全避免了脑裂不一致的可能性。然而，永久性丧失仲裁会导致灾难性的后果。

性能相关

如何基准测试 etcd？
可以尝试使用基准测试工具。当前的基准测试结果可以进行比较。

etcd 警告“apply entries took too long”是什么意思？
在大多数 etcd 成员同意提交请求后，每个 etcd 服务器将请求应用到其数据存储并将结果持久化到磁盘。即使使用慢速机械硬盘或虚拟化网络磁盘（例如 Amazon EBS 或 Google 的 PD），应用请求的时间应该通常少于 50 毫秒。如果平均应用时长超过 100 毫秒，etcd 将警告“应用条目花费的时间太长”。

这个问题通常是由于磁盘慢导致的。磁盘可能正在经历 etdc 和其他应用程序之间的竞争，或者磁盘本身就很慢。通过监控 backend_commit_duration_seconds（p99 持续时间应少于 25 毫秒），可以确认磁盘是否足够快。如果磁盘太慢，为 etcd 分配一个专用磁盘或使用更快的磁盘通常可以解决问题。

etcd 警告“failed to send out heartbeat on time”是什么意思？
etcd 使用基于领导者的共识协议来保持数据复制和日志执行一致。集群成员选举出一个领导者，其他成员成为跟随者。选举出的领导者必须定期发送心跳信号给跟随者，以维持其领导地位。如果领导者未能按时发送心跳，跟随者将触发选举。通常，心跳超时会由慢速磁盘或 CPU 饥饿引起。如果磁盘较慢，可以使用工具（如 fio）进行基准测试来确认磁盘性能是否足够。如果 CPU 使用率过高，考虑将 etcd 移动到专用的机器上，增加进程资源隔离。

其他问题

etcd 警告“mvcc: database space exceeded”是什么意思？
etcd 的多版本并发控制（MVCC）数据模型会保存键空间的历史记录。如果不定期压缩这些历史记录（例如，设置 --auto-compaction），etcd 最终会耗尽存储空间。若 etcd 存储空间不足，它会触发配额警告以保护集群不被进一步写入。