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

程序員必備接口測試調(diào)試工具：立即使用
Apipost = Postman + Swagger + Mock + Jmeter
Api設(shè)計(jì)、調(diào)試、文檔、自動化測試工具
后端、前端、測試，同時(shí)在線協(xié)作，內(nèi)容實(shí)時(shí)同步

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

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

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

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

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

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

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

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

• 最大允許的服務(wù)中斷的時(shí)間是多少？
• 服務(wù)中斷檢測的準(zhǔn)確性怎么樣？是否能夠允許服務(wù)中斷檢測誤報(bào)（會導(dǎo)致過早故障轉(zhuǎn)移）？
• 故障轉(zhuǎn)移的可靠性怎么樣？什么情況會導(dǎo)致故障轉(zhuǎn)移失??？
• 這個(gè)方案能否在跨數(shù)據(jù)中心實(shí)現(xiàn)，以及如何實(shí)現(xiàn)的？ 在不同的網(wǎng)絡(luò)狀況下會怎么樣，延遲高，或延遲低的情況會怎么樣？
• 這個(gè)解決方案能否承受整個(gè)數(shù)據(jù)中心（DC）的故障 或者網(wǎng)絡(luò)隔離的情況？
• 有什么機(jī)制防止 HA 集群腦裂情況（在一個(gè)整體的系統(tǒng)，聯(lián)系著的兩個(gè)節(jié)點(diǎn)分裂為兩個(gè)獨(dú)立節(jié)點(diǎn)，這兩個(gè)節(jié)點(diǎn)爭搶共享資源寫入數(shù)據(jù)的情況）？
• 能否容忍數(shù)據(jù)丟失？容忍丟失程度是多少？

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

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

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

• 使用 orchestrator 作為故障檢測遷移方案。
• 采用 VIP 和 DNS 方式作為主節(jié)點(diǎn)發(fā)現(xiàn)方案。

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

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

考慮夸三個(gè)數(shù)據(jù)中心的拓?fù)浣Y(jié)構(gòu)的情況：

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

orchestrator 會檢測異常，選出新的主庫，然后重新分配數(shù)據(jù)庫的名稱以及虛擬 IP (VIP)?？蛻舳吮旧聿恢乐鲙斓淖兏蛻舳擞械男畔⒅皇侵鲙斓?em>名稱，因此這個(gè)名稱必須能夠解析到新的主庫服務(wù)器?？紤]下面的問題：

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

• 故障轉(zhuǎn)移的順序，首先是請求故障機(jī)器釋放 VIP，然后聯(lián)系新的主庫機(jī)器分配 VIP。但是，如果故障機(jī)器本身不能訪問，或者說拒絕釋放 VIP 呢？ 考慮到機(jī)器故障的場景，故障機(jī)器不會立即響應(yīng)或根本就不會響應(yīng)釋放 VIP 的請求，整個(gè)過程有下面兩個(gè)問題：
  • 腦裂情況：如果有兩個(gè)主機(jī)持有相同的 VIP 的情況，不同的客戶端根據(jù)最短的網(wǎng)絡(luò)鏈路將會連接到不同的主機(jī)上。
  • 整個(gè) VIP 重新分配過程依賴兩個(gè)獨(dú)立服務(wù)器的相互協(xié)調(diào)，而且設(shè)置過程是不可靠的。
• 即使故障機(jī)器正常釋放 VIP，整個(gè)流程也是非常耗時(shí)的，因?yàn)榍袚Q過程還需要連接故障機(jī)器。
• 即使 VIP 重新分配，客戶端已有的連接不會自動斷開舊的故障機(jī)器，從而使得整個(gè)系統(tǒng)產(chǎn)生腦裂的情況。

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

• DNS 更改需要更長的時(shí)間傳播。客戶端緩存 DNS 名稱會先配置時(shí)間?？缙脚_故障轉(zhuǎn)移意味著需要