十三、mysql高可用 1、普通主從複製架構存在的不足 高可用? 業務不間斷的工作。 用戶的體驗不出來業務斷點。 普通主從環境,存在的問題: 2、企業高可用解決方案: MMM(過時) MHA(目前推薦) PXC、Galera Cluster(出現很多年,企業很少用) 5.7.17 MGR 、Inno ...
十三、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