苏宓出品
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表示,对这些中断造成的负面影响深表歉意。也承诺将快速处理中断问题并最大限度地减少宕机的时间。
在此次宕机事件中,你是否受到了影响?
参考: