查看原文

本文总结了为什么 GitHub 挂了一天多。

简单来说，有那么 43 秒的时间，东海岸的网络hub跟机房网络不通，导致 MySQL Raft Orchestrator 把 master 从东海岸切到了西海岸。就是一次脑裂，东西两边都有数据写进了数据库。工程师们决定保障数据一致性，所以就给服务降级，再慢慢迁移数据。

思考：

• 应急响应的博客服务怎么可以用自家服务呢，还是尽量用第三方服务/或者完全在别的地方托管比较好。
• 是否可以增加一份预算，当备份传输太慢的时候，直接让工程师带上硬盘，用几小时直飞到另外一个机房去作为 Plan B?
• 公有云的 blob 服务是否合适用于备份 TB 级别的数据？解压出来进新的 MysQL 服务器也需要很久时间。最能治本的方案可以在 Raft 集群外再做一个热备的 master，也即是文末提到的 multiple data centers in an active/active/active design.。
• Chaos Engineering 还没介入他们的工程文化。
• 本次事故，跨机房的 leader 切换是根源。Leader 选举不是万金油，Raft 它不能保证任意时刻只有一个 Leader（脑裂）。关于这个话题，欢迎查看我的一篇讨论：Raft and The Nature of Time。