摘要：歸根到底，高可用性就意味著更少的宕機時間。首先，可以盡量避免應用宕機來減少宕機時間。降低平均失效時間我們對系統變更缺少管理是所有導致宕機事件中最普遍的原因。

我們之前了解了復制、擴展性，接下來就讓我們來了解可用性。歸根到底，高可用性就意味著 "更少的宕機時間"。

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

我們常見的可用性通常以百分比表示，這本身就有其隱藏的意味：高可用性不是絕對的。換句話說，100% 的可用性是不可能達到的。沒錯，這里可以這么肯定的說。

我們一般用 “9” 的個數來描述可用性。X個9表示在數據中心運行1年時間的使用過程中，各系統可以正常使用時間與總時間（1年）之比。例如：“5 個 9” 表示 99.999%，那么應用宕機時間 t：

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

因此，我們可以說，“5 個 9” 表示應用每年只允許 5.256 分鐘的宕機時間。同樣的計算，我們可以得出 3 個 9 每年宕機時間為 8.76 小時，4 個 9 的是 52.6 分鐘。

實際上，5 個 9 對于大多數應用來說已經是很難做到的，但是對于一些大型公司，肯定還會去嘗試獲得更多的 "9"，已盡量減少應用的宕機時間，降低宕機成本。

每個應用對可用性的需求各不相同。在設定一個目標值之前，一定要考慮清楚是不是確實需要達到這個目標。可用性的效果和開銷對應的比例并不是線性增長的，每提高一點可用性，所花費的成本都會遠超之前。

因此，對于可用性，我們可以遵循這樣一個原則：

能夠承擔多少宕機成本，就保證相應的可用時間。

說起來可能有點繞，簡單來說：對于有 10W 用戶的應用，
假設實現 5 個 9 需要 100W，每年應用即使宕機 9 小時，總損失也才 50W，你說這個應用有必要去實現 5 個 9 的可用性嗎？

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

到此為止，我們應該有個大致的印象，可用性與應用宕機有關系。接下來，讓我們再深入一步，了解下應用宕機的原因。

我們最常聽到的數據庫宕機原因可能是 SQL 性能很差。但實際上并非如此，按表現方式導致宕機的原因分為以下幾類：

運行環境通常可以看作是支持數據庫服務器運行的系統資源集合，包括操作系統、硬盤以及網絡等。

另外，我們雖然經常用復制來提高可用時間，但它也是導致宕機的重要 “元兇” 之一。這也說明了一個普遍的情況：

許多高可用策略可能會產生反作用

了解了可用性的定義及其降低可用性的因素，我們就要來考慮如何提高系統的可用性了。

通過上面的分析，也許你已經發現了，我們可用性取決于兩個時間：

應用的平均失效時間

應用的平均恢復時間

因此，提高可用性也可以從這兩個方面入手。首先，可以盡量避免應用宕機來減少宕機時間。實際上，通過適當的配置、監控，以及規范或安全保障措施，很多導致宕機的問題很容易可以避免。

其次，盡量保證在發生宕機時，能夠快速恢復。最常見的策略是在系統中制造冗余，并且保證系統的故障轉移能力。

接下來，讓我們一起來了解具體針對性措施。

我們對系統變更缺少管理是所有導致宕機事件中最普遍的原因。典型的錯誤包括粗心的升級導致升級失敗并碰到一些 bug，或是尚未測試就將數據表結構或查詢語句的更改直接在線上運行，或者是沒有為一些失敗的情況制定對應計劃，例如達到了磁盤容量限制等。

另外一個導致宕機的主要原因是缺少嚴格的評估。例如因為疏忽沒有確認備份是否是可恢復的。

還有就是可能沒有準確的監控 MySQL 的相關信息。例如緩存命中率報警可能只是誤報，并不能說明出現問題，致使我們認為監控系統沒有用，就忽略了真正出現問題的報警。導致 boss 問你，為什么磁盤滿了沒有收到報警信息時，你一臉無辜的看著他。

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

測試恢復工具和流程，包括從備份中恢復數據。

遵從最小權限原則。

保持系統干凈、整潔。

使用好的命名和組織約定來避免產生混亂。例如服務器是用于開發還是生產環境。

謹慎安排升級數據庫服務器。

在升級前，使用諸如 Percona Toolkit 中的 pt-upgrade 之類的工具仔細檢查系統。

使用 InnoDB 并進行適當的配置，確保 InnoDB 是默認存儲引擎。如果存儲引擎被禁止，服務器就無法啟動。

確認基本的服務器配置是正確的。

通過 skip_name_resolve 禁止 DNS。

在未明確查詢緩存有用的情況下，應該禁用查詢緩存。

盡量避免使用復雜的特性，除非確實需要。例如復制過濾、觸發器等。

監控重要的組件和功能。特別是像磁盤空間和 RAID 卷狀態這樣的關鍵項目。

盡可能久的記錄服務器的狀態和性能指標。

定期檢查復制完整性。

將被刻意設置為只讀，不要讓復制自動啟動。

定期進行查詢語句審查。

歸檔并清理不需要的數據。

為文件系統保留部分空閑空間；

養成評估和管理系統的改變、狀態和性能信息的習慣。

對于恢復時間，我們可以從三方面入手：

為系統建立冗余，保證系統的故障轉移能力，避免單點失效。

為人員制定一個完善的恢復流程規范。

為人員組織事后復盤，避免未來發生相似的錯誤。

接下來，我們來討論下具體措施。

1) 如何避免單點失效？

對于單點失效，我們首先要做的是找到它，然后針對性解決它。

一個系統中，每個單點都有可能失效。可能是一個硬盤驅動器、一臺服務器或者是一臺交換機、路由器，甚至某個機架的電源等等單點。

在進行相關措施前，我們要明白，單點失效并不能完全消除。我們可能引入新的的技術來解決單點失效問題，但引入的新技術可能導致更多的宕機時間。因此，我們應該按影響級別對失效單點進行排序，按照排序針對性解決單點失效問題。

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

增加空余容量比較簡單。可以創建一個集群或服務器池，使用負載均衡方案。這樣在一臺服務器失效時，其它服務器可以接管失效服務器的負載。

另外，處于很多方面的考慮可能會需要冗余組件，可以主要組件失效時，能有一個備件來隨時替換。可冗余的組件可以是空閑的網卡、路由器或者硬盤驅動器等。

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

共享存儲或磁盤復制

MySQL 同步復制

2) 如何保證系統的故障轉移和恢復能力？

在開始這個話題之前，我們先來認識下什么是 “故障轉移”。有些人用 “回退” 表示，也有人會使用 “切換”，以表明一次計劃中的切換而不是故障后的應對措施。

我們在這里使用 “故障恢復” 來表示故障轉移的反面。如果系統擁有故障恢復能力，那么，故障轉移就是一個雙向過程：

當服務器 A 失效，服務器 B 代替它，在修復 A 服務器后可以再替換回來。

故障轉移最重要的部分就是故障恢復。如果服務器間不能自由切換，故障轉移就是一個死胡同，只能延緩宕機時間而已。因此，使用復制時，可以使用對稱復制布局，如雙主結構。因為配置是對等的，故障轉移和故障恢復就是在相反方向上的相同操作。

接下來我們就認識一些比較普遍的故障轉移技術。

提升備庫或切換角色

提升一臺備庫為主庫，或者在一個 主-主復制結構中調換主動和被動角色，這些都是許多 MySQL 故障轉移策略中很重要的一部分。詳情參見MySQL 復制 - 性能與擴展性的基石 4：主備庫切換

虛擬 IP 地址或 IP 接管

可以為需要提供特點服務的 MySQL 實例指定一個邏輯 IP 地址。當 MySQL 實例失效時，將 IP 地址轉移到另一臺 MySQL 服務器上。這里的解決方案本質上負載均衡里的虛擬 IP 技術是一樣的，不同的是現在是用于故障轉移。

這種方法的好處是對應用透明。它會中斷已有的連接，但不用修改配置。

當然，它也有一些不足之處：

需要把所有的 IP 地址定義在同一網段，或者使用網絡橋接。

有時候還需要更新 ARP 緩存。部分網絡設備可能會把 ARP 信息保存太久，導致無法即時將一個 IP 地址切換到另一個 MAC 地址上。

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

3) 團隊人員如何提高系統恢復時間？

由于團隊內每個人對于宕機恢復的熟練度和對應能力各有不同，因此我們還需要一個對應人員的流程規范，來幫助大家都能在宕機時參與進來，降低系統的恢復時間。

系統恢復后，我們就要組織大家對對宕機時間進行評估，這里要注意的是，不要對此類的 “事后反思” 期望太高。導致宕機的原因通常是多方面的的，我們很難去回顧問題當時所處的狀況，也很難找到真正的原因。因此，我們在事后反思得到的結論應該有所保留。

可用性用宕機時間 n 個 9 來衡量。

實現可用性從平均失效時間和平均恢復時間入手。