MySQL MHA介紹

MHA簡介

MHA是一位日本MySQL大牛用Perl寫一套MySQL故障切換方案，來保證數據庫系統的高可用，在宕機的事件內（通常10-30秒），完成故障轉意，部署MHA，可避免主從一致性問題，節約購買新服務器的費用，不影響服務器性能，易安裝，不改變現有部署

MHA在生產環境的作用

一主多從的環境下，MySQL的主從復制是異步或是半同步。 Master發生故障的時候，有可能一部分（或者全部）的Slave未能獲取到最新的binlog，造成Slave之間的binlog轉發發生偏差。 如下圖所示，Master宕機之后，id=102的binlog未能被發送到任何一個Slave上，id=101的binlog只有save2上有，slave3上未能收到id=100和id-101的binlog 如果想要正確恢復：

• Master必須發出的ID=102的binlog
• 還要消除各個Slave之間的差異性

MHA可以全自動的處理以上這些

MHA架構

可實現master工作狀態的監控以及宕機時的故障轉移 要求：MySQL版本要在5.0以上

MHA原理

1、等待SQL線程執行完畢 2、解析最新的Slave上的中繼日志（relay log）的日志頭（log Header），為其他各個服務器確定出差異位置 3、將i1–>i2–>X 全部組成一個二進制日志

MHA的主要特性

• 從master的監控到故障轉移全部都能自動完成，故障轉移也可手動執行
• 可在秒級單位內實現故障轉移
• 可將任意Slave提升至master
• 具備在多個點上調用外部腳本（擴展）的技能，可以用在電源OFF或者IP地址的故障轉移上。
• 安裝和卸載不用停止當前的mysql進程
• MHA 自身不會增加服務器負擔，不會降低性能，不用追加服務器
• 不依賴Storage Engine
• 不依賴二進制文件的格式（不論是statement模式還是Row模式）

拓展性

• seconary_check_script

? 調用該腳本，從多個網絡路徑判斷MASTER是否宕機

? MASTER連接錯誤時會被調用

? MHA標配的腳本masterhaseconarycheck方便

• shutdown_script

? 電源強制OFF等

? 故障轉移前的瞬間被調用

? SSH可以鏈接到的情況下mysqld，mysqld_safe強制kill，ssh連不到的情況下關閉電源

• master_ip_failover_script

??MASTER的IP地址更新，新建和應用程序連接所需要的用戶

? 故障轉移前的瞬間和轉移到新MASTER(差異反映結束后)被調用

? 根據用途的不同來寫腳本可以實現不需要更改應用程序端就可以連接到新的MASTER

? MASTER IP使用虛擬IP的場合

? 將VIP讓給新的MASTER 5.???用catalog database等來管理MASTER的IP地址的場合?? ?? 更新該catalog database 中的信息

• ?report_script 發郵件通知故障轉移成功或失敗等的詳細情況

? 故障轉移結束后被調用

案例分析

• 在DeNA的服務中（主要是社交游戲），針對有超過150組（對）MASTER/SLAVE的服務器引入MHA
• MySQL一般不會出現服務宕機，通常是由OS和H/W故障引起
• 拓展

??? 檢測MASTER是否宕機

除了Manager會對MASTER進行監控外，另外還通過其他兩處的遠程數據中心來檢測是否可以連接到MASTER

??? 強制宕機MASTER

ssh可以連接到的情況下用kill -9 mysqld mysqld_safe，ssh連接不到的情況下ipmitool等工具強制關閉電源。 ?

• 針對OS掛掉的故障轉移，檢測系統是否掛掉需要10秒，故障轉移僅需4秒

MASTER的生死判定 3*4-3 （9秒-12秒）

? 判定是否可以進行故障轉移

默認情況，只有其他所有的SLAVE都存貨的情況下才進行故障轉移 檢測SLAVE，判斷其工作狀態（不到1秒）

? 故障轉移處理

強制將顯著的MASTER關機

SSH可以連接到的情況下，將有差異的二進制日志保存下來

確定新MASTER

將重新MASTER的IP地址有效化

重開其他的SLAVE從新的MASTER之間的主從復制

準備工作

一個可以寫的MASTER和多個SLAVE或只讀MASTER

當MASTER崩潰時，MHA會修復SLAVE之間的一致性問題。另外，MHA會嘗試從崩潰的MASTER保存未能發送的二進制日志并應用到所有Slave。如果僅有一臺SLAVE服務器，就不需要擔心SLAVE之間的一致性問題。但是即使只有一臺SLAVE服務器，在SSH可以連通的情況下，MHA在MASTER崩潰時搶救日志上也會非常有幫助，當然，通過半同步也可以解決這個問題。 從MHA Manager 0.52 開始支持多個MASTER(multi master)的復制。下面是MHA在多MASTER復制時注意的事項

• 只允許有一個MASTER（可寫）。在其他MASTER上必須設置MySQL全局變量”read-only=1″
• 缺省情況下，所有被管理的服務器（在配置文件中定義的服務器）應該是2層級聯復制。

在0.52版本以前，MHA僅在所有SLAVE都從同一個MASTER上進行復制才能進行檢測，監控和故障轉移操作。也就是說MHA不支持多主的配置形式。一般情況下，只要MHA可以管控自動故障轉移，使用多MASTER配置的意義會很有限，比如在線模式更改。如果只是嘗試使用多MASTER配置（比如僅僅為了在線模式更改）僅需在操作期間停止MHA并配置多主設置。當操作結束后，重新改為單主多從的配置，并重啟MHA。

管理3層或更多曾的及聯復制環境

MHA默認不支持三次或更多曾的級聯復制架構（比如Master->Master2->Slave3）。MHA僅在SLAVE直接從當前主要MASTER進行復制時，才會進行故障轉移和恢復操作。MHA可以管理MASTER1和MASTER2并且當MASTER1崩潰提升MASTER為主MASTER，但是MHA不能監控和恢復SLAVE3，因為SLAVE3從不同的MASTER(MASTER2)上進行主從復制。為了讓MHA在這種架構下能進行工作，需要以下設置：

• 在MHA的配置文件中設置MASTER和二層級聯中的主機（MASTER1和MASTER2）
• 使用multi_tier_slave=1 參數并在MHA配置文件中設置所有主機。

不管在那種情況中，MHA都只管理主MASTER和第二層的級聯SLAVE，即使MASTER崩潰，MASTER2會成為主要MASTER,從MASTER進行復制的SLAVE依然可以運行

MySQL5.0或更高的版本

MHA支持MySQL5.0或更高的版本。MHA不支持MySQL4.1，因為MySQL5.0開始，二進制日志的格式發生了改變（binlog v4） MHA分析二進制日志并確定位置點時止支持v4版本，所以MySQL4.1 在這里不能工作。MySQL5.0或更高版本中的mysqlbinlog同樣也需要v4版本的binlog格式。在早起的MySQL版本中主從復制處理存在一些非常嚴重的問題，所以高度推薦使用高版本的MySQL.特別是如果你還在使用MYSQL 5.06.0 以前的版本，請考慮升級

在候選MASTER 上必須開啟log-bin

如果當前SLAVE未設置log-bin，很明顯他們都不能成為MASTER，MHA Manager內部將會檢查log-bin的設置，不會將未開啟binlog的Slave提升為MASTER、如果當前的Slave都沒有設置log-bin，MHA將會不盡興故障轉移

在所有服務器上二進制日志和中繼日志過濾規則必須一致

所有服務器上的主從復制過濾規則（binlog-do-db，replicate-ignore-db等）MHA在啟動時檢查過濾規則，如果發現各服務器之間的配置不一致將不會進行監控或故障轉移

在被選MASTER上必須存在具有復制權限的用戶

當故障轉移完成后，所有Slave將執行CHANGE MASTER TO 語句。必須存在一個具有復制權限的用戶才能進行復制

總結

以上是生活随笔為你收集整理的高可用MySQL MHA介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。