摘要
2018-10-21，GitHub 美国东海岸两个数据中心之间发生网络分区。故障切换机制将流量导向了原本应作为副本的数据中心，导致两个站点各自持有对方没有的写入数据。MySQL 拓扑出现冲突，为防止数据丢失，GitHub 暂停了主库写入，陷入长时间恢复，总中断约 24 小时 11 分。
# 两个数据中心各说各话，为了不丢数据只能先不写。
时间线
故障前例行主从切换演练 / 网络维护
分区发生两 DC 间网络中断
切换后两站点各含对方无数据，MySQL 拓扑冲突
为防丢失暂停主库写入
~24h11m完成数据协调与重建，恢复写入
根因
GitHub 在美国东海岸两个数据中心（Primary 位于 Virginia、副本位于 Massachusetts）之间进行网络维护时，触发了两 DC 间的网络分区。故障切换机制（基于 Orchestrator）把流量导向了原本应只作为副本、不应承接写入的 Massachusetts DC；结果两个站点各自持有对方没有的写入，MySQL 复制拓扑出现冲突。为防止分裂脑导致数据丢失，GitHub 主动暂停了主库写入，陷入长时间恢复。
- 东海岸网络维护触发 Primary（Virginia）与副本（Massachusetts）间分区。
- 故障切换把流量导向了不应承接写入的副本 DC，主 / 副本角色未严格锁定写入 ownership。
- 分区期间两站点各自承接写入，产生分裂脑数据，MySQL 拓扑不一致。
- 为防脑裂丢数据暂停主库写入，数据协调缺乏自动化，恢复以小时计。
放大因素
双活 / 切换逻辑缺陷；数据协调无自动化；分区期间写入堆积，恢复窗口被拉长到一整天。
缓解措施
- 明确主 / 副本角色，禁止副本承接写入。
- 网络分区检测与「脑裂」防护。
- 数据协调自动化，缩短恢复时间。
经验教训
多数据中心必须定义清晰的写入 ownership，分区时宁停勿裂；数据协调要可自动化，不能靠人肉对账。
检查清单
- 确认是否发生网络分区 / 切换
- 核对主副本角色与写入 ownership
- 检查 MySQL 拓扑冲突与数据协调进度
- 验证脑裂防护
- 复盘恢复自动化程度