
完全復旧までに24時間を要したGitHubの障害は43秒のネットワーク切断がきっかけだった 21
ストーリー by headless
相談 部門より
相談 部門より
GitHubは10月30日、日本時間10月22日に発生した障害のきっかけが43秒間のネットワーク切断だったことを明らかにした(GitHub Blogの記事、
The Registerの記事、
GeekWireの記事)。
日本時間10月22日7時52分、不調となった100G光ネットワーク機器の定期メンテナンスによる交換が行われた際、プライマリーの米東海岸データセンターと米東海岸ネットワークハブの間で43秒間接続が失われたという。その結果、Orchestratorにより米西海岸データセンターが新たなプライマリーに選出され、書き込みトラフィックが送られはじめる。
しかし、米東海岸データセンターにも西海岸で複製されていない短時間の書き込みがあり、両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになる。そのため、安全に東海岸をプライマリーとしてフェイルバックすることが不可能な状態となっていた。
日本時間10月22日7時52分、不調となった100G光ネットワーク機器の定期メンテナンスによる交換が行われた際、プライマリーの米東海岸データセンターと米東海岸ネットワークハブの間で43秒間接続が失われたという。その結果、Orchestratorにより米西海岸データセンターが新たなプライマリーに選出され、書き込みトラフィックが送られはじめる。
しかし、米東海岸データセンターにも西海岸で複製されていない短時間の書き込みがあり、両データセンターのMySQLデータベースクラスターには一方だけに存在する書き込みが含まれることになる。そのため、安全に東海岸をプライマリーとしてフェイルバックすることが不可能な状態となっていた。
GitHubの対策チームは、データの消失を最低限におさえるため、西海岸に複製されていない東海岸でのMySQLバイナリーログを確保しつつ、東海岸のデータセンターに対するバックアップからの復元作業を開始する。外部のクラウドストレージに保存されたバックアップは数TBにおよび、復元には数時間を要した。復元されたクラスターには西海岸から新しいデータを追加し、東海岸がプライマリーとして復旧したとのこと。
GitHubでは現在、東海岸のログを分析して復元を進めているほか、地域をまたぐプライマリー変更が行われないようOrchestratorの設定を調整するなどの対策を行ったとのことだ。
SQLServer (スコア:2)