MySQL叢集資源競用造成服務不穩，GitHub難題待解

從3月16日開始，GitHub平臺因為資料庫問題，接連幾天出現服務不穩的狀況，而官方現在提出說明，表示服務不穩的狀況，是因為MySQL叢集中資源競用所造成，因此在服務高峰的時候，影響GitHub大量服務和功能的效能。目前GitHub正在努力解決這個問題，會於之後的可用性報告進一步說明。

GitHub在3月16日22點06分的時候，發現MySQL資料庫在高峰時段負載增加，而這導致資料庫代理達到了最大連接數，官方解釋，這個資料庫由多個服務共用，並接受大量的讀寫流量，因此在中斷期間，所有寫入操作都無法進行，包括Git操作、webhook、拉取請求、API請求、問題發布、GitHub Packages、GitHub Codespaces、GitHub Actions和GitHub Pages服務。

官方指出，該事件似乎與峰值負載，再加上特定情況下的查詢效能不佳有關。GitHub的MySQL叢集使用典型的主要與副本執行個體配置，以實現高可用性，其中只有單一主要節點能夠執行寫入，叢集的其他部分則由提供讀取流量的副本執行個體組成，GitHub藉由故障轉移使用健康的副本執行個體，來解決服務中斷的問題，並對這段時間與查詢效能相關的流量模式展開調查。

但是相同的問題卻在3月17日又出現一次，官方觀察到MySQL叢集，出現與前一天相同的高峰流量模式和負載，由於還無法查明和解決出現查詢效能問題的根本原因，官方決定在問題變嚴重之前先採取行動，主動進行故障轉移，但沒想到這個舉動產生另一種負載模式，反而在主節點上造成連接問題，儘管GitHub重置連接，但應用程式仍無法連接到MySQL叢集。透過找出負載模式後，官方實作索引來解決主要節點的效能問題。

接著在3月22日和23日都接連發生同樣事故，官方在資料庫代理中啟用記憶體分析，希望進一步掌握高峰負載期間所出現的效能特徵，並且限制webhook流量避免出現高峰流量，而這兩天，GitHub同樣必須在連接發生中斷後，執行故障轉移來恢復服務。

GitHub在高峰負載時段，稽核特定資料庫的負載模式，並根據稽核的結果，進行一系列效能修復工作，這些工作包括將流量轉移到其他資料庫，以減少負載並且加速故障轉移的時間，並且審查變更管理程序，官方解釋，因為變更管理程序，與生產時中高負載期間的監控和變更有關。

GitHub還未找出發生連接問題的真正原因，目前先採取的措施，只能確保他們能優雅的處理中斷，並且盡可能減少停機時間。