TiDB 三中心"脑裂"场景探讨

作者： Kassadar 原文来源：https://tidb.net/blog/07b42ec0

TiDB 以其卓越的高可用性而闻名。然而，在跨多个数据中心进行部署时，数据中心之间的特殊网络拓扑可能带来额外的可用性挑战。让我们详细分析在多数据中心部署环境中，特定的网络拓扑是如何对系统的整体可用性产生影响的。

部署架构简述：

场景一

第一阶段：A 机房和 C 机房间网络断开（半断开 C）

预期情况：A、B 机房均可提供完整的服务

说明：读写由 A、B 机房同时提供，C 机房不提供服务，A 机房和 C 机房之间网络断开后：

因此 A、B 机房均可提供完整的服务

第二阶段：在 1 的基础上增加 B 机房和 C 机房间网络断开（完全断开 C）。

预期情况：A、B 机房均可提供完整的服务

说明：读写由 A、B 机房同时提供，C 机房被完全隔离：

因此 A、B 机房均可提供完整的服务

第一阶段：调整 C 机房可承载 Region Leader ；A 机房和 C 机房间网络断开（半断开 C）

预期情况： A 机房不可提供完整的服务，B 机房可提供完整的服务

说明：读写由 A、B、C 机房同时提供， A 机房到 C 机房网络断开后：

因此，B 机房可提供完整的服务；A 机房无法提供完整的服务，其访问 B 时正常，而其访问 C 时会报错。

第二阶段：B 机房和 C 机房间网络断开（完全断开 C）

预期情况：A、B 机房均可提供完整的服务

说明：读写由 A、B、C 机房同时提供，C 被完全隔离

因此 A、B 机房均可提供完整的服务

第一阶段：A 机房和 B 机房间网络断开（半断开 B）

预期情况： A、B 机房都不可以提供完整的服务

说明：读写由 A、B 机房同时提供， A 机房到 B 机房网络断开后：

因此， A、B 机房都不可以提供完整的服务，仅可能提供 Region Leader 位于自身时的数据服务

第二阶段：B 机房和 C 机房间网络断开（完全断开 B）。

预期情况： A 机房可以提供完整的服务，B 机房无法提供服务

说明：读写由 A、B 机房同时提供，B 机房被完全隔离

因此， A 机房可以提供完整的服务，B 机房无法提供服务

需要注意的是：B 机房历经从半断开到完全断开

在半断开时：A、B 机房都无法访问对方的数据，但可能能读写自己的数据（取决于 PD Leader 的位置）。此时写入 B 的数据在 B、C 上有相同的副本，A 上没有。
当 B 完全断开时：B 不满足多数派，其上的 region leader 由 A、C 重新发起选举，但由于 A 上的部分数据不是最新，只能由 C 先成为 leader，在补完数据后再将 leader 转移给 A（机制上每 60 秒检查一次，进行 leader 的转移）
多中心架构中 C 机房按建议配置 raft-min-election-timeout-ticks/raft-max-election-timeout-ticks 参数限制 C 上的副本发起选举时间，即该极端场景下需等待 raft-max-election-timeout-ticks 时间后，C 才会发起选举，并成为 leader

因此，raft-min-election-timeout-ticks/raft-max-election-timeout-ticks 不建议设置的过大，建议设置在 60S 以内。