聊聊GitHub做好MySQL高可用性的方法

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 名稱會先配置時間。跨平台故障轉移意味著需要更多的中斷時間：客戶端需要花更多時間去識別新的主伺服器。

僅這些限制就足以推動我們尋找新的解決方案，但需要考慮的是:

• 主伺服器使用pt-heartbeat 服務去自註入存取心跳，目的是延遲測量和節流控制。該服務必須在新的主伺服器開始。如果可以，在更換主伺服器的同時會關閉舊的主伺服器這項服務。

• 同樣地，Pseudo-GTID 是由伺服器自行管理的。它需要在新的主伺服器開始，最好在舊的主伺服器上停止。

• 新的主伺服器將設定為可寫入。如果可以的話，舊的主伺服器將設定為 read_only(只讀)。

這些額外的步驟是導致總停機時間的一個因素，並引入了它們自己的故障和摩擦。

解決方案是有效的，GitHub 已經成功地進行了 MySQL 故障轉移，但是我們希望 HA 在以下方面有所改進:

##與資料中心無關。
• 容忍資料中心故障。
• 刪除不可靠的協作工作流程。
• 減少總停機時間。
• 盡可能的，有無損的故障切換。

GitHub 的高可用解決方案：orchestrator ，Consul ， GLB

新策略可以改進，解決或優化上面提到的問題。現在高可用的組成如下：

• orchestrator 執行偵測和故障轉移。如連結中所描述的採用混合資料中心 orchestrator/raft 。
Hashicorp 的
• Consul 作為服務發現。
• GLB/HAProxy 作為客戶端與寫入節點之間的代理。 GLB 指導是開源的.
• anycast 作為網路路由。

新的結構移除了 VIP 和 DNS 。在引入更多的組件的同時，我們能夠解藕這些組件，並且簡化相關的任務，並且易於利用可靠且穩定的解決方案。詳情如下。

正常過程

正常情況，應用透過 GLB/HAProxy 連接到寫入節點。

應用程式感知不到 master 身分。之前，都是使用名稱。例如

cluster1 的 master 是 mysql-writer-1.github.net。現在的結構中，這個名稱被  anycast IP 取代。

透過 

anycast，名稱被相同的 IP 取代，但流量由客戶端的位置來進行路由。特別的，當資料中心有 GLB 時，高可用負載平衡器部署在不同的盒子內。 通往 mysql-writer-1.github.net 的流量都被引流到本地的資料中心的 GLB 叢集。這樣所有的客戶端都由本地代理服務。

在  HAProxy 頂層使用 GLB。 HAProxy 擁有  寫入池 ：每個 MySQL 叢集都有一個。每個池都有一個後端服務：叢集 master 節點。資料中心的所有 GLB/HAProxy 盒子都有相同的池子，表示這些池子有相同的後端服務對應。所以如果應用期望寫  mysql-writer-1.github.net，則不同關心連接哪個 GLB 服務。它會導向實際的 cluster1 master 節點。

就應用程式連接 GLB ，發現服務而言，不需要重新發現。 GLB 負責全部流量導向正確的目的地。

GLB 是怎麼知道哪些服務是後端，以及如何告知 GLB 變化的呢？

Discovery via Consul

Consul 以服務發現解決方案而聞名，也提供 DNS 服務。然而，在我們的解決方案中，我們將其用作高度可用的鍵值 (KV) 儲存。

在 Consul 的 KV 儲存中，我們寫入叢集主節點的身份。對於每個集群，都有一組 KV 條目指示集群的主設備 fqdn、連接埠、ipv4、ipv6。

每個 GLB/HAProxy 節點都運行 consul-template：一個監聽 Consul 資料變化的服務（在我們的例子中：群集主資料的變化）。 consul-template 產生一個有效的設定文件，並且能夠在配置更改時重新載入 HAProxy。

因此，每個GLB/HAProxy 機器都會觀察到Consul 對master 身分的更改，然後它會重新配置自己，將新的master 設定為叢集後端池中的單一實體，並重新載入以反映這些變更。

在 GitHub，我們在每個資料中心都有一個 Consul 設置，並且每個設置都是高度可用的。但是，這些設定彼此獨立。它們不會在彼此之間複製，也不會共享任何資料。

Consul 如何獲知變化，資訊如何跨 DC 分發？

orchestrator/raft

#我們執行一個orchestrator/raft 設定：orchestrator 節點透過raft 機制相互通訊。每個資料中心有一個或兩個 orchestrator 節點。

orchestrator 負責故障偵測和 MySQL 故障切換，並將 master 的變更傳達給 Consul 。故障切換由單一orchestrator/raft leader 節點操作，但是叢集現在擁有新master 的訊息透過raft 機制傳播到所有orchestrator節點。

當 orchestrator 節點收到 master 變更的訊息時，它們各自與本地 Consul 設定通訊：它們各自呼叫 KV 寫入。具有多個 orchestrator 代理程式的 DC 將多次（相同）寫入 Consul。

把流程組合起來

在master 崩潰的情況下:

• orchestrator 節點偵測故障.
• orchestrator/raft leader 節點開始恢復，一個資料伺服器被更新為master 。
• orchestrator/raft 公告所有 raft 子叢集節點變更了 master 。
• 每個 orchestrator/raft 成員收到一個 leader 節點 變更的通知。它們每個成員都把新的 master 更新到本地 Consul KV 儲存。
• 每個 GLB/HAProxy 都運行了 consul-template，該模版觀察 Consul KV 儲存中的更改，並重新配置和重新載入 HAProxy。
• 客戶端流量被重定向到新的 master 。

每個元件都有明確的責任歸屬，整個設計既是解耦的，又是簡化的。 orchestrator 不知道負載平衡器。 Consul 不需要知道訊息的來源。代理只關心 Consul。客戶端只關心代理。

此外:

• 沒有更改要傳播的 DNS
• 沒有 TTL。
• 串流沒有和故障的 master 合作，它很大程度上被忽略了。

其他詳細資訊

為了進一步保護流量，我們還有以下內容：

• HAProxy 配置了一個非常短的 hard-stop-after。當它重新載入寫入器池中的新後端伺服器時，它會自動終止與舊主伺服器的任何現有連線。
  • 使用 hard-stop-after，我們甚至不需要客戶的合作，這減輕了腦裂的情況。值得注意的是，這不是封閉的，並且在我們終止舊連接之前一段時間過去了。但是在某個時間點之後，我們會感到很舒服，並且不會期待任何令人討厭的驚喜。
• 我們並沒有嚴格要求 Consul 隨時待命。事實上，我們只需要它在故障轉移時可用。如果 Consul 發生故障，GLB 將繼續使用最後的已知值進行操作，並且不會採取劇烈行動。
• GLB 設定為驗證新提升的 master 的身份。與我們的 上下文感知 MySQL 池 類似，會在後端伺服器上進行檢查，以確認它確實是寫入器節點。如果我們碰巧在 Consul 中刪除了 master 的身份，沒問題；空條目被忽略。如果我們在 Consul 中錯誤地寫了一個非主伺服器的名字，沒有問題； GLB 將拒絕更新它並繼續以最後一個已知狀態運行。

我們將在以下部分進一步解決問題並追求 HA 目標。

Orchestrator/RAFT 故障偵測

##orchestrator 使用整體方法 來偵測故障，因此非常可靠。我們沒有觀察到誤報：我們沒有過早的故障轉移，因此不會遭受不必要的停機時間。

orchestrator/raft 進一步解決了完整的 DC 網路隔離（又稱 DC 圍欄）的情況。 DC 網路隔離可能會導致混亂：該 DC 內的伺服器可以相互通訊。是它們與其他 DC 網路隔離，還是其他 DC 被網路隔離？

在 orchestrator/raft 設定中，raft 領導節點是執行故障轉移的節點。領導者是獲得組中大多數人（法定人數）支持的節點。我們的協調器節點部署是這樣的，沒有一個資料中心佔多數，任何 n-1 資料中心都可以。

在 DC 網路完全隔離的情況下，此 DC 中的 orchestrator 節點會與其他 DC 中的對等節點斷開連接。因此，孤立 DC 中的 orchestrator 節點不能成為 raft 叢集的領導者。如果任何這樣的節點恰好是領導者，它就會下台。將從任何其他 DC 中分配新的領導者。該領導者將得到所有其他能夠相互溝通的 DC 的支持。

因此，發號施令的 orchestrator 節點將是網路隔離資料中心以外的節點。如果一個獨立的 DC 中有一個主控，orchestrator 將啟動故障轉移，用其中一個可用 DC 中的伺服器取代它。我們透過將決策委託給非隔離 DC 中的法定人數來緩解 DC 隔離。

更快的廣而告之

#透過更快地公佈主要變更可以進一步減少總停機時間。如何實現這一點？

當 orchestrator 開始故障轉移時，它會觀察可用於提升的伺服器佇列。理解複製規則並遵守提示和限制，它能夠對最佳操作過程做出有根據的決策。

它可能認識到，一個可用於促銷的伺服器也是一個理想的候選人，例如:

• 沒有什麼可以阻止伺服器的升級(用戶可能已經暗示這樣的伺服器是首選的升級) ，以及
• 預計伺服器能夠將其所有兄弟伺服器作為副本。

在這種情況下，orchestrator 首先將伺服器設定為可寫的，然後立即宣傳伺服器的推廣(在我們的例子裡是寫到Consul KV 儲存中) ，即使非同步開始修復複製樹，這個操作通常需要幾秒鐘。

很可能在 GLB 伺服器完全重新載入之前，複製樹已經完好無損，但並不嚴格要求它。伺服器很好接收寫！

半同步複製

在MySQL 的半同步複製中，主伺服器不會確認交易提交，直到已知變更已傳送到一個或多個副本。它提供了一種實現無損故障轉移的方法：應用於主伺服器的任何變更要么應用於主伺服器，要么等待應用於其中一個副本。

一致性伴隨著成本：可用性的風險。如果沒有副本確認收到更改，主伺服器將阻塞並停止寫入操作。幸運的是，有一個超時配置，超時後主伺服器可以恢復到非同步複製模式，從而使寫入操作再次可用。

我們已經將超時設定為一個合理的低值: 500ms。將變更從主 DC 副本傳送到本機 DC 副本，通常也傳送到遠端 DC，這已經足夠了。透過這個超時，我們可以觀察到完美的半同步行為 (沒有退回到異步複製) ，並且在確認失敗的情況下可以輕鬆地使用非常短的阻塞週期。

我們在本地 DC 副本上啟用半同步，在主伺服器死亡的情況下，我們期望 (儘管不嚴格執行) 無損故障轉移。完全直流故障的無損故障轉移是昂貴的，我們並不期望它。

在嘗試半同步超時的同時，我們也觀察到了一個對我們有利的行為：在主要失敗的情況下，我們能夠影響理想候選對象的身份。透過在指定的伺服器上啟用半同步，並將它們標記為候選伺服器，我們能夠透過影響故障的結果來減少總停機時間。在我們的實驗中，我們觀察到我們通常最終會得到理想的候選對象，從而快速地廣而告之。

注入心跳

我們沒有在升級/ 降級的主機上管理pt-heart 服務的啟動/ 關閉，而是選擇在任何時候在任何地方運行它。這需要進行一些修補，以便使 pt-heart 能夠適應伺服器來回更改 read_only(只讀狀態) 或完全崩潰的情況。

在我們目前的設定中，pt-heart 服務在主伺服器和副本上運行。在主機上，它們會產生心跳事件。在副本上，他們識別伺服器是 read_only(只讀) 的，並定期重新檢查它們的狀態。一旦伺服器被提升為主伺服器，該伺服器上的 pt-heart 就會將伺服器標識為可寫入的，並開始注入心跳事件。

orchestrator 所有權委託

##我們進一步orchestrator:

• 注入Pseudo-GTID ,
• 將提升的master 設定為可寫，清除其複製狀態，以及，
• 如果可能，將舊主伺服器設為read_only。

在所有的新 master 的基礎上，這減少了摩擦。一個剛剛被提升的 master 顯然應該是有生命力，並且可以被接受的，否則我們不會提升它。因此，讓 orchestrator 直接講更改應用於提升的 msater 是有意義的。

orchestrator 所有權委託

##我們進一步orchestrator：

• Pseudo-GTID 注入，
• 將提升的master 設定為可寫，清除其複製狀態，以及，
• 如果可能，將舊的master 設定為read_only。

在所有的新 master 的基礎上，這減少了摩擦。一個剛剛被提升的 master 顯然應該是有活力，並且可以被接受的，否則我們不會提升它。因此，讓 orchestrator 將變更直接套用於提升的 msater 是有意義的。

限制和缺點

代理層使應用程式不知道主伺服器的身份，但它也掩蓋了應用程式的主伺服器的身份。所有主要看到的都是來自代理層的連接，我們會失去關於連接的實際來源的資訊。

隨著分散式系統的發展，我們仍然面臨著未處理的場景。

值得注意的是，在一個資料中心隔離場景中，假設主伺服器位於隔離的 DC 中，該 DC 中的應用程式仍然能夠寫入主伺服器。一旦網路恢復，這可能導致狀態不一致。我們正在努力減輕這種分裂的大腦實施一個可靠的 STONITH 從內部非常孤立的 DC。和以前一樣，在摧毀初選之前還需要一段時間，而且可能會有一段短暫的腦分裂。避免大腦分裂的操作成本非常高。

還有更多的情況：在故障轉移時停止領事服務；部分直流隔離；其他情況。我們知道這種性質的分散式系統不可能堵住所有的漏洞，所以我們把重點放在最重要的案例上。

結論

我們的協調器 / GLB/Consul 為我們提供了:

• 可靠的故障檢測，
• 與資料中心無關的故障轉移，
• 通常無損的故障轉移，
• 資料中心網路隔離支持，
• 緩解裂腦(更多工作成果),
• 不依賴合作，
• 在大多數情況下，總中斷時間在10 and 13 seconds 之間。
  • 在不常見的情況下，我們最多可以看到20 seconds 的總停機時間，在極端情況下則可以看到最多 25 seconds 的停機時間。

結論

業務流程/ 代理程式/ 服務發現範例在分離的體系結構中使用眾所周知和受信任的元件，這使得部署、操作和觀察變得更加容易，並且每個元件都可以獨立向上或向下擴展。我們能不斷的測試設定並尋求改進。

原文網址：https://github.blog/2018-06-20-mysql-high-availability-at-github/

翻譯網址：https://learnku .com/mysql/t/36820

【相關推薦：mysql影片教學】

以上是聊聊GitHub做好MySQL高可用性的方法的詳細內容。更多資訊請關注PHP中文網其他相關文章！