去年2月，GitHub完成了内部调查，原因是什么导致了多次服务中断，影响了它超过8个小时的服务。造成这种情况的根本原因是意外的数据库负载变化和数据库配置问题。
所有的事件都影响到了GitHub的主数据库集群mysql1，它原本是GitHub上唯一的MySQL集群。
随着时间的推移，随着mysql1变得越来越大、越来越忙，我们将功能分组的表集拆分为新的集群，并为新的功能创建新的集群。然而，我们的大部分核心数据集仍然驻留在原始集群中。
第一个事件发生在GitHub工程师不小心向数据库主服务器发送了一个资源密集型的查询，而不是它的只读副本。因此，负责连接池的ProxySQL被重载，并开始以不一致的方式提供查询。
两天后也发生了类似的问题，原因是计划对主数据库进行升级，以便在主数据库只读一段时间时调查潜在的问题。这也产生了一个意料之外的负载和一个类似的proxy ql失败。
在这两种情况下，减少负载就足以修复故障。
更关键的是第三次事故，持续了两个多小时。在本例中，由于活动数据库连接跨越了给定的阈值，所以代理服务器也是故障点。
在这种情况下，主要的问题是活动连接在修复之后仍然高于临界阈值，这使得系统进入降级的服务状态。结果表明，proxy ql配置不当，并且由于系统范围和进程本地LimitNOFILE之间的冲突，将其描述符限制降级为65536。
第四个事件是由GitHub应用程序逻辑的变化引起的。此更改生成的查询会迅速增加mysql1主服务器上的负载，从而影响所有相关的服务。
根据GitHub工程师的说法，所有的问题一旦确定了根本原因，就很容易纠正，但是系统之间的交互并不总是可以立即理解。因此，他们解释说，改进的第一个重点领域是可观察性，然后在部署到生产环境之前进行更彻底的系统集成和性能测试。
然而，GitHub的工程师们继续说，要找到问题的核心，需要改进数据分区，以减少mysql1集群主服务器上的负载。这将有助于满足零停机时间的要求，并减少任何未来事件对用户的影响。
特别是，他们处理一个表，即能力表，这个表与任何身份验证请求一起使用，因此是性能的中心。经过两个月的工作后，能力表现在在它自己的集群中运行，以前需要使它与系统中的任何其他表独立(读，无连接)。GitHub的工程师说，多亏了这一变化，mysql1集群主服务器的负载减少了20%。
虽然进一步划分数据库的工作还在继续，目标是进一步减少mysql1集群上60%的写负载，并将12个模式域移出该集群，GitHub工程师还发现了其他一些改进措施。其中包括在从副本获得相同数据时减少从主服务器读取数据的次数;使用特性标志来禁用可能有问题的代码更改;改进GitHub内部仪表板，更好地识别部署问题;使用分片提高水平可伸缩性。