微软子公司 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）服务大范围出问题后正发布修复程序。