GitHubのウェブサイトが24時間にわたり不安定な状態にあった原因は、予期せぬMySQLデータベースのメルトダウンだったと判明

更新されたプログラマーの皆さん、雪の日は完全に終わりました。GitHub の Web サイトは 24 時間の停止からようやく解放され、すべてが再び正常に動作するようになったようです。

昨年、CEOのクリス・ワンストラスは、ダウンタイムゼロ、あるいは少なくとも99.999%の稼働率を目指すと述べました。これは年間約5分の非サービス時間を意味し、この目標をはるかに上回ったと言っても過言ではありません。

マイクロソフトが75億ドルで買収を希望していた企業は、日曜日の午後4時（米国太平洋時間）にウェブサイトで「エラー率の上昇」を初めて報告しました。その後、ほぼ24時間後の月曜日の午後4時（太平洋時間）に「復旧」のメッセージが届くまで、断続的なサービスが続きました。英国のユーザーにとっては、日曜日の午後11時から月曜日の午後11時までの間、月曜日の終日サービス停止となりました。一方、オーストラリアのユーザーは月曜日の午前10時にサイトがダウンし、ログインする時間もほとんどありませんでした。

昨日報告し​​たように、バックエンドの Git サービスは動作していましたが、Web サイトは時間的にフリーズし、古いコード リポジトリを提供し、送信された資料、Gist、およびバグ レポートを無視していました。

GitHubのインシデントレポートによると、この障害はデータストレージシステムのダウンが原因で、1台または複数のMySQLデータベースサーバーがダウンしたとみられています。現在は状況は正常に戻り、問題は「ネットワークの分断とそれに続くデータベース障害により、ウェブサイトに表示される情報が不整合になった」ことから始まったと説明されています。

GitHubは、リポジトリへのエラーの伝播を防ぐため、Webhookイベントと「その他の内部処理システム」を一時停止することを決定したと発表しました。少なくとも、その効果はありました。インシデントレポートによると、障害の影響は「MySQLデータベースに保存されているウェブサイトのメタデータ（課題やプルリクエストなど）のみでした。Gitリポジトリのデータは影響を受けず、インシデント発生中も利用可能でした」とのことです。

データベースに不具合が発生してから1時間後、管理者はバックアップデータストレージシステムへのフェイルオーバーを試みましたが、うまくいきませんでした。サイトが停止してから3時間後、ステータスメッセージはデータストレージシステムの移行を発表するものから、「損傷したストレージバックエンドの修復作業を継続しています」というメッセージに変わりました。

データベースの復元には「予想以上に時間がかかった」ため、その後、修復作業を検証し、Pages ビルドや Webhook など、膨大な数のイベントのバックログを処理する必要がありました。

最後の「エラー」メッセージは月曜日の15:23 PT（UTC 22:23、火曜日の09:23 AEST）に投稿され、40分後に「すべて正常に動作しています」という嬉しいメッセージが届きました。®

追加更新

MySQL データベースのメルトダウンは、不安定なネットワーク リンクによって発生し、データ ストアが不整合な状態になりました。