共計 7588 個字符，預(yù)計需要花費 19 分鐘才能閱讀完成。

這篇文章主要介紹了 GitHub 是如何做好 MySQL 高可用性的的相關(guān)知識，內(nèi)容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇 GitHub 是如何做好 MySQL 高可用性的文章都會有所收獲，下面我們一起來看看吧。

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

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

為了保證業(yè)務(wù)的正常運行，我們自然需要在集群中有一個可用的支持寫入的數(shù)據(jù)庫節(jié)點。同時，我們也必須能夠快速的發(fā)現(xiàn)可用的可寫入服務(wù)數(shù)據(jù)庫節(jié)點。

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

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

高可用性的實現(xiàn) #

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

當設(shè)計高可用以及服務(wù)發(fā)現(xiàn)系統(tǒng)方案的時候，從下面幾個問題出發(fā)，也許能夠幫助我們快速找到合適的解決方案：

最大允許的服務(wù)中斷的時間是多少？

服務(wù)中斷檢測的準確性怎么樣？是否能夠允許服務(wù)中斷檢測誤報（會導(dǎo)致過早故障轉(zhuǎn)移）？

故障轉(zhuǎn)移的可靠性怎么樣？什么情況會導(dǎo)致故障轉(zhuǎn)移失敗？

這個方案能否在跨數(shù)據(jù)中心實現(xiàn)，以及如何實現(xiàn)的？在不同的網(wǎng)絡(luò)狀況下會怎么樣，延遲高，或延遲低的情況會怎么樣？

這個解決方案能否承受整個數(shù)據(jù)中心（DC）的故障 或者網(wǎng)絡(luò)隔離的情況？

有什么機制防止 HA 集群腦裂情況（在一個整體的系統(tǒng)，聯(lián)系著的兩個節(jié)點分裂為兩個獨立節(jié)點，這兩個節(jié)點爭搶共享資源寫入數(shù)據(jù)的情況）？

能否容忍數(shù)據(jù)丟失？容忍丟失程度是多少？

為了說明上面的幾個問題，我們先來看一下我們之前的高可用方案，以及我們?yōu)槭裁匆倪M它。

摒棄基于 VIP 和 DNS 的發(fā)現(xiàn)機制 #

在之前的方案中，應(yīng)用了下面的技術(shù)方案：

使用 orchestrator 作為故障檢測遷移方案。

采用 VIP 和 DNS 方式作為主節(jié)點發(fā)現(xiàn)方案。

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

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

考慮夸三個數(shù)據(jù)中心的拓撲結(jié)構(gòu)的情況：

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

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

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

故障轉(zhuǎn)移的順序，首先是請求故障機器釋放 VIP，然后聯(lián)系新的主庫機器分配 VIP。但是，如果故障機器本身不能訪問，或者說拒絕釋放 VIP 呢？考慮到機器故障的場景，故障機器不會立即響應(yīng)或根本就不會響應(yīng)釋放 VIP 的請求，整個過程有下面兩個問題：

腦裂情況：如果有兩個主機持有相同的 VIP 的情況，不同的客戶端根據(jù)最短的網(wǎng)絡(luò)鏈路將會連接到不同的主機上。

整個 VIP 重新分配過程依賴兩個獨立服務(wù)器的相互協(xié)調(diào)，而且設(shè)置過程是不可靠的。

即使故障機器正常釋放 VIP，整個流程也是非常耗時的，因為切換過程還需要連接故障機器。

即使 VIP 重新分配，客戶端已有的連接不會自動斷開舊的故障機器，從而使得整個系統(tǒng)產(chǎn)生腦裂的情況。

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

DNS 更改需要更長的時間傳播。客戶端緩存 DNS 名稱會先配置時間。跨平臺故障轉(zhuǎn)移意味著需要更多的中斷時間：客戶端需要花費更多時間去識別新的主服務(wù)器。

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

主服務(wù)器使用 pt-heartbeat 服務(wù)去自注入訪問心跳，目的是延遲測量和節(jié)流控制。該服務(wù)必須在新的主服務(wù)器開始。如果可以，在更換主服務(wù)器的同時會關(guān)閉舊的主服務(wù)器這項服務(wù)。

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

新的主服務(wù)器將設(shè)置為可寫入。如果可以的話，舊的主服務(wù)器將設(shè)置為 read_only(只讀)。

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

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

與數(shù)據(jù)中心無關(guān)。

容忍數(shù)據(jù)中心故障。

刪除不可靠的協(xié)作工作流。

減少總停機時間。

盡可能的，有無損的故障切換。

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

新策略可以改進，解決或者優(yōu)化上面提到的問題。現(xiàn)在高可用的組成如下：

orchestrator 執(zhí)行檢測和故障轉(zhuǎn)移。如鏈接中描述的那樣采用混合數(shù)據(jù)中心 orchestrator/raft。

Hashicorp 的 Consul 作為服務(wù)發(fā)現(xiàn)。

GLB/HAProxy 作為客戶端和寫入節(jié)點之間的代理。GLB 指導(dǎo)是開源的.

anycast 作為網(wǎng)絡(luò)路由。

新的結(jié)構(gòu)移除了 VIP 和 DNS。在引入更多的組件的同時，我們能夠解藕這些組件，并且簡化相關(guān)的任務(wù)，并易于利用可靠穩(wěn)定的解決方案。詳情如下。

正常過程

正常情況，應(yīng)用通過 GLB/HAProxy 連接到寫入節(jié)點。

應(yīng)用感知不到 master 身份。之前，都是使用名稱。例如 cluster1 的 master 是 mysql-writer-1.github.net。現(xiàn)在的結(jié)構(gòu)中，這個名稱被  anycast IP 取代。

通過 anycast，名稱被相同的 IP 取代，但流量由客戶端的位置來進行路由。特別的，當數(shù)據(jù)中心有 GLB 時，高可用負載均衡器部署在不同的盒子內(nèi)。通向 mysql-writer-1.github.net 的流量都被引流到本地的數(shù)據(jù)中心的 GLB 集群。這樣所有的客戶端都由本地代理服務(wù)。

在  HAProxy 頂層使用 GLB。HAProxy 擁有   寫入池：每個 MySQL 集群都有一個。每個池都有一個后端服務(wù)：集群 master 節(jié)點。數(shù)據(jù)中心的所有 GLB/HAProxy 盒子都有相同的池子，表示這些池子有相同的后端服務(wù)對應(yīng)。所以如果應(yīng)用期望寫  mysql-writer-1.github.net，不同關(guān)心連接哪個 GLB 服務(wù)。它會導(dǎo)向?qū)嶋H的 cluster1 master 節(jié)點。

就應(yīng)用連接 GLB，發(fā)現(xiàn)服務(wù)而言，不需要重新發(fā)現(xiàn)。GLB 負責全部流量導(dǎo)向正確的目的地。

GLB 是怎么知道哪些服務(wù)是后端，以及如何告知 GLB 變化的呢？

Discovery via Consul

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

在 Consul 的 KV 存儲中，我們寫入集群主節(jié)點的身份。對于每個集群，都有一組 KV 條目指示集群的主設(shè)備 fqdn、端口、ipv4、ipv6。

每個 GLB/HAProxy 節(jié)點都運行 consul-template：一個監(jiān)聽 Consul 數(shù)據(jù)變化的服務(wù)（在我們的例子中：集群主數(shù)據(jù)的變化）。consul-template 生成一個有效的配置文件，并且能夠在配置更改時重新加載 HAProxy。

因此，每個 GLB/HAProxy 機器都會觀察到 Consul 對 master 身份的更改，然后它會重新配置自己，將新的 master 設(shè)置為集群后端池中的單個實體，并重新加載以反映這些更改。

在 GitHub，我們在每個數(shù)據(jù)中心都有一個 Consul 設(shè)置，并且每個設(shè)置都是高度可用的。但是，這些設(shè)置彼此獨立。它們不會在彼此之間復(fù)制，也不會共享任何數(shù)據(jù)。

Consul 如何獲知變化，信息如何跨 DC 分發(fā)？

orchestrator/raft

我們運行一個 orchestrator/raft 設(shè)置：orchestrator 節(jié)點通過 raft 機制相互通信。每個數(shù)據(jù)中心有一個或兩個 orchestrator 節(jié)點。

orchestrator 負責故障檢測和 MySQL 故障切換，以及將 master 的變更傳達給 Consul。故障切換由單個 orchestrator/raft leader 節(jié)點操作，但是集群現(xiàn)在擁有新 master 的消息通過 raft 機制傳播到所有 orchestrator 節(jié)點。

當 orchestrator 節(jié)點收到 master 變更的消息時，它們各自與本地 Consul 設(shè)置通信：它們各自調(diào)用 KV 寫入。具有多個 orchestrator 代理的 DC 將多次（相同）寫入 Consul。

把流程組合起來

在 master 崩潰的情況下:

orchestrator 節(jié)點檢測故障.

orchestrator/raft leader 節(jié)點開始恢復(fù)，一個數(shù)據(jù)服務(wù)器被更新為 master。

orchestrator/raft 公告所有 raft 子集群節(jié)點變更了 master。

每個 orchestrator/raft 成員收到一個 leader 節(jié)點 變更的通知。它們每個成員都把新的 master 更新到本地 Consul KV 存儲中。

每個 GLB/HAProxy 都運行了 consul-template，該模版觀察 Consul KV 存儲中的更改，并重新配置和重新加載 HAProxy。

客戶端流量被重定向到新的 master。

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

此外:

沒有更改要傳播的 DNS

沒有 TTL。

流沒有和故障的 master 合作，它很大程度被忽略了。

其他詳細信息

為了進一步保護流量，我們還有以下內(nèi)容：

HAProxy 配置了一個非常短的 hard-stop-after。當它重新加載寫入器池中的新后端服務(wù)器時，它會自動終止與舊主服務(wù)器的任何現(xiàn)有連接。

使用 hard-stop-after，我們甚至不需要客戶的合作，這減輕了腦裂的情況。值得注意的是，這不是封閉的，并且在我們終止舊連接之前一段時間過去了。但是在某個時間點之后，我們會感到很舒服，并且不會期待任何令人討厭的驚喜。

我們并不嚴格要求 Consul 隨時待命。事實上，我們只需要它在故障轉(zhuǎn)移時可用。如果 Consul 發(fā)生故障，GLB 將繼續(xù)使用最后的已知值進行操作，并且不會采取劇烈行動。

GLB 設(shè)置為驗證新提升的 master 的身份。與我們的 上下文感知 MySQL 池 類似，會在后端服務(wù)器上進行檢查，以確認它確實是寫入器節(jié)點。如果我們碰巧在 Consul 中刪除了 master 的身份，沒問題；空條目被忽略。如果我們在 Consul 中錯誤地寫了一個非主服務(wù)器的名字，沒有問題；GLB 將拒絕更新它并繼續(xù)以最后一個已知狀態(tài)運行。

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

Orchestrator/RAFT 故障檢測

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

orchestrator/raft 進一步解決了完整的 DC 網(wǎng)絡(luò)隔離（又名 DC 圍欄）的情況。DC 網(wǎng)絡(luò)隔離可能會導(dǎo)致混亂：該 DC 內(nèi)的服務(wù)器可以相互通信。是它們與其他 DC 網(wǎng)絡(luò)隔離，還是其他 DC 被網(wǎng)絡(luò)隔離？

在 orchestrator/raft 設(shè)置中，raft 領(lǐng)導(dǎo)節(jié)點是運行故障轉(zhuǎn)移的節(jié)點。領(lǐng)導(dǎo)者是獲得組中大多數(shù)人（法定人數(shù)）支持的節(jié)點。我們的協(xié)調(diào)器節(jié)點部署是這樣的，沒有一個數(shù)據(jù)中心占多數(shù)，任何 n-1 數(shù)據(jù)中心都可以。

在 DC 網(wǎng)絡(luò)完全隔離的情況下，該 DC 中的 orchestrator 節(jié)點會與其他 DC 中的對等節(jié)點斷開連接。因此，孤立 DC 中的 orchestrator 節(jié)點不能成為 raft 集群的領(lǐng)導(dǎo)者。如果任何這樣的節(jié)點恰好是領(lǐng)導(dǎo)者，它就會下臺。將從任何其他 DC 中分配新的領(lǐng)導(dǎo)者。該領(lǐng)導(dǎo)者將得到所有其他能夠相互通信的 DC 的支持。

因此，發(fā)號施令的 orchestrator 節(jié)點將是網(wǎng)絡(luò)隔離數(shù)據(jù)中心之外的節(jié)點。如果一個獨立的 DC 中有一個主控，orchestrator 將啟動故障轉(zhuǎn)移，用其中一個可用 DC 中的服務(wù)器替換它。我們通過將決策委托給非隔離 DC 中的法定人數(shù)來緩解 DC 隔離。

更快的廣而告之

通過更快地公布主要更改可以進一步減少總停機時間。如何實現(xiàn)這一點？

當 orchestrator 開始故障轉(zhuǎn)移時，它觀察可用于提升的服務(wù)器隊列。理解復(fù)制規(guī)則并遵守提示和限制，它能夠?qū)ψ罴巡僮鬟^程做出有根據(jù)的決策。

它可能認識到，一個可用于促銷的服務(wù)器也是一個理想的候選人，例如:

沒有什么可以阻止服務(wù)器的升級 (用戶可能已經(jīng)暗示這樣的服務(wù)器是首選的升級)，以及

預(yù)計服務(wù)器能夠?qū)⑵渌行值芊?wù)器作為副本。

在這種情況下，orchestrator 首先將服務(wù)器設(shè)置為可寫的，然后立即宣傳服務(wù)器的推廣 (在我們的例子里是寫到 Consul KV 存儲中)，即使異步開始修復(fù)復(fù)制樹，這個操作通常需要幾秒鐘。

很可能在 GLB 服務(wù)器完全重新加載之前，復(fù)制樹已經(jīng)完好無損，但是并不嚴格要求它。服務(wù)器很好接收寫！

半同步復(fù)制

在 MySQL 的半同步復(fù)制中，主服務(wù)器不會確認事務(wù)提交，直到已知更改已發(fā)送到一個或多個副本。它提供了一種實現(xiàn)無損故障轉(zhuǎn)移的方法：應(yīng)用于主服務(wù)器的任何更改要么應(yīng)用于主服務(wù)器，要么等待應(yīng)用于其中一個副本。

一致性伴隨著成本：可用性的風險。如果沒有副本確認收到更改，主服務(wù)器將阻塞并停止寫操作。幸運的是，有一個超時配置，超時后主服務(wù)器可以恢復(fù)到異步復(fù)制模式，從而使寫操作再次可用。

我們已經(jīng)將超時設(shè)置為一個合理的低值: 500ms。將更改從主 DC 副本發(fā)送到本地 DC 副本，通常也發(fā)送到遠程 DC，這已經(jīng)足夠了。通過這個超時，我們可以觀察到完美的半同步行為 (沒有退回到異步復(fù)制)，并且在確認失敗的情況下可以很輕松地使用非常短的阻塞周期。

我們在本地 DC 副本上啟用半同步，在主服務(wù)器死亡的情況下，我們期望 (盡管不嚴格執(zhí)行) 無損故障轉(zhuǎn)移。完全直流故障的無損故障轉(zhuǎn)移是昂貴的，我們并不期望它。

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

注入心跳

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

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

orchestrator 所有權(quán)委托

我們進一步 orchestrator:

注入 Pseudo-GTID ,

將提升的 master 設(shè)置為可寫，清除其復(fù)制狀態(tài)，以及，

如果可能，將舊主服務(wù)器設(shè)置為 read_only。

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

orchestrator 所有權(quán)委托

我們進一步 orchestrator：

Pseudo-GTID 注入，

將提升的 master 設(shè)置為可寫，清除其復(fù)制狀態(tài)，以及，

如果可能，將舊的 master 設(shè)置為 read_only。

在所有的新 master 的基礎(chǔ)上，這減少了摩擦。一個剛剛被提升的 master 顯然應(yīng)該是有活力，并且可以被接受的，否則我們不會提升它。因此，讓 orchestrator 將更改直接應(yīng)用于提升的 msater 是有意義的。

限制和缺點

代理層使應(yīng)用程序不知道主服務(wù)器的身份，但它也掩蓋了應(yīng)用程序的主服務(wù)器的身份。所有主要看到的都是來自代理層的連接，我們會丟失關(guān)于連接的實際來源的信息。

隨著分布式系統(tǒng)的發(fā)展，我們?nèi)匀幻媾R著未處理的場景。

值得注意的是，在一個數(shù)據(jù)中心隔離場景中，假設(shè)主服務(wù)器位于隔離的 DC 中，該 DC 中的應(yīng)用程序仍然能夠?qū)懭胫鞣?wù)器。一旦網(wǎng)絡(luò)恢復(fù)，這可能導(dǎo)致狀態(tài)不一致。我們正在努力減輕這種分裂的大腦實施一個可靠的 STONITH 從內(nèi)部非常孤立的 DC。和以前一樣，在摧毀初選之前還需要一段時間，而且可能會有一段短時間的腦分裂。避免大腦分裂的操作成本非常高。

還存在更多的情況：在故障轉(zhuǎn)移時停止領(lǐng)事服務(wù)；部分直流隔離；其他情況。我們知道這種性質(zhì)的分布式系統(tǒng)不可能堵住所有的漏洞，所以我們把重點放在最重要的案例上。

結(jié)論

我們的協(xié)調(diào)器 / GLB/Consul 為我們提供了:

可靠的故障檢測，

與數(shù)據(jù)中心無關(guān)的故障轉(zhuǎn)移，

通常無損的故障轉(zhuǎn)移，

數(shù)據(jù)中心網(wǎng)絡(luò)隔離支持，

緩解裂腦 (更多工作成果),

不依賴合作，

在大多數(shù)情況下，總中斷時間在 10 and 13 seconds 之間。

在不常見的情況下，我們最多可以看到 20 seconds 的總停機時間，在極端情況下則可以看到最多 25 seconds 的停機時間。

關(guān)于“GitHub 是如何做好 MySQL 高可用性的”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對“GitHub 是如何做好 MySQL 高可用性的”知識都有一定的了解，大家如果還想學習更多知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。