1.什麼是高可用性
高可用性不是絕對的，只有相對更高的可用性。可用性每提高一點，所花費的成本都會遠超之前。高可用性實際上是在宕機造成的損失和
降低宕機時間所花費的成本之間取得一個平衡。
有時候人們將可用性定義成服務器正在運行的時間段。我們認爲的可用性還應該包括應用是否能足夠好的處理請求。
2.導致宕機的原因
1.運行環境 (35%)
2.性能問題 (35%)
3.複製 (20%)
4.各種類似的數據丟失和損壞 (10%)
1.在運行環境中，最普通的問題是磁盤空間耗盡
2.在性能問題中，最普遍宕機的原因是運行很糟糕的 sql
3.糟糕的 schema 和索引設計是第二大影響性能的問題
4.複製問題通常是由於主備數據不一致導致的
5.數據丟失問題通常是由於 drop table的誤操作導致的
3.如何實現高可用性
可以通過同時進行以下2步來獲得高可用性。首先，可以嘗試避免導致宕機的原因來減少宕機時間。許多問題其實很容易避免，例如通過適當的配置，監控，以及規範或
安全保障措施來避免人爲錯誤。第二，儘量保證在發生宕機時能夠快速的恢復。最常見的策略是在系統中製造冗餘，並且具備故障轉移能力。這2個維度的高可用性可以通過
2個相關的度量來確定：平均失效時間(MTBF)和平均恢復時間(MTTR)。
1.提升平均失效時間(MTBF)
1.測試恢復工具和流程，包括從備份中恢復數據
2.遵守最小權限原則
3.保持系統乾淨，整潔
4.使用好的命名和組織來約定避免產生混亂
5.謹慎安排升級數據庫服務器
6.在升級前，使用諸如Percona Toolkit 中的 pt-upgrade 之類的工具仔細檢查系統
7.使用InnoDB並進行適當的配置，確保 InnoDB 是默認的存儲引擎。如果存儲引擎被禁用，服務器就無法啓動。
8.確認基本的服務器配置是正確的
9.通過 skip_name_resolve 禁止 DNS
10.除非能證明有效，否則禁用查詢緩存
11.避免使用複雜的特性，例如複製過濾和觸發器等
12.監控重要組件和功能，特別是像磁盤空間和 RAID 卷這樣的關鍵項目。
13.儘量記錄服務器的狀態和性能指標，如果可能就儘量永久保存
14.定期檢查複製完整性
15.將備庫設置爲只讀，不要讓複製自動啓動
16.定期進行查詢語句的檢查
17.歸檔並清理不需要的數據
18.爲文件系統保留一些空間
19.養成習慣，評估和管理系統的改變，狀態以及性能信息
2.降低平均恢復時間(MTTR)
通過在系統中建立冗餘來避免系統完全失效，並避免單點失效問題。一個能夠提供冗餘和故障轉移能力的系統架構，則是降低恢復時間的關鍵環節。
團隊成員是最重要的可用資產，所以爲恢復制定一個好的流程非常重要。擁有熟練技能，應變能力，訓練有素的僱員，以及處理緊急事件的詳細文檔和經過仔細測試的流程，
對從宕機中恢復有巨大的作用。
4.避免單點失效
找到並消除系統中可能失效的單點，並結合切換到備庫組件的機制，這是一種通過減少恢復時間(MTTR)來改善可用性的方法。思考並梳理整個應用，嘗試去定位任何可能
失效的單點。系統中任何不冗餘的部分都可能是一個失效的單點。
單點失效並不總是能夠消除。增加冗餘或許無法做到，因爲有些限制無法避開。嘗試去理解每一個影響可用性的部分，採取一種平衡的觀點來看待風險，並首先解決其中
影響最大的那一個。可以採用2種方法來爲系統增加冗餘：增加空餘容量和重複組件。一種提升可用性的方法是創建一個集羣或服務器池，並使用負載均衡解決方案。
1.共享存儲或磁盤複製
共享存儲能夠爲數據庫服務器和存儲解耦，通常使用的是 SAN。使用共享存儲時，服務器能夠正常掛在文件系統並進行操作。如果服務器掛了，備用服務器可以掛在相同
的文件系統，執行恢復需要的操作，並在失效服務器的數據上啓動MySQL。這個過程在邏輯上跟修復那臺故障的服務器沒什麼區別，不過更快速，因爲備用服務器已經啓動，
隨時可以運行。當開始故障轉移時，檢查文件系統，恢復InnoDB以及預熱是最有可能遇到延遲的地方，但檢查失效本身在許多設置中會花費很長時間。
共享存儲有2個優點：可以避免除存儲以外的任何其他組件失效所引起的數據丟失，併爲非存儲存儲建立冗餘提供可能。不過共享存儲本身仍然可能是單點。
共享存儲本身也有風險，如果mysql崩潰等故障導致數據文件損壞，可能會導致備用服務器無法恢復。我們強烈建議在使用共享存儲時選擇InnoDB存儲引擎或者其他穩定的
ACID存儲引擎。一次崩潰幾乎肯定會損壞MyISAM表，需要花費很長的時間來修復，並且肯定會丟失數據。我們也強烈建議使用日誌型文件系統。
磁盤複製技術是另外一個跟 SAN 類似效果的方法。mysql中最普遍使用的磁盤恢復技術是 DRBD，並結合 Linux-HA 項目中的工具使用。
DRBD是一個以 Linux 內核模塊方式實現的秒級別同步複製技術。它通過網卡將主服務器的每個塊複製到另外一個服務器的塊設備上(備用設備)，並在主設備提交塊之前
記錄下來。由於在備用DRBD設備上的寫入必須要在主設備上的寫入完成之前，因此備用設備的性能至少要和主設備一樣，否則就會限制主設備的寫入性能。同樣，如果正在
使用 DRBD 磁盤複製技術以保證在主設備失效時有一個隨時可以替換的備用設備，備用服務器的硬件應該跟主服務器的相匹配。帶電池寫緩存的 RAID 控制器對 DRBD 而言
幾乎是必須的，因爲在沒有這樣的控制器時性能會很差。
如果主服務器失效，可以把備用設備提升爲主設備。因爲 DRDB 是在磁盤塊層進行復制，而文件系統也可能不一致。這意味着最好是使用日誌型文件系統來做快速恢復。
一旦設備恢復完成，mysql 還需要運行自身的恢復。原故障服務器恢復後，會與新的主設備進行同步，並假定自身角色爲備用設備。
從如何實際的實現故障轉移的角度看，DRBD 和 SAN 很相似：有一個熱備機器，開始提供服務時會使用和故障機器相同的數據。最大的不同是，DRBD是複製存儲---不是
共享存儲---所以當使用 DRBD 時，獲得的是一份複製的數據，而 SAN 則是使用與故障機器同一物理設備上的相同數據副本。換句話說，磁盤複製技術的數據是冗餘的，
所以存儲和數據本身都不會存在單點失效問題。這2種情況下，當啓動備用機器時，mysql服務器的緩存都是空的。相比之下，備庫的緩存至少是部分預熱的。
DRDB 有一些很好的特性和功能，可以防止集羣軟件普遍會遇到的一些問題。一個典型的例子是 '腦裂綜合徵'，在2個節點上同時提升自己爲主服務器時會發生這種問題。
可以通過配置 DRDB 來防止這種事件發生。
缺點：
1.DRDB 的故障轉移無法做到秒級以內。它通常至少需要幾秒鐘的時間將備用設備提升爲主設備，還不包括任何必要的文件恢復和mysql恢復。
2.它很昂貴。
3.對於MyISAM表來說實際上用處不大，因爲MyISAM表崩潰後需要花費很長的時間來檢查和修復。
4.DRDB 無法替代備份。
5.對於寫操作增加了負擔。你需要理解的是寫入時，增加的延遲主要是由於網絡往返開銷和遠程服務器存儲導致的，特別對於小的寫入而言延遲會更大。儘管增加的延遲
可能就 0.3ms,這看起來比在本地磁盤上的IO 4~10ms的延遲小多了，但卻是正常的帶有寫緩存的RAID控制器的延遲的 3~4倍。使用DRDB導致服務器變慢最常見的原因
是mysql使用了InnoDB並採取了完全持久化模式，這會導致很多小的寫入和 fsync() 調用，通過 DRDB 同步時會很慢。
我們傾向於只使用 DRBD 複製存放二進制日誌的設備。如果主動節點失效，可以在被動節點上開啓一個日誌服務器，然後對失效主庫的所有備庫應用這些二進制日誌。接下來
可以選擇一個備庫提升爲主庫，以替代失效的系統。
說到底，共享存儲和磁盤複製的方式與其說是高可用性解決方案，不如說是一種保障數據安全的方法。只要有數據，就可以從故障中恢復，並且比無法恢復的情況的 MTTR更低。
2.MySQL同步複製
當使用同步複製的時候，主庫上的事務只有在至少一個備庫上提交後才能確認爲其執行完成。這實現了2個目標：當服務器崩潰時沒有提交的事務會丟失，並且至少有一個備庫
擁有實時的數據副本。大多數同步複製架構運行在主動-主動模式。這意味着每個服務器在任何時候都是故障轉移的候選者，這使得通過冗餘獲得高可用性更加容易。
1.MySQL Cluster
MySQL 中的同步複製首先出現在 MySQL Cluster 。它在所有的節點上進行同步的主---主複製，。這意味着在任何節點上寫入；這些節點擁有同等的讀寫能力。每一行
都是冗餘存儲的，這樣即使丟失了一個節點，也不會丟失數據，並且集羣仍然能提供服務。
2.Percona XtraDB Cluster
3.基於複製的冗餘
複製管理器是使用標準mysql複製來創建冗餘的工具。儘管可以通過複製來改善可用性，但也有一些'天花板'會阻止mysql當前版本的異步複製和半同步複製獲得和真正的同步
複製相同的結果。複製無法保證實時的故障轉移和數據零丟失，也無法將所有節點等同對待。
複製管理器通常監控和管理三件事：應用和mysql間的通信，mysql服務器的健康度，以及mysql服務器間的複製關係。它們既可以修改負載均衡的配置，也可以在必要的時候
轉移虛擬ip地址以使應用連接到合適的服務器上，還能夠在一個僞集羣中操縱複製以選擇一個服務器作爲寫入節點。大體上操作並不複雜：只需要確定寫入不會發送到一個還沒有
準備好提供些服務的服務器上，並保證黨需要提升一臺備庫爲主庫時記錄下正確的複製座標。
1.MMM
2.MHA
基於複製的冗餘最終來說是好壞參半。只有在可用性的重要性遠比一致性或者數據零丟失保證更重要時才推薦使用。
5.故障轉移和故障恢復
冗餘是很好的技術，但實際上只有在遇到故障需要恢復時纔會用到。冗餘一點兒也不會增加可用性或者減少宕機。在故障轉移的過程中，高可用性是建立在冗餘的基礎上的。
冗餘和故障轉移結合可以幫助更快的恢復，MTTR 的減少將降低宕機時間並改善可用性。
如果系統擁有故障恢復能力，故障轉移就是一個雙向過程：當服務器A失效，服務器B替代它，在修復服務器A後可以再替換回來。
故障轉移比僅僅從故障中恢復更好。
故障轉移的緣由各不相同，因爲負載均衡和故障轉移在很多方面很相似，它們之間的界限比較模糊。總的來說，我們認爲一個完全的故障轉移解決方案至少能夠監控並自動
替換組件。它對應用應該是透明的，負載均衡不需要提供這些功能。
Linux-HA 項目。
故障轉移最重要的部分就是故障恢復。如果服務器間不能自如切換，故障轉移就是一個死衚衕，只能延緩宕機時間而已。這也是我們傾向於對稱複製佈局，例如雙主配置，
而不會選擇使用三臺或者更多的聯合主庫來進行環形複製的原因。如果配置是對等的，故障轉移和故障恢復就是在相反的方向上的相同操作。
1.提升備庫或者切換角色
提升一臺備庫爲主庫，或者在一個主---主複製結構中調換主動和被動角色，這些都是許多MySQL故障轉移策略很重要的一部分。
2.虛擬IP地址或者IP接管
可以爲提供特定服務的MySQL實例指定一個邏輯IP。當mysql失效時，可以將ip地址轉移到另外一臺mysql服務器上。
這種方法的好處是對應用透明。它會中斷已有的連接，但不要求修改配置。
不足之處：
1.需要把所有的ip地址定義在同一個網段，或者使用網絡橋接
2.改變ip需要root權限
3.有時候還需要更新ARP緩存
4.需要確定網絡硬件支持快速ip接管。有些硬件需要克隆MAC地址後才能工作
5.有些服務器即使完全喪失功能也會保持有ip地址，所以可能需要從物理上關閉或者斷開網絡連接。
等待更新擴展：
經常有這種情況，在某一層定義了一個冗餘後，需要等待底層執行一些改變。
3.中間件解決方案
可以使用代理，端口轉發，網絡地址轉換(NAT)或者硬件負載均衡來實現故障轉移和故障恢復。它們是控制應用和服務器連接的中樞。但是，它們自身也引入了單點失效，
需要準備冗餘來避免這個問題。
使用這樣的解決方案，你可以將一個遠程數據中心設置爲看起來好像和應用在同一個網絡裏。這樣就可以使用諸如浮動ip這樣的技術讓應用和一個完全不同的數據中心開始
通信。你可以配置每個數據中心的每臺應用服務器，通過它自己的中間件連接，將流量路由到活躍數據中心的機器上。如果活躍數據中心的mysql徹底崩潰了，中間件可以路由
流量到另外一個數據中心的服務器池中，應用無需知道這個變化。
這種配置方法的主要缺點是在一個數據中心的apache服務器和另外一個數據中心的mysql服務器之間的延遲比較大。爲了緩和這個問題，可以把web服務器設置爲重定向模式。
這樣的通信都會被重定向到放置活躍mysql服務器的數據中心。還可以使用http代理來實現。
4.在應用中處理故障轉移
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
