GitHub 发布 10 月 21 日系统故障分析报告

h4cd
 h4cd
发布于 2018年10月31日
收藏 13

刚刚 GitHub 通过官方博客发布了 21 日“挂掉”的事件分析


GitHub 指出此次事件发生的原因是在 10 月 21 日 22:52 UTC 进行日常维护——更换发生故障的 100G 光纤设备时导致美国东海岸网络中心与美国东海岸数据中心之间的连接断开。


更具体地,GitHub 分析,虽然两地的连接在 43 秒内恢复,但这次短暂的中断引发了一系列事件,这才导致了长达 24 小时 11 分钟的服务降级。

为了大规模提高性能,GitHub 的应用程序将直接写入每个群集的相关主数据库,但在绝大多数情况下将读取请求委派给副本服务器的子集。GitHub 使用 Orchestrator 来管理 MySQL 集群拓扑并处理自动故障转移,Orchestrator 在此过程中考虑了许多变量,并在 Raft 共识机制之上达成共识。Orchestrator 可以实现应用程序无法支持的拓扑,因此必须注意将 Orchestrator 的配置与应用程序级别的期望保持一致。


然而 21 日,在网络分区过程中,Orchestrator 在主数据中心根据 Raft 的共识机制,执行了取消领导的选举(leadership deselection)。美国西海岸数据中心和美国东海岸公有云 Orchestrator 节点获得合规票数,并开始对群集进行故障转移,将写入指向美国西海岸数据中心。Orchestrator 继续组织美国西海岸数据库集群拓扑,当连接恢复时,应用层立即开始将写入流量引导到西海岸站点的新当选主节点上。

美国东海岸数据中心的数据库服务器包含一小段时间的写入数据,它们尚未复制到美国西海岸的设施。由于两个数据中心中的数据库集群都包含了其它数据中心中不存在的写入数据,因此无法安全地将主数据库故障转移到美国东海岸数据中心。


GitHub 工程师发现问题后进行了一系列抢救措施,“最终没有用户数据丢失,但是,几秒钟的数据库写入的手动协调仍在进行中。”

而之所以服务降级时间长达 24 小时 11 分,是因为在此次事件中,GitHub 的策略是优先考虑用户数据完整性,而不是站点可用性和恢复时间。

GitHub 对所有受影响的用户表示歉意,并表示“我们已经吸取了教训,并且采取了一系列措施,我们希望更好地确保不再发生类似情况。”

同时 GitHub 也表示接下来将进一步解决由此导致的数据不一致问题。

详细分析与事件时间线请查阅 GitHub 公告

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:GitHub 发布 10 月 21 日系统故障分析报告
加载中

精彩评论

izee
izee
双活中断后,两端产生的写入队列会形成冲突,网络恢复后,双活方案没有解决掉这个冲突,就宕机了
红薯
红薯

引用来自“izee”的评论

双活中断后,两端产生的写入队列会形成冲突,网络恢复后,双活方案没有解决掉这个冲突,就宕机了
这个问题目前其实还无解
NickWilde
NickWilde
由于两个数据中心中的数据库集群都包含了其它数据中心中不存在的写入,因此无法安全地将主数据库故障转移到美国东海岸数据中心。 这个是最蛋碎的,为了防止脑裂一般应该是3个节点,但是这个故障里只有两个中心。
harleyliao
harleyliao
网络分区,将主+少数派,多数派隔离,多数派根据raft协议选出新主,出现脑裂,两边都有数据写入,数据出现不一致。这个问题redis cluster也存在
蒋林辉
蒋林辉
split brain?

最新评论(16

抢小孩糖吃
抢小孩糖吃

引用来自“bhzhu203”的评论

哈哈哈 使用TiDB吧😄
@bhzhu203 这个问题和tidb没有太大关系
harleyliao
harleyliao
网络分区,将主+少数派,多数派隔离,多数派根据raft协议选出新主,出现脑裂,两边都有数据写入,数据出现不一致。这个问题redis cluster也存在
clouddyy
clouddyy

引用来自“izee”的评论

双活中断后,两端产生的写入队列会形成冲突,网络恢复后,双活方案没有解决掉这个冲突,就宕机了

引用来自“红薯”的评论

这个问题目前其实还无解
阿里云不是号称能搞定嘛
蒋林辉
蒋林辉
split brain?
名字又算什么呢
名字又算什么呢
有点不太懂,有大佬稍微解释下么?
bhzhu203
bhzhu203
哈哈哈 使用TiDB吧😄
红薯
红薯

引用来自“izee”的评论

双活中断后,两端产生的写入队列会形成冲突,网络恢复后,双活方案没有解决掉这个冲突,就宕机了
这个问题目前其实还无解
开源中国驻成都办事处
开源中国驻成都办事处
来用OceanBase吧
NickWilde
NickWilde
由于两个数据中心中的数据库集群都包含了其它数据中心中不存在的写入,因此无法安全地将主数据库故障转移到美国东海岸数据中心。 这个是最蛋碎的,为了防止脑裂一般应该是3个节点,但是这个故障里只有两个中心。
izee
izee
双活中断后,两端产生的写入队列会形成冲突,网络恢复后,双活方案没有解决掉这个冲突,就宕机了
返回顶部
顶部