关于GitHub 服务中断 24 小时 11 分钟事故

这起事故虽然发生在2018年，已经过去了很长时间，但其中的问题和带来的启示永不过时，拿来分析，具有很重要的意义。

1.背景

GitHub主要有东、西海岸两个数据中心，以及其他三个公有云数据中心。本次事故主要涉及东、西海岸两个数据中心。
并且，在GitHub，使用的Orchestrator作为MySQL集群拓扑管理和主库高可用工具。

GitHub 的MySQL集群和Orchestrator高可用服务部署情况如下。

MySQL集群部署情况

MySQL集群是一主 4从：

• 主库和2个从库在东海岸
• 2个从库在西海岸

为了大规模提高扩展性，已经使用读写分离。写操作在主库上，大部分读操作在从库上。

Orchestrator部署情况

Orchestrator高可用服务以分布式集群方式部署，跨东西海岸。

2.事情的经过

东海岸更换光纤设备，导致东海岸数据中心与外界网络断开，43s后，网路恢复。

这个短暂的网络断开，引起了一连串的事故。

这些事故主要包括以下。

1）.ORC leader漂移

ORC leader 原来是在东海岸，网络断开，触发leader 漂移到西海岸。

2）.MySQL集群主库切换后，数据不一致

ORC leader 漂移到西海岸后，发现主库探测异常，2个东海岸从库探测异常，2个西海岸从库复制断开，判定为DeadMasterAndSomeSlaves，触发MySQL集群主库由东海岸切到西海岸。写入流量开始导入到西海岸主库。

在切换过程，东海岸的2个从库无法change到新主库，成为丢失副本。切换后，实际集群拓扑，只包括一主一从，且都在西海岸。

切换后，发现东海岸有部分写入没有同步到西海岸。东、西海岸数据出现不一致。

出现问题后，为了保证数据一致性，GitHub 首先进行了服务降级，暂停了部分服务。

接着，在东海岸重新建立新主库。这其中包括，从备份恢复数据、从东西海岸同步数据等。

再接着，将主库切回东海岸。处理队列中的数据。

最后，网站对外提供服务。

最最后，解决数据不一致。通过与用户沟通，恢复丢失的数据。

3.存在的隐患

通过这个事故，可以看到几个隐患。

1）.ORC 跨Region部署

跨Region 的网络抖动，会导致ORC leader漂移。如果leader正在进行切换，leader漂移，会导致切换进行到一半。

解决方案：ORC 服务不跨Region部署。

2）.MySQL集群跨Region部署

跨Region部署，一方面，可以提供数据远程备份。另一方面，复制可能存在延迟，如果发生类似这个故障场景的切换，会造成数据不一致。

3）. 为什么恢复数据的方式是通过备份进行恢复？

通过备份恢复数据的问题是，时间太长。首先是备份存在公有云，需要远程下载，其次是解压、校验和应用数据，耗费时间。

为什么不将东海岸的其中一个从库，回退部分数据，接着同步西海岸新写入的数据，之后，就可以使用了吧？

4.参考

2018-10-30-oct21-post-incident-analysis

GitHub 服务中断 24 小时 11 分钟事故分析报告