摘要：歸根到底，高可用性就意味著更少的宕機(jī)時(shí)間。首先，可以盡量避免應(yīng)用宕機(jī)來(lái)減少宕機(jī)時(shí)間。降低平均失效時(shí)間我們對(duì)系統(tǒng)變更缺少管理是所有導(dǎo)致宕機(jī)事件中最普遍的原因。

我們之前了解了復(fù)制、擴(kuò)展性，接下來(lái)就讓我們來(lái)了解可用性。歸根到底，高可用性就意味著 "更少的宕機(jī)時(shí)間"。

老規(guī)矩，討論一個(gè)名詞，首先要給它下個(gè)定義，那么什么是可用性？

我們常見(jiàn)的可用性通常以百分比表示，這本身就有其隱藏的意味：高可用性不是絕對(duì)的。換句話說(shuō)，100% 的可用性是不可能達(dá)到的。沒(méi)錯(cuò)，這里可以這么肯定的說(shuō)。

我們一般用 “9” 的個(gè)數(shù)來(lái)描述可用性。X個(gè)9表示在數(shù)據(jù)中心運(yùn)行1年時(shí)間的使用過(guò)程中，各系統(tǒng)可以正常使用時(shí)間與總時(shí)間（1年）之比。例如：“5 個(gè) 9” 表示 99.999%，那么應(yīng)用宕機(jī)時(shí)間 t：

(1-99.999%)  3600  24 * 365 = 315.36s = 5.256m

因此，我們可以說(shuō)，“5 個(gè) 9” 表示應(yīng)用每年只允許 5.256 分鐘的宕機(jī)時(shí)間。同樣的計(jì)算，我們可以得出 3 個(gè) 9 每年宕機(jī)時(shí)間為 8.76 小時(shí)，4 個(gè) 9 的是 52.6 分鐘。

實(shí)際上，5 個(gè) 9 對(duì)于大多數(shù)應(yīng)用來(lái)說(shuō)已經(jīng)是很難做到的，但是對(duì)于一些大型公司，肯定還會(huì)去嘗試獲得更多的 "9"，已盡量減少應(yīng)用的宕機(jī)時(shí)間，降低宕機(jī)成本。

每個(gè)應(yīng)用對(duì)可用性的需求各不相同。在設(shè)定一個(gè)目標(biāo)值之前，一定要考慮清楚是不是確實(shí)需要達(dá)到這個(gè)目標(biāo)。可用性的效果和開(kāi)銷對(duì)應(yīng)的比例并不是線性增長(zhǎng)的，每提高一點(diǎn)可用性，所花費(fèi)的成本都會(huì)遠(yuǎn)超之前。

因此，對(duì)于可用性，我們可以遵循這樣一個(gè)原則：

能夠承擔(dān)多少宕機(jī)成本，就保證相應(yīng)的可用時(shí)間。

說(shuō)起來(lái)可能有點(diǎn)繞，簡(jiǎn)單來(lái)說(shuō)：對(duì)于有 10W 用戶的應(yīng)用，
假設(shè)實(shí)現(xiàn) 5 個(gè) 9 需要 100W，每年應(yīng)用即使宕機(jī) 9 小時(shí)，總損失也才 50W，你說(shuō)這個(gè)應(yīng)用有必要去實(shí)現(xiàn) 5 個(gè) 9 的可用性嗎？

另外，我們上面給可用性定義成了 “宕機(jī)時(shí)間”，但實(shí)際上可用性還應(yīng)該包括應(yīng)用是否能以足夠好的性能處理請(qǐng)求。對(duì)于一個(gè)大型服務(wù)器而言，重啟 MySQL 后，可能需要幾個(gè)小時(shí)才能預(yù)熱數(shù)據(jù)以保證請(qǐng)求的響應(yīng)時(shí)間。這里的幾個(gè)小時(shí)也應(yīng)該包括在宕機(jī)時(shí)間內(nèi)。

到此為止，我們應(yīng)該有個(gè)大致的印象，可用性與應(yīng)用宕機(jī)有關(guān)系。接下來(lái)，讓我們?cè)偕钊胍徊剑私庀聭?yīng)用宕機(jī)的原因。

我們最常聽(tīng)到的數(shù)據(jù)庫(kù)宕機(jī)原因可能是 SQL 性能很差。但實(shí)際上并非如此，按表現(xiàn)方式導(dǎo)致宕機(jī)的原因分為以下幾類：

運(yùn)行環(huán)境通常可以看作是支持?jǐn)?shù)據(jù)庫(kù)服務(wù)器運(yùn)行的系統(tǒng)資源集合，包括操作系統(tǒng)、硬盤以及網(wǎng)絡(luò)等。

另外，我們雖然經(jīng)常用復(fù)制來(lái)提高可用時(shí)間，但它也是導(dǎo)致宕機(jī)的重要 “元兇” 之一。這也說(shuō)明了一個(gè)普遍的情況：

許多高可用策略可能會(huì)產(chǎn)生反作用

了解了可用性的定義及其降低可用性的因素，我們就要來(lái)考慮如何提高系統(tǒng)的可用性了。

通過(guò)上面的分析，也許你已經(jīng)發(fā)現(xiàn)了，我們可用性取決于兩個(gè)時(shí)間：

應(yīng)用的平均失效時(shí)間

應(yīng)用的平均恢復(fù)時(shí)間

因此，提高可用性也可以從這兩個(gè)方面入手。首先，可以盡量避免應(yīng)用宕機(jī)來(lái)減少宕機(jī)時(shí)間。實(shí)際上，通過(guò)適當(dāng)?shù)呐渲谩⒈O(jiān)控，以及規(guī)范或安全保障措施，很多導(dǎo)致宕機(jī)的問(wèn)題很容易可以避免。

其次，盡量保證在發(fā)生宕機(jī)時(shí)，能夠快速恢復(fù)。最常見(jiàn)的策略是在系統(tǒng)中制造冗余，并且保證系統(tǒng)的故障轉(zhuǎn)移能力。

接下來(lái)，讓我們一起來(lái)了解具體針對(duì)性措施。

我們對(duì)系統(tǒng)變更缺少管理是所有導(dǎo)致宕機(jī)事件中最普遍的原因。典型的錯(cuò)誤包括粗心的升級(jí)導(dǎo)致升級(jí)失敗并碰到一些 bug，或是尚未測(cè)試就將數(shù)據(jù)表結(jié)構(gòu)或查詢語(yǔ)句的更改直接在線上運(yùn)行，或者是沒(méi)有為一些失敗的情況制定對(duì)應(yīng)計(jì)劃，例如達(dá)到了磁盤容量限制等。

另外一個(gè)導(dǎo)致宕機(jī)的主要原因是缺少嚴(yán)格的評(píng)估。例如因?yàn)槭韬鰶](méi)有確認(rèn)備份是否是可恢復(fù)的。

還有就是可能沒(méi)有準(zhǔn)確的監(jiān)控 MySQL 的相關(guān)信息。例如緩存命中率報(bào)警可能只是誤報(bào)，并不能說(shuō)明出現(xiàn)問(wèn)題，致使我們認(rèn)為監(jiān)控系統(tǒng)沒(méi)有用，就忽略了真正出現(xiàn)問(wèn)題的報(bào)警。導(dǎo)致 boss 問(wèn)你，為什么磁盤滿了沒(méi)有收到報(bào)警信息時(shí)，你一臉無(wú)辜的看著他。

因此，只要我們多做些針對(duì)性的工作，就可以避免很多宕機(jī)時(shí)間。具體可以從以下措施著手：

測(cè)試恢復(fù)工具和流程，包括從備份中恢復(fù)數(shù)據(jù)。

遵從最小權(quán)限原則。

保持系統(tǒng)干凈、整潔。

使用好的命名和組織約定來(lái)避免產(chǎn)生混亂。例如服務(wù)器是用于開(kāi)發(fā)還是生產(chǎn)環(huán)境。

謹(jǐn)慎安排升級(jí)數(shù)據(jù)庫(kù)服務(wù)器。

在升級(jí)前，使用諸如 Percona Toolkit 中的 pt-upgrade 之類的工具仔細(xì)檢查系統(tǒng)。

使用 InnoDB 并進(jìn)行適當(dāng)?shù)呐渲茫_保 InnoDB 是默認(rèn)存儲(chǔ)引擎。如果存儲(chǔ)引擎被禁止，服務(wù)器就無(wú)法啟動(dòng)。

確認(rèn)基本的服務(wù)器配置是正確的。

通過(guò) skip_name_resolve 禁止 DNS。

在未明確查詢緩存有用的情況下，應(yīng)該禁用查詢緩存。

盡量避免使用復(fù)雜的特性，除非確實(shí)需要。例如復(fù)制過(guò)濾、觸發(fā)器等。

監(jiān)控重要的組件和功能。特別是像磁盤空間和 RAID 卷狀態(tài)這樣的關(guān)鍵項(xiàng)目。

盡可能久的記錄服務(wù)器的狀態(tài)和性能指標(biāo)。

定期檢查復(fù)制完整性。

將被刻意設(shè)置為只讀，不要讓復(fù)制自動(dòng)啟動(dòng)。

定期進(jìn)行查詢語(yǔ)句審查。

歸檔并清理不需要的數(shù)據(jù)。

為文件系統(tǒng)保留部分空閑空間；

養(yǎng)成評(píng)估和管理系統(tǒng)的改變、狀態(tài)和性能信息的習(xí)慣。

對(duì)于恢復(fù)時(shí)間，我們可以從三方面入手：

為系統(tǒng)建立冗余，保證系統(tǒng)的故障轉(zhuǎn)移能力，避免單點(diǎn)失效。

為人員制定一個(gè)完善的恢復(fù)流程規(guī)范。

為人員組織事后復(fù)盤，避免未來(lái)發(fā)生相似的錯(cuò)誤。

接下來(lái)，我們來(lái)討論下具體措施。

1) 如何避免單點(diǎn)失效？

對(duì)于單點(diǎn)失效，我們首先要做的是找到它，然后針對(duì)性解決它。

一個(gè)系統(tǒng)中，每個(gè)單點(diǎn)都有可能失效。可能是一個(gè)硬盤驅(qū)動(dòng)器、一臺(tái)服務(wù)器或者是一臺(tái)交換機(jī)、路由器，甚至某個(gè)機(jī)架的電源等等單點(diǎn)。

在進(jìn)行相關(guān)措施前，我們要明白，單點(diǎn)失效并不能完全消除。我們可能引入新的的技術(shù)來(lái)解決單點(diǎn)失效問(wèn)題，但引入的新技術(shù)可能導(dǎo)致更多的宕機(jī)時(shí)間。因此，我們應(yīng)該按影響級(jí)別對(duì)失效單點(diǎn)進(jìn)行排序，按照排序針對(duì)性解決單點(diǎn)失效問(wèn)題。

具體到增加冗余的相關(guān)措施，有兩種方案：增加空余容量和重復(fù)組件。

增加空余容量比較簡(jiǎn)單。可以創(chuàng)建一個(gè)集群或服務(wù)器池，使用負(fù)載均衡方案。這樣在一臺(tái)服務(wù)器失效時(shí)，其它服務(wù)器可以接管失效服務(wù)器的負(fù)載。

另外，處于很多方面的考慮可能會(huì)需要冗余組件，可以主要組件失效時(shí)，能有一個(gè)備件來(lái)隨時(shí)替換。可冗余的組件可以是空閑的網(wǎng)卡、路由器或者硬盤驅(qū)動(dòng)器等。

此外，最重要的是，要完全冗余 MySQL 服務(wù)器。這意味著我們必須確保備用服務(wù)器能夠獲得主服務(wù)器上的數(shù)據(jù)。可以從以下措施著手：

共享存儲(chǔ)或磁盤復(fù)制

MySQL 同步復(fù)制

2) 如何保證系統(tǒng)的故障轉(zhuǎn)移和恢復(fù)能力？

在開(kāi)始這個(gè)話題之前，我們先來(lái)認(rèn)識(shí)下什么是 “故障轉(zhuǎn)移”。有些人用 “回退” 表示，也有人會(huì)使用 “切換”，以表明一次計(jì)劃中的切換而不是故障后的應(yīng)對(duì)措施。

我們?cè)谶@里使用 “故障恢復(fù)” 來(lái)表示故障轉(zhuǎn)移的反面。如果系統(tǒng)擁有故障恢復(fù)能力，那么，故障轉(zhuǎn)移就是一個(gè)雙向過(guò)程：

當(dāng)服務(wù)器 A 失效，服務(wù)器 B 代替它，在修復(fù) A 服務(wù)器后可以再替換回來(lái)。

故障轉(zhuǎn)移最重要的部分就是故障恢復(fù)。如果服務(wù)器間不能自由切換，故障轉(zhuǎn)移就是一個(gè)死胡同，只能延緩宕機(jī)時(shí)間而已。因此，使用復(fù)制時(shí)，可以使用對(duì)稱復(fù)制布局，如雙主結(jié)構(gòu)。因?yàn)榕渲檬菍?duì)等的，故障轉(zhuǎn)移和故障恢復(fù)就是在相反方向上的相同操作。

接下來(lái)我們就認(rèn)識(shí)一些比較普遍的故障轉(zhuǎn)移技術(shù)。

提升備庫(kù)或切換角色

提升一臺(tái)備庫(kù)為主庫(kù)，或者在一個(gè) 主-主復(fù)制結(jié)構(gòu)中調(diào)換主動(dòng)和被動(dòng)角色，這些都是許多 MySQL 故障轉(zhuǎn)移策略中很重要的一部分。詳情參見(jiàn)MySQL 復(fù)制 - 性能與擴(kuò)展性的基石 4：主備庫(kù)切換

虛擬 IP 地址或 IP 接管

可以為需要提供特點(diǎn)服務(wù)的 MySQL 實(shí)例指定一個(gè)邏輯 IP 地址。當(dāng) MySQL 實(shí)例失效時(shí)，將 IP 地址轉(zhuǎn)移到另一臺(tái) MySQL 服務(wù)器上。這里的解決方案本質(zhì)上負(fù)載均衡里的虛擬 IP 技術(shù)是一樣的，不同的是現(xiàn)在是用于故障轉(zhuǎn)移。

這種方法的好處是對(duì)應(yīng)用透明。它會(huì)中斷已有的連接，但不用修改配置。

當(dāng)然，它也有一些不足之處：

需要把所有的 IP 地址定義在同一網(wǎng)段，或者使用網(wǎng)絡(luò)橋接。

有時(shí)候還需要更新 ARP 緩存。部分網(wǎng)絡(luò)設(shè)備可能會(huì)把 ARP 信息保存太久，導(dǎo)致無(wú)法即時(shí)將一個(gè) IP 地址切換到另一個(gè) MAC 地址上。

需要確定網(wǎng)絡(luò)硬件是否支持快速 IP 接管。有些硬件需要克隆 MAC 地址后才能工作。

3) 團(tuán)隊(duì)人員如何提高系統(tǒng)恢復(fù)時(shí)間？

由于團(tuán)隊(duì)內(nèi)每個(gè)人對(duì)于宕機(jī)恢復(fù)的熟練度和對(duì)應(yīng)能力各有不同，因此我們還需要一個(gè)對(duì)應(yīng)人員的流程規(guī)范，來(lái)幫助大家都能在宕機(jī)時(shí)參與進(jìn)來(lái)，降低系統(tǒng)的恢復(fù)時(shí)間。

系統(tǒng)恢復(fù)后，我們就要組織大家對(duì)對(duì)宕機(jī)時(shí)間進(jìn)行評(píng)估，這里要注意的是，不要對(duì)此類的 “事后反思” 期望太高。導(dǎo)致宕機(jī)的原因通常是多方面的的，我們很難去回顧問(wèn)題當(dāng)時(shí)所處的狀況，也很難找到真正的原因。因此，我們?cè)谑潞蠓此嫉玫降慕Y(jié)論應(yīng)該有所保留。

可用性用宕機(jī)時(shí)間 n 個(gè) 9 來(lái)衡量。

實(shí)現(xiàn)可用性從平均失效時(shí)間和平均恢復(fù)時(shí)間入手。