mysql 高可用性 高效能mysql筆記
什麼是高可用性
- 高可用性是相對的沒有100%的高可用只有儘可能接近100%。
- 可用性每提高一點，所花費的成本都會遠超之前，可用性的效果和開銷的比例並不是線性的。
宕(dang)機的原因
-
執行環境問題，最普遍的是磁碟空間耗盡。
-
效能問題，最普遍的是執行糟糕的SQL，或伺服器BUG或錯誤的行為。
-
表和索引設計有問題。
-
複製問題通常由於主備資料不一致導致。
-
資料丟失通常由於DROP TABLE的誤操作導致，並總是伴隨著缺少可用備份的問題。
如何實現高可用性
-
避免導致宕機的原因來減少宕機時間
-
儘量保證在發生宕機時能夠快速恢復
1.提升平均失效時間（MTBF）
- 測試恢復工具和流程包括從備份中恢復資料。
- 遵從最小許可權原則。
- 保持系統乾淨、整潔。
- 用好的命名和組織約定來避免產生混亂,例如伺服器是用於開發還是用於生產環境。
- 安排升級資料庫伺服器。在升級前,使用諸如PerconaToolkit中的pt-upgrade之類的工具仔細檢查。
- 系統使用INNODB並進行適當的配置,確保INNODB是預設儲存引擎。如果儲存引擎被禁止,伺服器就無法啟動。
- 確認基本的伺服器配置是正確的。
- 通過skip_name_resolve禁止DNS。
- 除非能證明有效,否則禁用查詢快取。
- 避免使用複雜的特性,例如複製過濾和觸發器,除非確實需要。
- 監控重要的元件和功能,特別是像磁碟空間和RAID卷狀態這樣的關鍵專案,但也要避免誤報,只有當確實發生問題時才傳送告警。
- 儘量記錄伺服器的狀態和效能指數,如果可能就儘量久地儲存。
- 定期檢查複製完整性。
- 將備庫設定為只讀,不要讓複製自動啟動。
- 定期進行查詢語句審查。歸檔並清理不需要的資料。
- 為檔案系統保留一些空間。在GNU/Linx中,可以使用-m選項來為檔案系統本身保留空間。還可以在LVM卷組中留下一些空閒空間。或者,更簡單的方法,僅僅建立一個巨大的空檔案,在檔案系統快滿時,直接將其刪除。
- 養成習慣,評估和管理系統的改變、狀態以及效能資訊。
2.降低平均恢復時間（MTTR）
- 所有的宕機事件都是由多方面的失效聯合在一起導致的，可以通過利用合適的方法比如主備結構確保單點的安全。
避免單點失效
找到並消除系統中可能失效的單點，並結合切換到備用元件的機制，這是一種通過減少恢復時間來改善可用性的方法。
- 共享儲存或磁碟複製
共享儲存能夠為資料庫伺服器和儲存解耦合，通常使用的是SAN。使用共享儲存時，伺服器能夠正常掛載檔案系統並進行操作。如果伺服器掛了，備用伺服器可以掛載相同的檔案系統，執行需要的恢復操作，並在失效伺服器的資料上啟動MySQL。這個過程在邏輯上跟修復那臺故障的伺服器沒什麼兩樣，不過更快速，因為備用伺服器已經啟動，隨時可以執行。當開始故障轉移時，檢查檔案系統、恢復InnoDB以及預熱是最有可能遇到延遲的地方，但檢測失效本身在許多設定中也會花費很長時間。
磁碟複製技術是另外一個獲得跟SAN型別效果的方法。MySQL中最普遍使用的磁碟複製技術是DRBD，並結合Linux-HA專案中的工具使用。
- 同步複製
當使用同步複製時，主庫上的事務只有在至少一個備庫上提交後才能認為其執行完成。這實現了兩個目標：當伺服器崩潰時沒有提交的事務會丟失，並且至少有一個備庫擁有實時的資料副本。大多數同步複製架構執行在主動-主動模式。這意味著每個伺服器在任何時候都是故障轉移的候選者，這使得通過冗餘獲得高可用性更加容易。
- 基於複製的冗餘
複製管理器是使用標準MySQL複製來建立冗餘的工具。儘管可以通過複製來改善可用性，但也有一些“玻璃天花板”當前版本的非同步複製和半同步複製獲得和真正的同步複製相同的結果。複製無法保證實時的故障轉移和資料零丟失，也無法將所有節點等同對待。
故障轉移和故障恢復
在故障轉移的過程中，高可用性是建立在冗餘的基礎上。當有一個元件失效，但存在冗餘時，可以停止使用發生故障的元件，而使用冗餘元件。冗餘和故障轉移結合可以幫助更快的恢復。
- 提升備庫或切換角色
提升一臺備庫作為主庫，或者在一個主-主結構中調換主動或被動角色。 - 虛擬IP地址或IP接管
可以為需要提供特定服務的MySQL例項指定一個邏輯IP地址。當MySQL例項失效時，可以將IP地址轉移到另一臺MySQL伺服器上。這和負載均衡類似。 - 中介軟體解決方案
可以使用代理、埠轉發、網路地址轉換或者硬體負載均衡來實現故障轉移和故障恢復。這些都是很好的解決方案，不像其他方法可能會引入一些不確定性，它們是控制應用和伺服器間連線的中樞。但是，它們自身也引入了單點失效，需要準備冗餘來避免這個問題。 - 在應用中處理
當應用判斷mysql失效自動轉到另一臺。