十三、mysql高可用
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軟體
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.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
#mha小bug只能在/usr/bin下使用
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必要目錄與組態檔（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.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]
測驗：ssh 10.0.0.51 date
...
3.8、檢測互信
masterha_check_ssh --conf=/etc/mha/app1.cnf
3.9、檢測主從
masterha_check_ssh --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 &
tail -f /var/log/mha/app1/manager
故障演練：
1、宕掉db01主庫
/etc/init.d/mysqld stop
2、tail -f /var/log/mha/app1/manager 觀察日志變化(實時監控日志)
3、恢復主庫運行，重新將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;
4、將組態檔中加入修稿的故障節點(宕機后自動洗掉被洗掉的server資訊)
5、啟動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.11、使用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.12、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.13、其他引數說明
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
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/44475.html
標籤：MySQL