mysql mha 主從自動切換 高可用

mha（Master High Availability）目前在MySQL多服務器（超過二臺），高可用方面是一個相對成熟的解決方案。

 

一，什麼是mha，有什麼特性

1. 主服務器的自動監控和故障轉移

MHA監控複製架構的主服務器，一旦檢測到主服務器故障，就會自動進行故障轉移。即便有些從服務器沒有收到最新的relay log，MHA自動從最新的從服務器上識別差別的relay log並把這些日誌應用到其餘從服務器上，所以全部的從服務器保持一致性了。MHA一般在幾秒內完成故障轉移，9-12秒能夠檢測出主服務器故障，7-10秒內關閉故障的主服務器以免腦裂，幾秒中內應用差別的relay log到新的主服務器上，整個過程能夠在10-30s內完成。還能夠設置優先級指定其中的一臺slave做爲master的候選人。因爲MHA在slaves之間修復一致性，所以能夠將任何slave變成新的master，而不會發生一致性的問題，從而致使複製失敗。

2. 交互式主服務器故障轉移

能夠只使用MHA的故障轉移，而不用於監控主服務器，當主服務器故障時，人工調用MHA來進行故障故障。

3. 非交互式的主故障轉移

不監控主服務器，但自動實現故障轉移。這種特徵適用於已經使用其餘軟件來監控主服務器狀態，好比heartbeat來檢測主服務器故障和虛擬IP地址接管，可使用MHA來實現故障轉移和slave服務器晉級爲master服務器。

4. 在線切換主從服務器

在許多狀況下，須要將現有的主服務器遷移到另一臺服務器上。好比主服務器硬件故障，RAID控制卡須要重建，將主服務器移到性能更好的服務器上等等。維護主服務器引發性能降低，致使停機時間至少沒法寫入數據。另外，阻塞或殺掉當前運行的會話會致使主主之間數據不一致的問題發生。MHA提供快速切換和優雅的阻塞寫入，這個切換過程只須要0.5-2s的時間，這段時間內數據是沒法寫入的。在不少狀況下，0.5-2s的阻塞寫入是能夠接受的。所以切換主服務器不須要計劃分配維護時間窗口(呵呵，不須要你在夜黑風高時通宵達旦完成切換主服務器的任務)。

5.MHA由兩部分組成：MHA Manager（管理節點）和MHA Node（數據節點）

要搭建MHA,要求一個複製集羣中必須最少有三臺數據庫服務器，一主二從，即一臺充當master，一臺充當備用master，另一臺充當從庫，管理節點能夠和master在一臺機器上。因此若是你只有二臺機器的話，heartbeat,keepalive等都是不錯的選擇了。

6.MHA比較靈活，能夠寫腳本，來進行故障轉移，或者主從切換等。

7.mha出現故障後，配置文件會被修改掉，這一點，讓我以爲很搞笑，若是故障轉移須要從新修改配置文件，從新啓動masterha_manager服務.

二，服務器說明

192.168.10.103 masters   //主
192.168.10.209 slave1    //從
192.168.10.219 slave2    //從（主備）
192.168.10.220 manage    //管理節點

一主二從，一個管理節點，將上面的內容寫入到每臺/etc/hosts當中

三，服務器間，無密碼ssh登陸

# ssh-keygen -t rsa
# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.10.103
# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.10.209
# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.10.219
# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.10.220

上面有5個命令，若是在103機器上，103自己不須要執行ssh-copy-id。copy完了之後，ssh測試一下，機器間切換是否是須要密碼了。

四，安裝mha

1,下載mha

https://code.google.com/p/mysql-master-ha/downloads/list

2,全部節點都要安裝

# yum install -y perl-DBD-MySQL
# rpm -ivh mha4mysql-node-0.54-0.el6.noarch.rpm

3,管理節點

# yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager
# rpm -ivh mha4mysql-manager-0.55-0.el6.noarch.rpm

注意：manager和node節點的版本能夠不同

五，配置mysql replication

請參考：mysql replication 主從(master-slave)同步

要符合mha的配置，根這篇文章有點不一樣。

1，主從的配置都要有

binlog-do-db=test
replicate-do-db=test

通常狀況下，主服務器須要包含binlog-do-db=test，從服務器須要包含replicate-do-db=test，這樣主從就能夠同步了。可是隻是這樣配置的話，會報如下錯誤

All log-bin enabled servers must have same binlog filtering rules (same binlog-do-db and binlog-ignore-db). Check SHOW MASTER STATUS output and set my.cnf correctly.

在摸索這一塊配置的時候，浪費不少時間，我一直覺得，上面英文的意思是說，主從同步的數據庫要同樣，其實不是，而是配置文件中，配置數據庫這一塊要同樣。

2，從服務器，要加上relay_log_purge=0，不加的話，會報出warning,relay_log_purge=0 is not set on slave

六，corosync pacemaker mysql replication配置

請參考：corosync pacemaker mysql replication 實現高可用

配置corosync pacemaker的目的，其實就是爲獲得一個虛擬IP，連主和主備中的一個，我能夠經過虛擬IP鏈接，這樣作的好處就是，若是主down機了，我經過虛擬IP能夠鏈接主備，若是主修改好了，那麼虛擬IP能夠鏈接到主，而不須要去修改代碼。

七，配置mha manage

1，添加管理帳號，每臺機器都執行如下操做

grant all privileges on *.* TO mha@'192.168.%' IDENTIFIED BY 'test';
flush privileges;

2，配置/etc/mha/app1.cnf，只在管理端作，manage這臺機器

# mkdir /etc/mha
# mkdir -p /var/log/mha/app1

[root@manage mysql]# cat /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager.log
manager_workdir=/var/log/mha/app1.log
master_binlog_dir=/var/lib/mysql
user=mha
password=test
ping_interval=2
repl_password=test
repl_user=test
ssh_user=root

[server1]
hostname=192.168.10.103
port=3306

[server2]
candidate_master=1
check_repl_delay=0
hostname=192.168.10.219
port=3306

[server3]
hostname=192.168.10.209
port=3306

在server default中的配置，是三臺機器共同的配置，也能夠放到具體的server中進行定製

八，檢查mha manage是否是配置成功

1,檢查ssh登陸

# masterha_check_ssh --conf=/etc/mha/app1.cnf

若是看到，All SSH connection tests passed successfully，就說明ssh配置成功了

2,檢查mysql replication是否配置成功

# masterha_check_repl --conf=/etc/mha/app1.cnf

若是，出現如下內容，說明配置成功了。

mha 檢驗 mysql replication

3,管理端經常使用命令

masterha_check_ssh       檢查MHA的SSH配置情況
masterha_check_repl      檢查MySQL複製情況
masterha_manger          啓動MHA
masterha_check_status    檢測當前MHA運行狀態
masterha_master_monitor  檢測master是否宕機
masterha_master_switch   控制故障轉移（自動或者手動）
masterha_conf_host       添加或刪除配置的server信息

九，在管理端，啓動監控

[root@manage mha]#  nohup masterha_manager --conf=/etc/mha/app1.cnf > /tmp/mha_manager.log  2>&1 &    //開啓MHA
[root@manage mha]# masterha_check_status --conf=/etc/mha/app1.cnf  //查看狀態   app1 (pid:13675) is running(0:PING_OK), master:192.168.10.103   //說明已經啓用
[root@manage mha]# masterha_stop --conf=/etc/mha/app1.cnf  //關閉監控

到這兒，mha咱們就配置好了。

十，說一下，個人測試過程

1,mysql -u test -p -h 192.168.10.130，經過虛擬IP登陸

2,插入數據，查看一下主103有沒有該數據，以及二個從服務器，是否是同步了數據。

3,在主103上，執行crm node standby,會帶來幾種結果。

在220機器上，/etc/mha/app1.cnf

[server1]
hostname=192.168.10.103
port=3306

這段配置消失了。

在219機器上，show master status;是有數據的，變成主機了

在209機器上，show slave status\G;中 Master_Host: 192.168.10.219，變成219了。

4，在103上面，執行# crm node online,這個時候，103既不是主，也不是從，standby後mysqld進程被關閉，因此在這兒要啓動mysqld，而後在將103加入到219中。

mysql> CHANGE MASTER TO MASTER_HOST='192.168.10.219',
MASTER_USER='test', MASTER_PASSWORD='test',
MASTER_LOG_FILE='mysql-bin.000048',
MASTER_LOG_POS=107;

5,在線切換主從

[root@manage mysql]# masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=192.168.10.103 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000
Wed Apr 29 04:14:55 2015 - [info] MHA::MasterRotate version 0.55.
Wed Apr 29 04:14:55 2015 - [info] Starting online master switch..
Wed Apr 29 04:14:55 2015 - [info]
Wed Apr 29 04:14:55 2015 - [info] * Phase 1: Configuration Check Phase..
Wed Apr 29 04:14:55 2015 - [info]
Wed Apr 29 04:14:55 2015 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Wed Apr 29 04:14:55 2015 - [info] Reading application default configurations from /etc/mha/app1.cnf..
Wed Apr 29 04:14:55 2015 - [info] Reading server configurations from /etc/mha/app1.cnf..
Wed Apr 29 04:14:55 2015 - [info] Current Alive Master: 192.168.10.219(192.168.10.219:3306)
Wed Apr 29 04:14:55 2015 - [info] Alive Slaves:
Wed Apr 29 04:14:55 2015 - [info] 192.168.10.209(192.168.10.209:3306) Version=5.1.73-log (oldest major version between slaves) log-bin:enabled
Wed Apr 29 04:14:55 2015 - [info] Replicating from 192.168.10.219(192.168.10.219:3306)

It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 192.168.10.219(192.168.10.219:3306)? (YES/no): yes
Wed Apr 29 04:15:10 2015 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..
Wed Apr 29 04:15:10 2015 - [info] ok.
Wed Apr 29 04:15:10 2015 - [info] Checking MHA is not monitoring or doing failover

。。。。。。。。。。。。。省略了。。。。。。。。。。。。。。。

這樣就切換到最原始的狀態了。