MySQL集群资源竞用造成服务不稳,GitHub难题待解

从3月16日开始,GitHub平台因为数据库问题,接连几天出现服务不稳的状况,而官方现在提出说明,表示服务不稳的状况,是因为MySQL集群中资源竞用所造成,因此在服务高峰的时候,影响GitHub大量服务和功能的性能。目前GitHub正在努力解决这个问题,会于之后的可用性报告进一步说明。

GitHub在3月16日22点06分的时候,发现MySQL数据库在高峰时段负载增加,而这导致数据库代理达到了最大连接数,官方解释,这个数据库由多个服务共享,并接受大量的读写流量,因此在中断期间,所有写入操作都无法进行,包括Git操作、webhook、拉取请求、API请求、问题发布、GitHub Packages、GitHub Codespaces、GitHub Actions和GitHub Pages服务。

官方指出,该事件似乎与峰值负载,再加上特定情况下的查询性能不佳有关。GitHub的MySQL集群使用典型的主要与副本执行实例配置,以实现高可用性,其中只有单一主要节点能够执行写入,集群的其他部分则由提供读取流量的副本执行实例组成,GitHub借由故障转移使用健康的副本执行实例,来解决服务中断的问题,并对这段时间与查询性能相关的流量模式展开调查。

但是相同的问题却在3月17日又出现一次,官方观察到MySQL集群,出现与前一天相同的高峰流量模式和负载,由于还无法查明和解决出现查询性能问题的根本原因,官方决定在问题变严重之前先采取行动,主动进行故障转移,但没想到这个举动产生另一种负载模式,反而在主节点上造成连接问题,尽管GitHub重置连接,但应用程序仍无法连接到MySQL集群。通过找出负载模式后,官方实例索引来解决主要节点的性能问题。

接着在3月22日和23日都接连发生同样事故,官方在数据库代理中激活内存分析,希望进一步掌握高峰负载期间所出现的性能特征,并且限制webhook流量避免出现高峰流量,而这两天,GitHub同样必须在连接发生中断后,执行故障转移来恢复服务。

GitHub在高峰负载时段,审核特定数据库的负载模式,并根据审核的结果,进行一系列性能修复工作,这些工作包括将流量转移到其他数据库,以减少负载并且加速故障转移的时间,并且审查变更管理程序,官方解释,因为变更管理程序,与生产时中高负载期间的监控和变更有关。

GitHub还未找出发生连接问题的真正原因,目前先采取的措施,只能确保他们能优雅的处理中断,并且尽可能减少停机时间。

发表评论