GitHub凌晨大规模全站服务故障——怪它用了MySQL？

美国时间 8 月 14 日，GitHub 出现大规模宕机事故，核心服务几乎全部瘫痪（现已恢复）。当时用户反馈称，GitHub 主站无法访问，并显示 “无可用服务器” 的错误信息。

同时，包括 Pull Request、GitHub Pages、Copilot 和 GitHub API 在内的多个核心服务也受到严重影响。 

根据 GitHub 的 Status 状态页消息，本次影响范围为 GitHub 全站所有服务。

根据 GitHub Status 当时公布的情况，此次故障疑似因数据库基础设施变更导致，公司正在紧急回滚。

值得注意的是，此次故障发生迅速，从 GitHub 首次发布故障信息到多个服务瘫痪仅用了数分钟时间。据第三方监测平台 Downdetector 显示，有超过一万名用户报告了问题。

网络监测机构 NetBlocks 也确认了 GitHub 正在经历全球范围的宕机。

服务恢复后，GitHub 很快就发布了事故报告，称这是由于他们对数据库基础设施更改配置，从而引发流量路由受影响，结果导致关键服务意外失去数据库连接。在这一事件中，没有数据丢失或损坏。

两年前——2022 年，GitHub 有一段时间曾频繁出现宕机事件，官方称是 mysql1 集群的资源争夺导致，这影响了 GitHub 在负载高峰期的大量服务和功能性能。

2023 年，GitHub 将 MySQL 升级到了 8.0，当时他们介绍了 GitHub 的 MySQL 基础设施概览：

• 由 1200 多台主机组成，包括数据中心中的 Azure 虚拟机和裸机主机

• 存储超过 300 TB 的数据，并在 50 多个数据库集群中每秒处理 550 万次查询

• 每个集群都配置为具有主副设置的高可用性

• 分区存储数据 —— 利用水平和垂直分片来扩展 MySQL 集群，以及使用 MySQL 集群来存储特定产品领域的数据。此外还为大结构域 (large-domain) 提供了水平分片的 Vitess 集群，这些区域的增长超出了单主 MySQL 集群的规模

• 庞大的工具生态，包括 Percona Toolkit、gh-ost、orchestrator、freno 和用于操作主机集群的内部自动化工具

所以，MySQL 要为 GitHub 的宕机背锅吗？

Reference

https://www.githubstatus.com/incidents/kz4khcgdsfdv
https://www.theverge.com/2024/8/14/24220685/github-down-website-pull-request