GitHub 釋出 21 日系統故障分析報告

剛剛 GitHub 通過官方部落格釋出了 ofollow,noindex" target="_blank">21 日“掛掉”的事件分析 。

GitHub 指出此次事件發生的原因是在 10 月 21 日 22:52 UTC 進行日常維護——更換髮生故障的 100G 光學裝置時導致美國東海岸網路中心與美國東海岸資料中心之間的連線斷開。

更具體地，GitHub 分析，雖然兩地的連線在 43 秒內恢復，但這次短暫的中斷引發了一系列事件，這才導致了長達 24 小時 11 分鐘的服務降級。

為了大規模提高效能，GitHub 的應用程式將直接寫入每個群集的相關主資料庫，但在絕大多數情況下將讀取請求委派給副本伺服器的子集。GitHub 使用 Orchestrator 來管理 SQL/">MySQL 叢集拓撲並處理自動故障轉移，Orchestrator 在此過程中考慮了許多變數，並在 Raft 共識機制之上達成共識。Orchestrator 可以實現應用程式無法支援的拓撲，因此必須注意將 Orchestrator 的配置與應用程式級別的期望保持一致。

然而 21 日，在上述網路分割槽中，根據 Raft 的共識機制，Orchestrator 在主資料中心中一直保持活躍，開始了一個取消領導選舉的過程。美國西海岸資料中心和美國東海岸公有云 Orchestrator 節點能夠建立合規數量並開始對群集進行故障轉移，以便將寫入指向美國西海岸資料中心。Orchestrator 繼續組織美國西海岸資料庫叢集拓撲，當連線恢復時，應用層立即開始將寫入流量引導到西海岸站點的新當選者。

美國東海岸資料中心的資料庫伺服器包含一段短暫的寫入時間，但尚未複製到美國西海岸的設施。由於兩個資料中心中的資料庫叢集都包含了其它資料中心中不存在的寫入，因此無法安全地將主要資料庫故障轉移到美國東海岸資料中心。

GitHub 工程師發現問題後進行了一系列搶救措施，“最終 沒有使用者資料丟失， 但是，幾秒鐘的資料庫寫入的手動協調仍在進行中。”

GitHub 對所有受影響的使用者表示歉意，並表示“我們已經吸取了教訓，並且採取了一系列急救措施，我們希望更好地確保不再發生類似情況。”

同時 GitHub 也表示接下來將解決由此導致的資料不一致問題。

詳細分析與事件時間線請查閱 GitHub 公告 。