GitHub是怎么做好 MySQL 高可用性的？下面本篇文章就來帶大家分享一下，希望對大家有所幫助。

程序員必備接口測試調試工具：立即使用
Apipost = Postman + Swagger + Mock + Jmeter
Api設計、調試、文檔、自動化測試工具
后端、前端、測試，同時在線協作，內容實時同步

Github 使用 MySQL 數據庫作為所有非 git 事務的數據存儲。數據庫的可用性對 Github 的正常運行而言至關重要。無論是 Github 網站本身，還是 Github API，身份驗證服務等都需要訪問數據庫。Github 運行了多個數據庫集群用于支撐不同的服務于任務。數據庫的架構采用的是傳統的主從結構，集群中一個節點（主庫）支持寫訪問，其余的節點（從庫）同步主庫的變更，支持讀服務。

主庫的可用性至關重要。一旦主庫宕機，集群將不能夠支持數據寫入服務：任何需要保存的數據都無法寫入到數據庫保存。最終導致 Github 上任何變更，例如代碼提交，提問，用戶創建，代碼 review，創建倉庫等操作都無法完成。

為了保證業務的正常運行，我們自然需要在集群中有一個可用的支持寫入的數據庫節點。同時，我們也必須能夠快速的發現可用的可寫入服務數據庫節點。

就是說，在異常情況下，假如主庫宕機的場景，我們必須確保新的主庫能夠立刻上線支持服務，同時保證集群中其他節點能夠快速識別到新的主庫。故障檢測，主庫遷移以及集群其他數據節點識別新主庫的總時間構成了服務中斷的總時間。

這篇文章說明了 GitHub 的 MySQL 高可用性和主庫服務發現解決方案，該解決方案使我們能夠可靠地運行跨數據中心的操作，能夠容忍數據中心的隔離，并縮短在出現故障時停機時間。

高可用性的實現#

本篇文章描述的解決方案是在以前 Github 高可用方案上的改進版本。正如前面說到的一樣，MySQL 的高可用策略必須適應業務的變化。我們期望 MySQL 以及 GitHub 上其他的服務都有能夠應對變化的高可用解決方案。

當設計高可用以及服務發現系統方案的時候，從下面幾個問題出發，也許能夠幫助我們快速找到合適的解決方案：

• 最大允許的服務中斷的時間是多少？
• 服務中斷檢測的準確性怎么樣？是否能夠允許服務中斷檢測誤報（會導致過早故障轉移）？
• 故障轉移的可靠性怎么樣？什么情況會導致故障轉移失敗？
• 這個方案能否在跨數據中心實現，以及如何實現的？ 在不同的網絡狀況下會怎么樣，延遲高，或延遲低的情況會怎么樣？
• 這個解決方案能否承受整個數據中心（DC）的故障 或者網絡隔離的情況？
• 有什么機制防止 HA 集群腦裂情況（在一個整體的系統，聯系著的兩個節點分裂為兩個獨立節點，這兩個節點爭搶共享資源寫入數據的情況）？
• 能否容忍數據丟失？容忍丟失程度是多少？

為了說明上面的幾個問題，我們先來看一下我們之前的高可用方案，以及我們為什么要改進它。

摒棄基于 VIP 和 DNS 的發現機制#

在之前的方案中，應用了下面的技術方案：

• 使用 orchestrator 作為故障檢測遷移方案。
• 采用 VIP 和 DNS 方式作為主節點發現方案。

客戶端通過節點名稱，例如 mysql-writer-1.github.net，解析成主節點的虛擬 IP 地址 (VIP)，從而找到主節點。

因此，正常情況下，客戶端可以通過對節點名稱的解析，連接到對應 IP 的主節點上。

考慮夸三個數據中心的拓撲結構的情況：

一旦主庫異常，必須將其中的一個數據副本服務器更新為主庫服務器。

orchestrator 會檢測異常，選出新的主庫，然后重新分配數據庫的名稱以及虛擬 IP (VIP)。客戶端本身不知道主庫的變更，客戶端有的信息只是主庫的名稱，因此這個名稱必須能夠解析到新的主庫服務器。考慮下面的問題：

VIP 需要協商：虛擬 IP 由數據庫本身所持有。 服務器必須發送 ARP 請求，才能夠占有或釋放 VIP。 在新的數據庫分配新的 VIP 之前，舊的服務器必須先釋放其占有的 VIP。這個過程會產生一些異常問題:

• 故障轉移的順序，首先是請求故障機器釋放 VIP，然后聯系新的主庫機器分配 VIP。但是，如果故障機器本身不能訪問，或者說拒絕釋放 VIP 呢？ 考慮到機器故障的場景，故障機器不會立即響應或根本就不會響應釋放 VIP 的請求，整個過程有下面兩個問題：
  • 腦裂情況：如果有兩個主機持有相同的 VIP 的情況，不同的客戶端根據最短的網絡鏈路將會連接到不同的主機上。
  • 整個 VIP 重新分配過程依賴兩個獨立服務器的相互協調，而且設置過程是不可靠的。
• 即使故障機器正常釋放 VIP，整個流程也是非常耗時的，因為切換過程還需要連接故障機器。
• 即使 VIP 重新分配，客戶端已有的連接不會自動斷開舊的故障機器，從而使得整個系統產生腦裂的情況。

在我們實際設置 VIP 時，VIP 還受實際物理位置的約束。這主要取決于交換機或者路由器所在。因此，我們只能在同一本地服務器上重新分配 VIP。特別是在某些情況下，我們無法將 VIP 分配給其他數據中心的服務器，而必須進行 DNS 更改。

• DNS 更改需要更長的時間傳播。客戶端緩存 DNS 名稱會先配置時間。跨平臺故障轉移意味著需要