GitHub如何做好MySQL高可用性

這篇文章主要介紹了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ù)庫保存。最終導致 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ù)中斷的總時間。

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

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

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

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

• 故障轉(zhuǎn)移的可靠性怎么樣？什么情況會導致故障轉(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(只讀)。

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

解決方案是有效的，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 指導是開源的.

• 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?，F(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ù)。它會導向?qū)嶋H的 cluster1 master 節(jié)點。

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

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è)置彼此獨立。 它們不會在彼此之間復制，也不會共享任何數(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é)點開始恢復，一個數(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?？蛻舳酥魂P(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ò)隔離可能會導致混亂：該 DC 內(nèi)的服務(wù)器可以相互通信。是它們與其他 DC 網(wǎng)絡(luò)隔離，還是其他 DC 被網(wǎng)絡(luò)隔離？

在 orchestrator/raft 設(shè)置中，raft 領(lǐng)導節(jié)點是運行故障轉(zhuǎn)移的節(jié)點。領(lǐng)導者是獲得組中大多數(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)導者。如果任何這樣的節(jié)點恰好是領(lǐng)導者，它就會下臺。將從任何其他 DC 中分配新的領(lǐng)導者。該領(lǐng)導者將得到所有其他能夠相互通信的 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ù)器隊列。理解復制規(guī)則并遵守提示和限制，它能夠?qū)ψ罴巡僮鬟^程做出有根據(jù)的決策。

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

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

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

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

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

半同步復制

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

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

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

我們在本地 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è)置為可寫，清除其復制狀態(tài)，以及，

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

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

orchestrator 所有權(quán)委托#

我們進一步 orchestrator：

• Pseudo-GTID 注入，

• 將提升的 master 設(shè)置為可寫，清除其復制狀態(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ò)恢復，這可能導致狀態(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)注億速云行業(yè)資訊頻道。