數據庫學習之十三：mysql高可用配置

十3、mysql高可用

一、普通主從複製架構存在的不足

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

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

一、監控的問題：APP應用程序，並不具有監控數據庫的功能，沒有責任監控數據庫是否能鏈接。
二、選主的問題：
三、failover：VIP漂移，對於應用透明
四、數據補償

二、企業高可用解決方案：

MMM（過期）

MHA（目前推薦）
PXC、Galera Cluster（出現不少年，企業不多用）
5.7.17 MGR 、Innodb Cluster（將來的趨勢，儘早研究）
MySQL NDB Cluster（出現不少年，仍然不完善）
MyCAT 高可用

三、MHA高可用架構部署實戰：

3.0 MHA介紹及工做原理

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

3.一、安裝mha node：

依賴包perl-DBD-MySQL ，並在三個節點都安裝node軟件

MHA高可用架構部署細節:
三臺MySQL獨立節點實例，主機名、IP、防火牆關閉等
開啓1主2從GTID複製結構
關閉各節點relay-log自動刪除功能
各節點部署node工具包及依賴包
選擇其中一個從節點進行部署manager工具包
各節點ssh祕鑰互信配置
配置manager節點配置文件（注意：在數據庫中添加mha管理用戶和密碼）
作ssh互信檢查和主從狀態檢查
開啓MHA功能

檢查防火牆和enforce開關狀況：
iptables -L
getenforce
關閉二進制日誌刪除功能：relay_log_purge=0;
數據庫中全局關閉：set relay_log_purge=0;
檢查狀態：mysql -e "show variables like '%relay%'";
上傳MHA軟件，而後解壓：unzip mha.zip
#涉及到安裝兩個軟件，node和manager；
依賴包perl-DBD-MySQL ，並在三個節點都安裝node軟件（三個節點都安裝node）
rpm包直接
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

3.二、主庫中建立mha管理用戶

grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';		(會同步給從庫)

3.三、配置軟鏈接

ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql
#mha小bug只能在/usr/bin下使用

3.四、部署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.五、安裝 manager軟件

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

3.六、建立Manager必要目錄與配置文件（DB03）

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.七、配置互信(全部節點)

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

ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.51
ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.52
ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.53

測試：ssh 10.0.0.51 date
...

3.八、檢測互信

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

3.九、檢測主從

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

3.十、啓動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 &

tail -f /var/log/mha/app1/manager

故障演練：

一、宕掉db01主庫
/etc/init.d/mysqld stop
二、tail -f /var/log/mha/app1/manager  觀察日誌變化(實時監控日誌)
三、恢復主庫運行，從新將db01加入到主從複製關係中
檢查狀態：
show slave stauts\G;
/etc/init.d/mysqld start
CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
start slave;
show slave status\G;
四、將配置文件中加入修稿的故障節點(宕機後自動刪除被刪除的server信息)
五、啓動MHA了manager程序（經歷主庫宕機後，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.十一、使用MHA自帶腳本實現IP FailOver(vip 漂移，應用透明)
#################################END#########################################

配置步驟

上傳準備好的/usr/local/bin/master_ip_failover(腳本文件)
chmod +x 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一致（master_ip_failover），個人是eth0:1(1是key指定的值)

ifconfig eth0:1 10.0.0.55/24

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

/etc/init.d/mysqld stop

3.十二、binlogserver配置：

找一臺額外的機器，必需要有5.6以上的版本，支持gtid並開啓，咱們直接用的第二個slave
vim /etc/mha/app1.cnf（在10.0.0.53機器上）
[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     -----》必須進入到本身建立好的目錄，在主庫的/data/binlog目錄中查看是不是從如下001開始的。

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 &

3.1三、其餘參數說明
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