微软子公司GitHub近日针对上月底持续8小时以上的系列故障发布了一份完整的事后分析报告，详细说明导致GitHub遭遇的数据库基础设施。中断的确切原因并不是GitHub数据库第一次出现问题。这份由GitHub工程高级副总裁基思·巴林格(KeithBallinger)撰写的报告称，2月份的中断是“多次服务中断，导致服务降级，在四次不同的事件中总共持续了8小时14分钟。”简短的解释是：“数据库负载的突然变化，加上由于日常扩展改进导致的意外配置问题，共同导致我们的mysql1数据库集群中的资源争用。”尽管代码存储公司一直在扩展数据运维，但“我们的大部分核心数据集”仍然驻留在他们原来的集群上。第一次中断发生在2月19日，当时“一个意外的资源密集型查询开始在我们的mysql1数据库集群上运行”。虽然最初的计划是以低得多的频率在只读副本池上运行该负载，但“我们不小心将此流量发送到集群的主节点（master），这增加了主机的压力并超出了服务范围剩余容量。”无法一致地执行查询。”两天后，“计划中的主数据库升级再次导致ProxySQL失败。”第三次事件发生在2月25日，再次涉及ProxySQL，当时“活动数据库连接数超过阈值，改变了这个新的行为基础设施。由于修复后连接仍然高于临界值，系统又回到了降级状态。”然后在2月27日，GitHub遭遇了一次大宕机，宕机了整整4小时23分钟。这是由于“应用逻辑对数据库查询模式的改变，迅速增加了我们mysql1数据库集群的master节点所面临的负载，这种负载突然增加的情况导致集群性能大幅下降，影响了所有的运行相关服务。”可用性。”Ballinger声称GitHub进行了更改以更快地检测和解决问题。“一旦我们确定了系统之间的相互关系，解决这些问题就很简单了。GitHub还付出了“更多努力”来了解大规模运行的ProxySQL的性能特征及其对其他服务的影响，同时又不影响用户。Ballinger补充说：“就在这些事件发生几天后，我们已经完成了对MySQL表中一个更重要的字段（“能力”表）的大量数据分区任务。这些更改减轻了主节点的负载mysql1集群减少20%，每秒查询数减少15%。该公司还致力于减少从主数据库的读取操作并将其移动到副本数据库，并完成“mysql1集群的动态功能分区和确定要分区的其他域。”它还改进了仪表板并分片了最大的模式集。“如果GitHub没有更好地报告错误或引入混沌工程技术让你感到奇怪，那是因为它早在2018年就承诺会做这些事情。2018年，在连接中断导致其数据库集群在美国东西海岸失去同步后，GitHub经历了24小时的短暂中断美国。不仅仅是GitHub。运行一个云平台是……困难的。母公司微软本周发现其Azure平台出了点问题，在撰写本文时，谷歌在谷歌云平台(GCP)服务出现广泛故障后发布了修复程序。
