• 1.背景
  • MySQL叢集部署情況
  • Orchestrator部署情況
• 2.事情的經過
• 3.存在的隱患
• 4.參考

這起事故雖然發生在2018年，已經過去了很長時間，但其中的問題和帶來的啟示永不過時，拿來分析，具有很重要的意義。

1.背景

GitHub主要有東、西海岸兩個資料中心，以及其他三個公有云資料中心。本次事故主要涉及東、西海岸兩個資料中心。
並且，在GitHub，使用的Orchestrator作為MySQL叢集拓撲管理和主庫高可用工具。

GitHub 的MySQL叢集和Orchestrator高可用服務部署情況如下。

MySQL叢集部署情況

MySQL叢集是一主 4從：

• 主庫和2個從庫在東海岸
• 2個從庫在西海岸

為了大規模提高擴充套件性，已經使用讀寫分離。寫操作在主庫上，大部分讀操作在從庫上。

Orchestrator部署情況

Orchestrator高可用服務以分散式叢集方式部署，跨東西海岸。

2.事情的經過

東海岸更換光纖裝置，導致東海岸資料中心與外界網路斷開，43s後，網路恢復。

這個短暫的網路斷開，引起了一連串的事故。

這些事故主要包括以下。

1）.ORC leader漂移

ORC leader 原來是在東海岸，網路斷開，觸發leader 漂移到西海岸。

2）.MySQL叢集主庫切換後，資料不一致

ORC leader 漂移到西海岸後，發現主庫探測異常，2個東海岸從庫探測異常，2個西海岸從庫複製斷開，判定為DeadMasterAndSomeSlaves，觸發MySQL叢集主庫由東海岸切到西海岸。寫入流量開始匯入到西海岸主庫。

在切換過程，東海岸的2個從庫無法change到新主庫，成為丟失副本。切換後，實際叢集拓撲，只包括一主一從，且都在西海岸。

切換後，發現東海岸有部分寫入沒有同步到西海岸。東、西海岸資料出現不一致。
 

出現問題後，為了保證資料一致性，GitHub 首先進行了服務降級，暫停了部分服務。

接著，在東海岸重新建立新主庫。這其中包括，從備份恢復資料、從東西海岸同步資料等。

再接著，將主庫切回東海岸。處理佇列中的資料。

最後，網站對外提供服務。

最最後，解決資料不一致。通過與使用者溝通，恢復丟失的資料。

3.存在的隱患

通過這個事故，可以看到幾個隱患。

1）.ORC 跨Region部署

跨Region 的網路抖動，會導致ORC leader漂移。如果leader正在進行切換，leader漂移，會導致切換進行到一半。

解決方案：ORC 服務不跨Region部署。

2）.MySQL叢集跨Region部署

跨Region部署，一方面，可以提供資料遠端備份。另一方面，複製可能存在延遲，如果發生類似這個故障場景的切換，會造成資料不一致。

3）. 為什麼恢復資料的方式是通過備份進行恢復？

通過備份恢復資料的問題是，時間太長。首先是備份存在公有云，需要遠端下載，其次是解壓、校驗和應用資料，耗費時間。

為什麼不將東海岸的其中一個從庫，回退部分資料，接著同步西海岸新寫入的資料，之後，就可以使用了吧？

4.參考

2018-10-30-oct21-post-incident-analysis

GitHub 服務中斷 24 小時 11 分鐘事故分析報告