这起事故虽然发生在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）. 为什么恢复数据的方式是通过备份进行恢复？
通过备份恢复数据的问题是，时间太长。首先是备份存在公有云，需要远程下载，其次是解压、校验和应用数据，耗费时间。
为什么不将东海岸的其中一个从库，回退部分数据，接着同步西海岸新写入的数据，之后，就可以使用了吧？