GitHub發布10月21日系統故障分析報告
- 2019 年 12 月 30 日
- 筆記
摘要： 宕機是檢驗技術實力的唯一標準
Fundebug經授權轉載，版權歸原作者所有。
剛剛 GitHub 通過官方部落格發布了 21 日「掛掉」的事件分析：October 21 post-incident analysis
GitHub 指出此次事件發生的原因是在 10 月 21 日 22:52 UTC 進行日常維護——更換髮生故障的 100G 光纖設備時導致美國東海岸網路中心與美國東海岸數據中心之間的連接斷開。
At 22:52 UTC on October 21, routine maintenance work to replace failing 100G optical equipment resulted in the loss of connectivity between our US East Coast network hub and our primary US East Coast data center. Connectivity between these locations was restored in 43 seconds, but this brief outage triggered a chain of events that led to 24 hours and 11 minutes of service degradation.
更具體地，GitHub 分析，雖然兩地的連接在 43 秒內恢復，但這次短暫的中斷引發了一系列事件，這才導致了長達 24 小時 11 分鐘的服務降級。
為了大規模提高性能，GitHub 的應用程式將直接寫入每個群集的相關主資料庫，但在絕大多數情況下將讀取請求委派給副本伺服器的子集。GitHub 使用 Orchestrator 來管理 MySQL 集群拓撲並處理自動故障轉移，Orchestrator 在此過程中考慮了許多變數，並在 Raft 共識機制之上達成共識。Orchestrator 可以實現應用程式無法支援的拓撲，因此必須注意將 Orchestrator 的配置與應用程式級別的期望保持一致。
然而 21 日，在網路分區過程中，Orchestrator 在主數據中心根據 Raft 的共識機制，執行了取消領導的選舉（leadership deselection）。美國西海岸數據中心和美國東海岸公有雲 Orchestrator 節點獲得合規票數，並開始對群集進行故障轉移，將寫入指向美國西海岸數據中心。Orchestrator 繼續組織美國西海岸資料庫集群拓撲，當連接恢復時，應用層立即開始將寫入流量引導到西海岸站點的新當選主節點上。
美國東海岸數據中心的資料庫伺服器包含一小段時間的寫入數據，它們尚未複製到美國西海岸的設施。由於兩個數據中心中的資料庫集群都包含了其它數據中心中不存在的寫入數據，因此無法安全地將主資料庫故障轉移到美國東海岸數據中心。
GitHub 工程師發現問題後進行了一系列搶救措施，「最終沒有用戶數據丟失，但是，幾秒鐘的資料庫寫入的手動協調仍在進行中。」
而之所以服務降級時間長達 24 小時 11 分，是因為在此次事件中，GitHub的策略是優先考慮用戶數據完整性，而不是站點可用性和恢復時間。
GitHub 對所有受影響的用戶表示歉意，並表示「我們已經吸取了教訓，並且採取了一系列措施，我們希望更好地確保不再發生類似情況。」
同時 GitHub 也表示接下來將進一步解決由此導致的數據不一致問題。
詳細分析與事件時間線請查閱 GitHub 公告。
相關鏈接
轉載說明
本站文章除註明轉載外，均為本站原創或編譯。歡迎任何形式的轉載，但請務必註明出處，尊重他人勞動共創開源社區。
轉載請註明：文章轉載自 開源中國社區 [http://www.oschina.net] 本文標題：GitHub 發布 10 月 21 日系統故障分析報告 本文地址：https://www.oschina.net/news/101342/github-oct21-incident-analysis
版權聲明
轉載時請註明作者 Fundebug以及本文地址： https://blog.fundebug.com/2018/11/05/github-incident-analysis/
您的用戶遇到BUG了嗎？
.copyright *{box-sizing:border-box}
