不过，针对宕机事件，GitHub 迅速进行跟进并公开了最新的调查报告，究其原因，GitHub 多次宕机竟与 MySQL 数据库有关。

有媒体统计，GitHub 在过去一周中多次中断影响的开发者数量高达 7300 万。根据网友投诉以及 GitHub 官方统计，过去一段时间内的宕机分别发生在 3 月 16 日、17 日、22 日、23 日，每起事件持续时长在 2-5 小时。

GitHub 高级工程副总裁 Keith Ballinger 发文表示，「我知道这会影响许多客户的生产力，我们也非常重视这一点。过去几周发生的宕机事件根本原因是我们的‘MySQL1’集群中的资源争夺，在负载高峰期，影响了 GitHub 大量服务和功能。」

根据官方公告，宕机的主要时间线如下：

第一次宕机发生时，GitHub  MySQL1 数据库负载增加，导致数据库访问达到最大连接数。这个数据库接收大量的读/写流量，也被多个服务程序应用。

当中断发生时，GitHub 发现 MySQL1 数据库所有的写入操作都无法进行，影响 Git 操作、webhook、拉取请求、API 请求、issue、GitHub Packages、GitHub Codespaces、GitHub Actions 和 GitHub 页面服务。

经过调查发现，这种情况似乎与峰值负载以及特定情况下查询性能不佳有关。

值得注意的是，GitHub 使用 MySQL 作为所有非 git 仓库数据的主要存储，对其高可用性也有很大的要求。

GitHub 的 MySQL 集群使用经典的主从配置，主集群中的某个节点能够接受写入，其余的从集群节点异步同步来自主服务器的更改，并提供数据的读取服务。基于此，GitHub 可以实现故障转移，即在一个写入失败时，提示主节点崩溃的场景中，会有另一个新的主节点被启用，用以支撑场景实现，避免宕机。

但是这个选项失败了，宕机还是发生了。

次日，GitHub 还是宕机了，虽然持续时间比前一天要少，但 MySQL1 中呈现的是相同的峰值流量模式和负载。

对此，GitHub 解释道，“在这个峰值前，我们无法确定和解决查询性能问题，我们决定在问题升级前主动进行故障转移。

不幸的是，这导致了一种新的负载模式。在新的故障转移主服务器过程中引入了连接问题，并且 GitHub 努力重置这些连接时，应用服务再次无法连接到 MySQL1。”

基于此，GitHub 能够确定负载模式，随后实施了一个索引来修复主要的性能问题。

虽然 GitHub 在前两次中减少了负载，但是对于最终结果他们也并不是有 100% 的信心。

因此，在第三次宕机发生之前，GitHub 在数据库代理上启用了内存剖析，以便更仔细地观察峰值负载期间的性能特征。同时，当故障发生，以及客户对 MySQL1 的连接失败时，GitHub 再次执行主故障切换进行了恢复。

发生了第四次宕机时，GitHub 限制了 webhook 的流量，并在其数据库无法处理峰值负载时使用该控件来缓解未来的问题。 

截至目前，GitHub 并不能完全阻断宕机事件再次发生的可能性。

不过，为了防止这些类型的事件在未来发生，GitHub 表示，“我们已经开始对这个特定数据库在高峰期的负载模式进行审计，并根据这些审计进行一系列的性能修复。作为其中的一部分，我们正在将流量转移到其他数据库，以减少负载并加快故障切换时间，同时审查我们的变更管理程序，特别是与生产中高负载期间的监控和变更有关的程序。”

作为一家托管服务平台，GitHub 时不时的宕机事件，无疑对开发者而言是一种不好的体验。对于此，GitHub 表示，对这些中断造成的负面影响深表歉意。也承诺将快速处理中断问题并最大限度地减少宕机的时间。

在此次宕机事件中，你是否受到了影响？

  https://github.blog/2022-03-23-an-update-on-recent-service-disruptions/