Github 8 小时一连串故障的元凶是：数据库基础架构

微软子公司GitHub近日就上个月底持续时间超过8个小时的一连串故障发表了完整的事后分析报告，详细说明了数据库基础架构导致GitHub遭遇故障的确切原因，GitHub数据库出岔子不是第一次了。

GitHub工程高级副总裁Keith Ballinger撰写的这篇报告称，2月份的故障是“多次服务中断，导致在四起独立的事件中服务降级持续时间共长达8小时14分钟。”

简短的解释就是：“数据库负载突然出现变化，加上因日常的规模扩展改进而带来的意外配置问题，共同导致了我们的mysql1数据库集群出现资源争夺现象。”虽然这家代码存储库公司一直在扩大数据运维的规模，但“我们的大部分核心数据集”仍驻留在其原始集群中。

第一次故障发生在2月19日，当时“一个意外的资源密集型查询开始在我们的mysql1数据库集群上运行。”虽然原计划是以低得多的频次在读取副本池上运行该负载，但“我们不小心将该流量发送到了集群的主节点（master），给该主机加大了压力，超出了剩余容量的服务范围。”

这一切使ProxySQL不堪重负，“ProxySQL负责连接池，因而导致无法一致地执行查询。”

两天后，“计划中的主数据库升级再次引发了ProxySQL故障。”

2月25日的第三次事件再次涉及ProxySQL，当时“活动数据库连接超过了临界值，从而改变了这个新基础架构的行为。由于连接在修复后仍保持在临界值之上，因此系统回退到了降级状态。”

然后在2月27日，GitHub遭到了重大故障，停运了整整4小时23分钟。这是由于“应用程序逻辑对数据库查询模式的更改迅速加大了我们mysql1数据库集群的主节点所面临的负载。负载猛增的这种情况使集群性能大幅下降，以至于影响了所有相关服务的可用性。”

Ballinger声称，GitHub进行了更改，以便更迅速地检测和解决问题。“一旦我们查明了系统之间的相互关系，解决这些问题就很简单。”GitHub还抽出“更多的精力”，在不影响用户的情况下，了解大规模运行的ProxySQL的性能特征及其对其他服务造成的影响。

Ballinger补充说：“就在这些事件发生几天后，我们为其中一个比较重要的MySQL表域（“abilities”表）完成了工作量相当大的数据分区任务。这些更改将mysql1集群主节点上的负载减少了20%，将每秒查询次数减少了15%。”

该公司还致力于减少主数据库的读取操作，并将它们转移至副本数据库，并完成“mysql1集群的在途（in-flight）功能分区，并确定要分区的其他域。它还在完善仪表板，并对最大的模式集进行分片（sharding）。”

如果GitHub没有在更好地报告故障或引入混乱工程技术方面做得更到位让你觉得很奇怪，那是由于它早在2018年的时候就已经保证会做那些事情。2018年，在短暂的连接中断导致其数据库集群在美国东西岸地区不同步后，GitHub遭遇了长达24小时的故障。

而且遭遇故障的并非只有GitHub。运行云平台很……难。母公司微软本周发现其Azure平台出了问题，而就在撰写本文时，谷歌在谷歌云平台（GCP）服务大范围出问题后正发布修复程序。