MHA高可用切換工具

MHA高可用切換工具

MHA簡介
MHA是一位日本MySQL大牛用Perl寫的一套MySQL故障切換方案，來保證資料庫系統的高可用，在宕機時間內（通常10-30秒），完成故障切換，部署HA,可避免主從不一致問題節約購買伺服器的費用，易安裝，不改變現有部署。

MHA解決課題


MySQL主從複製架構中，當master發生故障時，有可能會發生一部分（或者全部）的slave未能擷取到最新binglog日誌，導致slave從庫和master資料不一致情況，甚至各salve之間資料也存在偏差
而master能夠消除各slave之間資料的差異，最大程度地保證資料一致性，實現真正意義上的高可用1）從宕機崩潰的master儲存二進位日誌事件（binlog events）;2）識別含有最新更新的slave；3）應用差異的中繼日誌（relay log）到其他的slave；4）提升一個slave為新的master；5）使其他的slave串連新的master進行複製

MHA架構

MHA Manager可以單獨部署在一台獨立的機器上管理多個master-slave叢集，也可以部署在一台slave節點上。MHA Node運行在每台MySQL伺服器上，MHA Manager會定時探測叢集中的master節點，當master出現故障時，它可以自動將最新資料的slave提升為新的master，然後將所有其他的slave重新指向新的master。整個容錯移轉過程對應用程式完全透明 在MHA自動故障切換過程中，MHA試圖從宕機的主伺服器上儲存二進位日誌，最大程度的保證資料的不丟失，但這並不總是可行的。例如，如果主伺服器硬體故障或無法通過ssh訪問，MHA沒法儲存二進位日誌，只進行容錯移轉而丟失了最新的資料。使用MySQL 5.5的半同步複製，可以大大降低資料丟失的風險。MHA可以與半同步複製結合起來。如果只有一個slave已經收到了最新的二進位日誌，MHA可以將最新的二進位日誌應用於其他所有的slave伺服器上，因此可以保證所有節點的資料一致性。

MHA特點從master的監控到容錯移轉全部自動完成，故障也可以選擇手動執行

可在秒級單位內實現容錯移轉

可將任意salve提升為master

安裝和卸載MHA不用停止當前正在啟動並執行mysql進程

MHA本身不會增加伺服器負擔，不會降低效能，不用另外追加伺服器

不依賴Storage Engine

不依賴binglog記錄檔格式（statement或者row）

具備在多個點上調用外部指令碼技能，可以在電源OFF或者IP地址的故障上轉移

MHA部署環境：CentOS 6.7_x64 MySQL5.5 多執行個體（已經實現主從複製）

主庫 /data/3306/ 172.16.2.10連接埠3306 #master    從庫 /data/3307/ 172.16.2.10連接埠3307 #candicate master 備選主庫從庫兼管理 /data/3308/ 172.16.2.10連接埠3308 #slave

1) 雖然我這裡採用的是本地多執行個體環境，但是還是要配置SSH遠程分發密鑰，以便MHA管理主機能不用輸入密碼和其他節點從庫通訊，如果是不同主機，記得每台都要分發公開金鑰，管理節點自己也要給自己發一次

[root@db02 ~]# ssh-keygen -t rsa[root@db02 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@172.16.2.10

2) 所有節點安裝mha的node包

[root@db02 ~]# yum install perl-DBD-MySQL -y #安裝依賴包[root@db02 ~]# rpm -ivh tools/mha4mysql-node-0.54-0.el6.noarch.rpm #mha的node節點包（：https://downloads.mariadb.com/files/MHA/mha4mysql-node-0.54-0.el6.noarch.rpm）

3) 管理節點安裝manager和相關依賴包

[root@db02 ~]# yum install perl-DBD-MySQL -y[root@db02 ~]# yum install perl-Config-Tiny -y[root@db02 ~]# yum install perl-Log-Dispatch -y[root@db02 ~]# yum install perl-Parallel-ForkManager -y[root@db02 ~]# yum localinstall tools/mha4mysql-manager-0.55-0.el6.noarch.rpm #localinstall解決循環相依性問題

4) 從程式庫伺服器配置 從程式庫伺服器設定檔裡my.cnf需要添加relay_log_purge=0參數
MySQL資料庫主從複製在預設情況下從庫的relay logs會在SQL線程執行完畢後被自動刪除，但是對於MHA情境下，對於某些滯後從庫的恢複依賴於其他的從庫relay log，因此需要禁止自動刪除功能：

mysql> set global relay_log_purge = 0;

編輯設定檔

my.cnf [mysqld] relay_log_purge = 0

5) 在所有節點伺服器上添加管理帳號

mysql> grant all privileges on *.* to mha@'172.16.2.%' identified by 'mha';Query OK, 0 rows affected (0.00 sec)mysql> flush privileges;Query OK, 0 rows affected (0.00 sec)

6) 在管理端配置/etc/mha/app1.cnf

[root@db02 ~]# mkdir /etc/mha #建立MHA設定檔夾[root@db02 ~]# mkdir -p /var/log/mha/app1 #MHA日誌管理檔案夾[root@db02 ~]# vim /etc/mha/app1.cnf #管理端設定檔[server default]manager_log=/var/log/mha/app1/manager.log #manager日誌manager_workdir=/var/log/mha/app1.log #manager的工作目錄master_binlog_dir=/data/3306/ #master 儲存binlog的位置，以便MHA可以找到master的日誌user=mha #設定監控使用者rootpassword=mha #設定監控使用者密碼ping_interval=2 #設定監控主庫，發送ping包的時間間隔，預設是3秒，嘗試三次沒有回應的時候自動進行railoverrepl_password=123456 #設定主從複製使用者的密碼repl_user=rep #設定主從複製使用者ssh_user=root #SSH遠端連線使用者名稱[server1]hostname=172.16.2.10port=3306[server2]candidate_master=1 #設定為候選master，如果設定該參數以後，發生主從切換以後將會將此從庫提升為主庫，即使這個主庫不是叢集中事件最新的slavecheck_repl_delay=0 #預設情況下如果一個slave落後master 100M的relay logs的話，MHA將不會選擇該slave作為一個新的master，因為對於這個slave的恢複需要花費很長時間，通過設定check_repl_delay=0,MHA觸發切換在選擇一個新的master的時候將會忽略複製延時，這個參數對於設定了candidate_master=1的主機非常有用，因為這個候選主在切換的過程中一定是新的masterhostname=172.16.2.10port=3307[server3]hostname=172.16.2.10port=3308

檢查mha manage是否配置成功
1）檢查SSH登陸

[root@db02 ~]# masterha_check_ssh --conf=/etc/mha/appl.cnf...Sun Jul 10 23:43:10 2016 - [info] All SSH connection tests passed successfully.

2） 檢查mysql replication主從複製是否成功

[root@db02 ~]# ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog #所有節點執行[root@db02 ~]# ln -s /application/mysql/bin/mysql /usr/bin/mysql #所有節點執行[root@db02 ~]# masterha_check_repl --conf=/etc/mha/appl.cnf...Mon Jul 11 00:11:14 2016 - [info] Checking replication health on 172.16.2.10..Mon Jul 11 00:11:14 2016 - [info]  ok.Mon Jul 11 00:11:14 2016 - [info] Checking replication health on 172.16.2.10..Mon Jul 11 00:11:14 2016 - [info]  ok.Mon Jul 11 00:06:56 2016 - [warning] shutdown_script is not defined.Mon Jul 11 00:06:56 2016 - [info] Got exit code 0 (Not master dead).MySQL Replication Health is OK.

3） 管理端啟動監控和測試啟動監控

[root@db02 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &[1] 100414#--remove_dead_master_conf    該參數代表當發生主從切換後，老的主庫的ip將會從設定檔中移除#--ignore_last_failover   在預設情況下，如果MHA檢測到連續發生宕機，且兩次宕機間隔不足8小時的話，則不會進行Failover，之所以這樣限制是為了避免ping-pong效應。該參數代表忽略上次MHA觸發切換產生的檔案，預設情況下，MHA發生切換後會在日誌目錄，也就是上面我設定的/data產生app1.failover.complete檔案，下次再次切換的時候如果發現該目錄下存在該檔案將不允許觸發切換，除非在第一次切換後收到刪除該檔案，為了方便，這裡設定為--ignore_last_failover[root@db02 ~]# masterha_check_status --conf=/etc/mha/app1.cnf #查看主庫及節點狀態app1 (pid:100414) is running(0:PING_OK), master:172.16.2.10

這裡MHA配置就算結束了，我們來試試停掉主庫master，類比故障
此時3308從庫兼管理機器上

mysql> show slave status\G;*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 172.16.2.10                   Master_User: rep                  Master_Port: 3306 #顯示master是3306                Connect_Retry: 60              Master_Log_File: mysql-bin.000023          Read_Master_Log_Pos: 3887               Relay_Log_File: relay-bin.000031                Relay_Log_Pos: 701        Relay_Master_Log_File: mysql-bin.000023             Slave_IO_Running: Yes

我們停掉3306

[root@db02 ~]# mysqladmin -uroot -pli123456 -S /data/3306/mysql.sock shutdown

再來看各同步資訊

mysql> show slave status\G;*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 172.16.2.10                  Master_User: rep                  Master_Port: 3307 #顯示主庫已經切換為3307了，而且速度非常快                Connect_Retry: 60              Master_Log_File: mysql-bin.000002          Read_Master_Log_Pos: 3529               Relay_Log_File: relay-bin.000002                Relay_Log_Pos: 253        Relay_Master_Log_File: mysql-bin.000002

而3307上面，此時已經看不到從庫資訊了，說明已經被MHA自動變為主庫了~

mysql> show slave status\G;Empty set (0.00 sec)

說明：實際工作中，當真的碰到主庫宕機，要秒級切換主庫時，這種MHA高可用方案涉及到要變更集群架構中DB的IP操作，會影響很多後端web應用，所有我們最好在串連解析資料庫時採用解析主機名稱的方式，一旦主庫宕機，MHA重新選出主庫以後，我們可以一鍵分發hosts解析到所有叢集節點，減少更改配置的的麻煩，效率還高！

本文永久更新連結地址：