高可用 FAQ

本文档介绍 YMatrix 5.X 高可用的常见问题。

高可用相关文档请见：
- YMatrix 架构
- 故障恢复

1 etcd 是部署在每台主机上吗？

etcd 的存储可以理解为全复制表，因此节点数量不必太多。在实践层面，推荐的配置为 1、3、5、7 节点，安装部署过程会自动根据主机数量选定部署几个 etcd 实例。
因此如果集群里的主机个数是偶数，或者超过 7 台主机，那么有些机器上是没有 etcd 节点的。可以通过 ps 命令查看当前主机上有没有 etcd 进程。
通常 Master 和 Standby 的主机上会优先安放 etcd 节点。

2 为什么 etcd 集群的成员数量需要为奇数？

在 etcd 中，将节点数设置为奇数个是为了确保选举过程的稳定性和一致性，在 Raft 协议中，leader 的选举是基于大多数原则。当节点数为奇数时，选举过程更容易达成共识。在这种情况下，半数以上的节点需要同意并投票支持一个 candidate 成为 leader。假设有 5 个节点，需要至少 3 个节点同意选举同一个 leader；如果有 7 个节点，则需要至少 4 个节点同意。

这种配置除了确保 leader 的选举结果是唯一的，还能尽量保证选举时间的精短。另外奇数个节点还能提供更好的容错能力。在发生故障或网络异常的情况下，多数个节点仍然可以保持选举过程的正常运行，确保系统的可用性和一致性。当节点数为偶数时，可能会出现平局的情况，导致选举无法完成或结果不确定。

3 日常我们需要针对 etcd 做哪些运维操作？

首先，需要部署针对 etcd 的监控。目前支持 Prometheus 5.0 部署 etcd 的监控(Prometheus + Grafana)。

4 etcd 的数据量有多大？是否需要特别的运维工作？

5.X 的 etcd 会定期自动进行清理操作，因此数据目录和内存大小都能维持在一个相对固定的范围。
但是如果有节点故障和后续 recover 操作，会使 etcd 的数据在短时间内发生稍许膨胀。只要 etcd 的数据目录不持续膨胀超过 1.5GB，都是正常的，建议通过监控进行监视和定期检查。

5 引入 etcd 后，图形化界面部署数据库集群操作有哪些变化？

从使用体验上并没有变化，安装部署的页面和操作方法跟以前完全一致。

6 5.X 号称实现了 Master Auto-failover，为什么 Master 关机并切换后，再开机 Master 不会自动恢复？

这里存在一个概念误区，一个 Segment 有两个维度的概念：

一个维度是角色：Primary 或 Mirror
一个维度是状态：Up 或 Down

当前版本下，Master Auto-failover 功能指的是节点角色的自动切换，即 Master 离线之后，Standby 能自动切换为 Master，这个动作称为提升（Promote）或者故障自动转移（Failover）。
而一旦一个 Segment 的状态从 Up 变成 Down，是必须通过手动节点恢复操作（mxrecover）才能变回 Up。

7 Master 发生自动切换的延迟是多久？

当 Master 的 postmaster 进程发生崩溃，但主机和网络都正常，Master 可以快速切换到 Standby。
当 Master 主机发生断电、网络隔离等现象，其自动切换会根据参数的配置延迟重试一段时间。

8 当半数以上的 etcd 进程异常（被杀死或无法启动）后，集群出现宕机，是正常现象吗？

是的。

postgres 进程的存活需要依赖 etcd 集群的租约存续。当 etcd 服务本身出现异常（半数以上的 etcd 节点宕机或失联），postgres 进程就无法维持存活，宕机是必然的结果。因此，请严格部署 etcd 监控，密切关注其健康状态。监控事项包括但不限于：磁盘剩余空间、磁盘 I/O、网络联通性、宿主进程 supervisor 的存活等。