MySQL - 高可用性：少宕機即高可用？

咱們以前瞭解了複製、擴展性，接下來就讓咱們來了解可用性。歸根到底，高可用性就意味着 "更少的宕機時間"。

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

1 什麼是可用性

咱們常見的可用性一般以百分比表示，這自己就有其隱藏的意味：高可用性不是絕對的。換句話說，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 後，可能須要幾個小時才能預熱數據以保證請求的響應時間。這裏的幾個小時也應該包括在宕機時間內。

到此爲止，咱們應該有個大體的印象，可用性與應用宕機有關係。接下來，讓咱們再深刻一步，瞭解下應用宕機的緣由。

2 致使宕機的緣由

咱們最常聽到的數據庫宕機緣由多是** SQL 性能不好**。但實際上並不是如此，按表現方式致使宕機的緣由分爲如下幾類：

宕機事件表現形式	佔比	致使宕機的緣由
運行環境	35%	磁盤空間耗盡
性能問題	35%	1. 低性能 SQL；2. 服務器 BUG；3. 糟糕的表結構設計和索引設計
複製	20%	主備數據不一致
數據丟失或損壞	10%	誤操做刪除數據，缺乏備份

運行環境一般能夠看做是支持數據庫服務器運行的系統資源集合，包括操做系統、硬盤以及網絡等。

另外，咱們雖然常常用複製來提升可用時間，但它也是致使宕機的重要 「元兇」 之一。這也說明了一個廣泛的狀況：

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

瞭解了可用性的定義及其下降可用性的因素，咱們就要來考慮如何提升系統的可用性了。

3 如何實現高可用性

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

• 應用的平均失效時間
• 應用的平均恢復時間

所以，提升可用性也能夠從這兩個方面入手。首先，能夠儘可能避免應用宕機來減小宕機時間。實際上，經過適當的配置、監控，以及規範或安全保障措施，不少致使宕機的問題很容易能夠避免。

其次，儘可能保證在發生宕機時，可以快速恢復。最多見的策略是在系統中製造冗餘，而且保證系統的故障轉移能力。

接下來，讓咱們一塊兒來了解具體針對性措施。

3.1 下降平均失效時間

咱們對系統變動缺乏管理是全部致使宕機事件中最廣泛的緣由。典型的錯誤包括粗心的升級致使升級失敗並碰到一些 bug，或是還沒有測試就將數據表結構或查詢語句的更改直接在線上運行，或者是沒有爲一些失敗的狀況制定對應計劃，例如達到了磁盤容量限制等。

另一個致使宕機的主要緣由是缺乏嚴格的評估。例如由於疏忽沒有確認備份是不是可恢復的。

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

所以，只要咱們多作些針對性的工做，就能夠避免不少宕機時間。具體能夠從如下措施着手：

• 測試恢復工具和流程，包括從備份中恢復數據。
• 聽從最小權限原則。
• 保持系統乾淨、整潔。
• 使用好的命名和組織約定來避免產生混亂。例如服務器是用於開發仍是生產環境。
• 謹慎安排升級數據庫服務器。
• 在升級前，使用諸如 Percona Toolkit 中的 pt-upgrade 之類的工具仔細檢查系統。
• 使用 InnoDB 並進行適當的配置，確保 InnoDB 是默認存儲引擎。若是存儲引擎被禁止，服務器就沒法啓動。
• 確認基本的服務器配置是正確的。
• 經過 skip_name_resolve 禁止 DNS。
• 在未明確查詢緩存有用的狀況下，應該禁用查詢緩存。
• 儘可能避免使用複雜的特性，除非確實須要。例如複製過濾、觸發器等。
• 監控重要的組件和功能。特別是像磁盤空間和 RAID 卷狀態這樣的關鍵項目。
• 儘量久的記錄服務器的狀態和性能指標。
• 按期檢查複製完整性。
• 將被刻意設置爲只讀，不要讓複製自動啓動。
• 按期進行查詢語句審查。
• 歸檔並清理不須要的數據。
• 爲文件系統保留部分空閒空間；
• 養成評估和管理系統的改變、狀態和性能信息的習慣。

3.2 下降平均恢復時間

對於恢復時間，咱們能夠從三方面入手：

• 爲系統創建冗餘，保證系統的故障轉移能力，避免單點失效。
• 爲人員制定一個完善的恢復流程規範。
• 爲人員組織過後覆盤，避免將來發生類似的錯誤。

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

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) 團隊人員如何提升系統恢復時間？

因爲團隊內每一個人對於宕機恢復的熟練度和對應能力各有不一樣，所以咱們還須要一個對應人員的流程規範，來幫助你們都能在宕機時參與進來，下降系統的恢復時間。

系統恢復後，咱們就要組織你們對對宕機時間進行評估，這裏要注意的是，不要對此類的 「過後反思」 指望過高。致使宕機的緣由一般是多方面的的，咱們很難去回顧問題當時所處的情況，也很難找到真正的緣由。所以，咱們在過後反思獲得的結論應該有所保留。

4 總結

1. 可用性用宕機時間 n 個 9 來衡量。
2. 實現可用性從平均失效時間和平均恢復時間入手。