GitHub发布21日系统故障分析报告
刚刚GitHub通过官方博客发布了21日“挂掉”的事件分析。GitHub指出此次事件发生的原因是在10月21日22:52 UTC进行日常维护——更换发生故障的100G光学设备时导致美国东海岸网络中心与美国东海岸数据中心之间的连接断开。
更具体地，GitHub分析，虽然两地的连接在43秒内恢复，但这次短暂的中断引发了一系列事件，这才导致了长达24小时11分钟的服务降级。
为了大规模提高性能，GitHub的应用程序将直接写入每个群集的相关主数据库，但在绝大多数情况下将读取请求委派给副本服务器的子集。GitHub使用Orchestrator来管理MySQL集群拓扑并处理自动故障转移，Orchestrator在此过程中考虑了许多变量，并在Raft共识机制之上达成共识。Orchestrator可以实现应用程序无法支持的拓扑，因此必须注意将Orchestrator的配置与应用程序级别的期望保持一致。
然而21日，在上述网络分区中，Orchestrator在主数据中心中一直保持活跃，根据Raft的共识机制，它开始了一个取消领导选举的过程。美国西海岸数据中心和美国东海岸公有云Orchestrator节点能够建立合规数量并开始对群集进行故障转移，以便将写入指向美国西海岸数据中心。Orchestrator继续组织美国西海岸数据库集群拓扑，当连接恢复时，应用层立即开始将写入流量引导到西海岸站点的新当选者。
美国东海岸数据中心的数据库服务器包含一段短暂的写入时间，但尚未复制到美国西海岸的设施。由于两个数据中心中的数据库集群都包含了其它数据中心中不存在的写入，因此无法安全地将主要数据库故障转移到美国东海岸数据中心。
GitHub工程师发现问题后进行了一系列抢救措施，“最终没有用户数据丢失，但是，几秒钟的数据库写入的手动协调仍在进行中。”
GitHub对所有受影响的用户表示歉意，并表示“我们已经吸取了教训，并且采取了一系列急救措施，我们希望更好地确保不再发生类似情况。”
同时GitHub也表示接下来将解决由此导致的数据不一致问题。
相关阅读
企业要为云端的5种风险承担责任
云环境中面临的传统和新兴威胁
2019年你必须了解的六大新兴信息安全工具
