MySQL高可用及讀寫分離（MHA）

轉載自：https://blog.51cto.com/12083623/2360114
1、普通主從複製架構存在的不足

高可用？
業務不間斷的工作。
用戶的體驗不出來業務斷點。

普通主從環境，存在的問題：

1、監控的問題：APP應用程序，並不具備監控數據庫的功能，沒有責任監控數據庫是否能連接。
2、選主的問題
3、failover：VIP漂移，對於應用透明
4、數據補償
2、企業高可用解決方案：

MMM（過時）
MHA（目前推薦）
PXC、Galera Cluster（出現很多年，企業很少用）
5.7.17 MGR 、Innodb Cluster（未來的趨勢，儘早研究）
MySQL NDB Cluster（出現很多年，仍然不完善）
MyCAT 高可用
3、MHA高可用架構部署實戰：

3.0 MHA介紹及工作原理

（1）Manager程序負責監控所有已知Node（1主2從所有節點）
（2）當主庫發生意外宕機
（2.1）mysql實例故障（SSH能夠連接到主機）
0、監控到主庫宕機，選擇一個新主（取消從庫角色，reset slave），選擇標準：數據較新的從庫會被選擇爲新主(show slave status\G)
1、從庫通過MHA自帶腳本程序，立即保存缺失部分的binlog
2、二號從庫會重新與新主構建主從關係，繼續提供服務
3、如果VIP機制，將vip從原主庫漂移到新主，讓應用程序無感知
（2.2）主節點服務器宕機（SSH已經連接不上了）
0、監控到主庫宕機，嘗試SSH連接，嘗試失敗
1、選擇一個數據較新的從庫成爲新主庫（取消從庫角色 reset slave），判斷細節：show slave status\G
2、計算從庫之間的relay-log的差異，補償到2號從庫
3、二號從庫會重新與新主構建主從關係，繼續提供服務
4、如果VIP機制，將vip從原主庫漂移到新主，讓應用程序無感知
5、如果有binlog server機制，會繼續講binlog server中的記錄的缺失部分的事務，補償到新的主庫
3.1、安裝mha node：

依賴包perl-DBD-MySQL ，並在三個節點都安裝node軟件
rpm包直接
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

3.2、主庫中創建mha管理用戶
grant all privileges on . to mha@'10.0.0.%' identified by 'mha';

3.3、配置軟連接

ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql
3.4、部署manger節點（建議在從節點db03）

wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
3.5、安裝 manager軟件

rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

3.6、創建Manager必須目錄與配置文件

mkdir -p /etc/mha
mkdir -p /var/log/mha/app1 ----》可以管理多套主從複製
創建配置文件 (不需要的配置不要留着，註釋沒用,切換後會重寫)
vim /etc/mha/app1.cnf -----》serverdefault可以獨立

[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
user=mha
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root

[server1]
hostname=10.0.0.51
port=3306

[server2]
hostname=10.0.0.52
port=3306

[server3]
hostname=10.0.0.53
port=3306
3.7、配置互信(所有節點)

ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa >/dev/null 2>&1

ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected]
ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected]
ssh-copy-id -i /root/.ssh/id_dsa.pub [email protected]
3.8、檢測互信

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

3.9、檢測主從
masterha_check_repl --conf=/etc/mha/app1.cnf

3.10、啓動MHA manager
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、宕掉db01主庫
2、tail -f /var/log/mha/app1/manager 觀察日誌變化
3、恢復主庫運行，重新將db01加入到主從複製關係中
CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
4、將配置文件中加入修好的故障節點
5、啓動MHA了manager程序

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

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

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 &
3.11、使用MHA自帶腳本實現IP FailOver(vip 漂移，應用透明)

配置步驟
上傳準備好的/usr/local/bin/master_ip_failover
dos2unix /usr/local/bin/master_ip_failover

vim /etc/mha/app1.cnf
添加：
master_ip_failover_script=/usr/local/bin/master_ip_failover

重啓mha

masterha_stop --conf=/etc/mha/app1.cnf

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 &
手工在主庫上綁定vip，注意一定要和配置文件中的ethN一致，我的是eth0:1(1是key指定的值)

ifconfig eth0:1 10.0.0.55/24

切換測試：
停主庫，看vip是否漂移

11、binlogserver配置：
找一臺額外的機器，必須要有5.6以上的版本，支持gtid並開啓，我們直接用的第二個slave

[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog
提前創建好,這個目錄不能和原有的binlog一致

mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/mysql/*
修改完成後，將主庫binlog拉過來（從000001開始拉，之後的binlog會自動按順序過來）

cd /data/mysql/binlog -----》必須進入到自己創建好的目錄

mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
重啓MHA，生效配置：

重啓mha

masterha_stop --conf=/etc/mha/app1.cnf

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 &
12、其他參數說明

ping_interval=2 manager檢測節點存活的間隔時間，總共會探測4次。
#設置爲候選master，如果設置該參數以後，發生主從切換以後將會將此從庫提升爲主庫，即使這個主庫不是集羣中事件最新的slave
candidate_master=1
#默認情況下如果一個slave落後master 100M的relay logs的話，MHA將不會選擇該slave作爲一個新的master，
因爲對於這個slave的恢復需要花費很長時間，通過設置check_repl_delay=0,
MHA觸發切換在選擇一個新的master的時候將會忽略複製延時，這個參數對於設置了candidate_master=1的主機非常有用，
因爲這個候選主在切換的過程中一定是新的master
check_repl_delay=0