mysql-mha高可用
一．方案介紹
在上一篇文章中已經介紹了mmm方案，接下來介紹一下mha方案，mha方案在淘寶和58同城有在使用。MHA(mysql-master-ha)。
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的阻塞寫入是可以接受的。因此切換主服務器不需要計劃分配維護時間窗口(呵呵，不需要你在夜黑風高時通宵達旦完成切換主服務器的任務)。
二．方案部署
1.MHA方案的優缺點
優點：相比mmm方案可以自動同步差異的日志，可以自己寫故障轉移的腳本，比較靈活
缺點：如果故障轉移了需要重新修改配置文件，重新啟動masterha_manager服務
2.安裝部署
服務器IP | 角色 | OS | mysql | 說明 |
| 10.1.10.24 | Monitor節點 | Centos 5.5 64bit | --- | |
| 10.1.10.4 | Master 節點 | Centos 5.5 64bit | Mysql5.5.18 | |
| 10.1.10.16 | Slave節點(master替補節點) | Centos 5.5 64bit | Mysql5.5.18 | |
| 10.1.10.70 | Slave | Centos 5.5 64bit | Mysql5.5.18 |
2. 在數據庫節點安裝node
首先安裝yum -y install perl-DBD-MySQL
tar -zxvpf mha4mysql-node-0.54.tar.gz
perl Makefile.PL
make && make install
3. 在管理節點安裝mha manager
yum install perl-DBD-MySQL
yum install perl-Config-Tiny
yum install perl-Log-Dispatch
yum install perl-Parallel-ForkManager
yum install perl-Config-IniFiles
tar -zxvpf mha4mysql-manager-0.54.tar.gz
perl Makefile.PL
make && make install
4.編輯管理節點的配置文件
mkdir /etc/masterha
mkdir -p /masterha/app1
cp samples/conf/* /etc/masterha/
cat /etc/masterha/app1.cnf
[server default]
manager_workdir=/masterha/app1
manager_log=/masterha/app1/manager.log
user=mha_mon
password=123456
ssh_user=root
repl_user=repl
repl_password=replPAS
ping_interval=1
shutdown_script=""
master_ip_online_change_script=""
report_script=""
#master_ip_failover_script="/usr/local/bin/master_ip_failover"
[server1]
hostname=10.1.10.4
master_binlog_dir=/data/dbdata/mysqllog/binlog
candidate_master=1
[server2]
hostname=10.1.10.16
master_binlog_dir=/data/dbdata/mysqllog/binlog
candidate_master=1
[server3]
hostname=10.1.10.70
master_binlog_dir=/data/dbdata/mysqllog/binlog
5.配置機器之間相互ssh的訪問
在每臺機器上面執行ssh-keygen -t rsa，會生成兩個文件id_rsa和Identity.pub。
在10.1.10.27點上執行
ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.1.10.4
ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.1.10.16
ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.1.10.70
同理在其余的三臺機器上面也把分別自己的rsa傳到剩余的機器上面，這樣這四臺機器之間就可以相互ssh登陸了。
6.測試ssh連接
masterha_check_ssh --conf=/etc/masterha/app1.cnf
如果正常，會顯示MySQL Replication Health is OK.
7.建立mha監控訪問賬號
GRANT ALL PRIVILEGES ON *.* TO 'mha_mon'@'10.1.10.%' IDENTIFIED BY ‘123456’
8.測試機器之間的復制連接
masterha_check_repl --conf=/etc/masterha/app1.cnf
如果正常，會顯示MySQL Replication Health is OK
9.啟動管理幾點的進程
nohup masterha_manager --conf=/etc/masterha/app1.cnf > /tmp/mha_manager.log< /dev/null 2>&1 &
10.檢查MHA的狀態
masterha_check_status --conf=/etc/masterha/app1.cnf
如果正常，會顯示[PING_OK]，否則會顯示[NOT_RUNNING]
3．故障轉移測試
關閉master 10.1.10.4的mysql服務，slave 10.1.10.16升級為master ,slave 10.1.10.70的maseter
連接指向了10.1.10.16,自動完成了切換。Master 10.1.10.4節點從集群中排除。
切換的日志如下：
----- Failover Report -----
app1: MySQL Master failover 10.1.10.4 to 10.1.10.16 succeeded
Master 10.1.10.4 is down!
Check MHA Manager logs at localhost:/masterha/app1/manager.log for details.
Started automated(non-interactive) failover.
The latest slave 10.1.10.16(10.1.10.16:3306) has all relay logs for recovery.
Selected 10.1.10.16 as a new master.
10.1.10.16: OK: Applying all logs succeeded.
10.1.10.70: This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
10.1.10.70: OK: Applying all logs succeeded. Slave started, replicating from 10.1.10.16.
10.1.10.16: Resetting slave info succeeded.
Master failover to 10.1.10.16(10.1.10.16:3306) completed successfully.
雖然這里完成了slave到master的升級切換，但是對于前段應用程序來說，還要更換IP地址，這是比較麻煩的。那么如何通知前端應用程序呢？這里需要在配置文件中設置如下兩個參數。
u master_ip_failover_script
u master_ip_online_change_script
說到Failover，通常有兩種方式：一種是虛擬IP地址，一種是全局配置文件。MHA并沒有限定使用哪一種方式，而是讓用戶自己選擇，虛擬IP地址的方式會牽扯到其它的軟件(vrrpd).
如果要測試效果的話，可以kill掉當前的MySQL主服務器，稍等片刻，MHA就會把某臺MySQL從服務器提升為新的MySQL主服務器，并調用master_ip_failover_script腳本，我們在master_ip_failover_script腳本里可以把新的MySQL主服務器的ip和port信息持久化到配置文件里，這樣應用就可以使用新的配置了。
有時候需要手動切換MySQL主服務器，可以使用masterha_master_switch命令，不過它調用的不是master_ip_failover_script腳本，而是master_ip_online_change_script腳本，但調用參數類似，腳本可以互用。
三．MHA適用于的復制
1.單個master,多個 slaves
M(RW)M(RW), promoted from S1
||
+------+------+--(master crash)-->+-----+-----+
S1(R) S2(R)S3(R)S2(R)S3(R)
M服務器down掉，s1升級為M. 這是一種最常見的結構。
2.單個master,多個slave(其中一個slave是遠程的數據中心，不作為升級master的目標)
M(RW)M(RW), promoted from S1
||
+------+---------+--(master crash)-->+-----+------+
S1(R) S2(R)Sr(R,no_master=1) S2(R)Sr(R,no_master=1)
需在配置文件sr機器設置no_master=1
3.單個master，多個slave，一個候選master
M(RW)-----S0(R,candidate_master=1)M(RW), promoted from S0
||
+----+----+--(master crash)-->+----+----+
S1(R)S2(R)S1(R)S2(R)
需在配置文件s0機器設置candidate_master=1
4.多臺master，多個slave
M(RW)<--->M2(R,candidate_master=1)M(RW), promoted from M2
||
+----+----+--(master crash)-->+----+----+
S(R)S2(R)S1(R)S2(R)
需在配置文件M2機器設置candidate_master=1
5.三層復制結構
M(RW)M(RW), promoted from S1
||
+------+---------+--(master crash)-->+-----+------+
S1(R) S2(R)Sr(R)S2(R)Sr(R)
||
++
Sr2Sr2
Sr2不要在配置文件中配置
6.三層復制結構，多個master
M1(host1,RW) <-----------------> M2(host2,read-only)
||
+-----+--------++
S1(host3,R)S2(host4,R)S3(host5,R)
=> After failover
M2(host2,RW)
|
+--------------+--------------------------+
S1(host3,R)S2(host4,R)S3(host5,R)
[server default]
multi_tier_slave=1
[server1]
hostname=host1
candidate_master=1
[server2]
hostname=host2
candidate_master=1
[server3]
hostname=host3
[server4]
hostname=host4
[server5] hostname=host5
轉載于:https://blog.51cto.com/appoint/1288311
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的mysql-mha高可用的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： pro mvvm 读书笔记
- 下一篇： SQL执行效率总结