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 [email protected]
# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
# ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
上面有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
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 --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
[1] 13675
[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
。。。。。。。。。。。。。省略了。。。。。。。。。。。。。。。
這樣就切換到最原始的狀態了。
MySQL MHA測試之感
基本與MMM相同。
測試之前我想過兩個問題:
1)在主從切換之後應用如何訪問new master?
2)一台MHA Manager服務器上能否監控多組MySQL主從架構?
部署安裝都不太難,看文檔就可以搞定,這裡也不列出。
我搞了個兩組MySQL主從架構,每組三台機器:Master-Premary、Master-Standby、Slave。
另外一台MHA Manger。
測試基本順利,也了解了MHA工作機制。
總結一下:
1)MHA只負責主從Failover,它沒有一個固定的接口提供給應用端,所以在現實環境中,還是需要Keepalived等工具來提供VIP;
2)單台MHA Manager服務器上無法監控多組MySQL主從,會提示沖突;
3)MHA Failover時間非常快,也較穩定;
4)MHA Failover時候會將Master-Standby也就是New Master給reset slave處理,所以後期需要手動恢復。
我需要的答案基本都得到了,前面提到的兩個問題答案並不很完美,所以暫時沒考慮應用到公司生產環境上。