苏宓出品
CSDN（ID：CSDNnews）
宕机时时有，但近期特别多。这边苹果服务器发生大规模宕机，导致AppStore、AppleMusic、Books等十几项服务中断，另一边全球知名代码托管平台GitHub也出现了此种情况。
不过，针对宕机事件，GitHub迅速进行跟进并公开了最新的调查报告，究其原因，GitHub多次宕机竟与MySQL数据库有关。
GitHub宕机原因分析
有媒体统计，GitHub在过去一周中多次中断影响的开发者数量高达万。根据网友投诉以及GitHub官方统计，过去一段时间内的宕机分别发生在3月16日、17日、22日、23日，每起事件持续时长在2-5小时。
GitHub高级工程副总裁KeithBallinger发文表示，「我知道这会影响许多客户的生产力，我们也非常重视这一点。过去几周发生的宕机事件根本原因是我们的‘MySQL1’集群中的资源争夺，在负载高峰期，影响了GitHub大量服务和功能。」
根据官方公告，宕机的主要时间线如下：
3月16日1:09（持续5小时36分钟）
第一次宕机发生时，GitHubMySQL1数据库负载增加，导致数据库访问达到最大连接数。这个数据库接收大量的读/写流量，也被多个服务程序应用。
当中断发生时，GitHub发现MySQL1数据库所有的写入操作都无法进行，影响Git操作、webhook、拉取请求、API请求、issue、GitHubPackages、GitHubCodespaces、GitHubActions和GitHub页面服务。
经过调查发现，这种情况似乎与峰值负载以及特定情况下查询性能不佳有关。
值得注意的是，GitHub使用MySQL作为所有非git仓库数据的主要存储，对其高可用性也有很大的要求。
GitHub的MySQL集群使用经典的主从配置，主集群中的某个节点能够接受写入，其余的从集群节点异步同步来自主服务器的更改，并提供数据的读取服务。基于此，GitHub可以实现故障转移，即在一个写入失败时，提示主节点崩溃的场景中，会有另一个新的主节点被启用，用以支撑场景实现，避免宕机。
但是这个选项失败了，宕机还是发生了。
3月17日13:6（持续2小时28分钟）次日，GitHub还是宕机了，虽然持续时间比前一天要少，但MySQL1中呈现的是相同的峰值流量模式和负载。
对此，GitHub解释道，“在这个峰值前，我们无法确定和解决查询性能问题，我们决定在问题升级前主动进行故障转移。
不幸的是，这导致了一种新的负载模式。在新的故障转移主服务器过程中引入了连接问题，并且GitHub努力重置这些连接时，应用服务再次无法连接到MySQL1。”
基于此，GitHub能够确定负载模式，随后实施了一个索引来修复主要的性能问题。
3月22日15:53UTC（持续2小时53分钟）虽然GitHub在前两次中减少了负载，但是对于最终结果他们也并不是有%的信心。
因此，在第三次宕机发生之前，GitHub在数据库代理上启用了内存剖析，以便更仔细地观察峰值负载期间的性能特征。同时，当故障发生，以及客户对MySQL1的连接失败时，GitHub再次执行主故障切换进行了恢复。
3月23日1:9（持续2小时51分钟）发生了第四次宕机时，GitHub限制了webhook的流量，并在其数据库无法处理峰值负载时使用该控件来缓解未来的问题。
解决方案
截至目前，GitHub并不能完全阻断宕机事件再次发生的可能性。
不过，为了防止这些类型的事件在未来发生，GitHub表示，“我们已经开始对这个特定数据库在高峰期的负载模式进行审计，并根据这些审计进行一系列的性能修复。作为其中的一部分，我们正在将流量转移到其他数据库，以减少负载并加快故障切换时间，同时审查我们的变更管理程序，特别是与生产中高负载期间的监控和变更有关的程序。”
作为一家托管服务平台，GitHub时不时的宕机事件，无疑对开发者而言是一种不好的体验。对于此，GitHub表示，对这些中断造成的负面影响深表歉意。也承诺将快速处理中断问题并最大限度地减少宕机的时间。
在此次宕机事件中，你是否受到了影响？
参考：