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

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

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

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

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

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

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

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

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

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

• 最大允許的服務(wù)中斷的時(shí)間是多少？
• 服務(wù)中斷檢測(cè)的準(zhǔn)確性怎么樣？是否能夠允許服務(wù)中斷檢測(cè)誤報(bào)（會(huì)導(dǎo)致過(guò)早故障轉(zhuǎn)移）？
• 故障轉(zhuǎn)移的可靠性怎么樣？什么情況會(huì)導(dǎo)致故障轉(zhuǎn)移失敗？
• 這個(gè)方案能否在跨數(shù)據(jù)中心實(shí)現(xiàn)，以及如何實(shí)現(xiàn)的？ 在不同的網(wǎng)絡(luò)狀況下會(huì)怎么樣，延遲高，或延遲低的情況會(huì)怎么樣？
• 這個(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)爭(zhēng)搶共享資源寫(xiě)入數(shù)據(jù)的情況）？
• 能否容忍數(shù)據(jù)丟失？容忍丟失程度是多少？

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

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

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

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

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

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

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

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

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

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

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

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

• DNS 更改需要更長(zhǎng)的時(shí)間傳播?？蛻舳司彺?DNS 名稱會(huì)先配置時(shí)間。跨平臺(tái)故障轉(zhuǎn)移意味著需要