MySQL高可用解決方案---MHA
阿新 • • 發佈:2017-11-15
linux、mysql
一主兩從一管理,一共四臺設備
MHA的作用是做master的高可用,當主節點MySQL故障時,會將和主節點數據最接近的一個從節點提升為主節點,同時如果其他從節點有更新的數據也會同步到此“準主節點”上。如果在主節點有數據已經提交但是所有的從節點還未完成復制,則從節點提升為主節點後只能將此數據回退,沒有別的辦法。
準備事項:
1、同步時間
ntpdate 172.18.0.1
2、配置主機域名,在主節點即node1上操作
vim /etc/hosts 192.168.1.101 node1 #主節點 192.168.1.106 node2 #從節點 192.168.1.107 node3 #從節點 192.168.1.100 node4 #manager scp /etc/hosts node2:/etc/hosts scp /etc/hosts node3:/etc/hosts scp /etc/hosts node4:/etc/hosts
3、MHA需要ssh無密鑰驗證
ssh-keygen -t rsa -P ‘‘ cd /root/.ssh/ ssh-copy-id -i ./id_rsa.pub root@node1 scp id_rsa{,.pub} authorized_keys node2:/root/.ssh scp id_rsa{,.pub} authorized_keys node3:/root/.ssh scp id_rsa{,.pub} authorized_keys node4:/root/.ssh
下面開始具體步驟:
1、配置主從復制集群
node1: vim /etc/my.cnf.d/server.cnf [server] skip_name_resolve=ON innodb_file_per_table=ON server_id = 1 log_bin = master-log relay_log = relay-log #主節點也要配置中繼日誌,因為主節點故障再恢復時就會稱為從節點
node2: vim /etc/my.cnf.d/server.cnf [server] skip_name_resolve=ON innodb_file_per_table=ON server_id = 2 relay_log = relay-log log_bin = master-log relay_log_purge = OFF read_only = ON node3: vim /etc/my.cnf.d/server.cnf [server] skip_name_resolve=ON innodb_file_per_table=ON server_id = 3 relay_log = relay-log log_bin = master-log relay_log_purge = OFF read_only = ON
開啟服務
systemctl start mariadb.service
2、在主節點授權復制賬號
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO ‘repluser‘@‘192.168.1.%‘ IDENTIFIED BY ‘centos‘;
主節點授權管理設備的管理賬號
GRANT ALL ON *.* TO ‘mhaadmin‘@‘192.168.1.%‘ IDENTIFIED BY ‘centos‘;
寫入磁盤
FLUSH PRIVILEGES;
3、在從節點配置
CHANGE MASTER TO MASTER_HOST=‘192.168.1.101‘,MASTER_USER=‘repluser‘,MASTER_PASSWORD=‘centos‘,MASTER_LOG_FILE=‘master-log.000003‘,MASTER_LOG_POS=245; START SLAVE ; SHOW SLAVE STATUS\G; SELECT USER FROM mysql.user; #能看到復制授權賬戶和管理賬戶已經同步
4、安裝MHA軟件包
在manager節點安裝manager和node包
yum -y install mha4mysql-manager-0.56-0.el6.noarch.rpm yum -y install mha4mysql-node-0.56-0.el6.noarch.rpm
5、在node上安裝node包
yum -y install mha4mysql-node-0.56-0.el6.noarch.rpm
6、在manager上配置
mkdir /etc/masterha vim /etc/masterha/app1.cnf [server default] user=mhaadmin password=centos manager_workdir=/data/masterha/app1 manager_log=/data/masterha/app1/manager.log remote_workdir=/data/masterha/app1 ssh_user=root repl_user=repluser repl_password=centos ping_interval=1 [server1] hostname=192.168.1.101 ssh_port=22 candidate_master=1 [server2] hostname=192.168.1.106 ssh_port=22 candidate_master=1 [server3] hostname=192.168.1.107 ssh_port=22 candidate_master=1
7、檢查配置並啟動服務
檢查 masterha_check_ssh --conf=/etc/masterha/app1.cnf masterha_check_repl --conf=/etc/masterha/app1.cnf 啟動manager服務器 masterha_manager --conf=/etc/masterha/app1.cnf
8、測試
此時模擬主節點故障
SHOW MASTER STATUS; SHOW SLAVE STATUS; #在從節點查看從節點信息,此時有一個從節點已經升級為主節點
9、修復原主節點
vim /etc/my.cnf.d/server.cnf #添加兩行 relay_log_purge = OFF read_only = ON 再次開啟服務上線 systemctl start mariadb.service CHANGE MASTER TO MASTER_HOST=‘192.168.1.106‘,MASTER_USER=‘repluser‘,MASTER_PASSWORD=‘centos‘,MASTER_LOG_FILE=‘master-log.000003‘,MASTER_LOG_POS=320; START SLAVE; SHOW SLAVE STATUS\G; #此時的主節點就是替代的原從節點
10、在manager上檢查復制功能
masterha_check_repl --conf=/etc/masterha/app1.cnf 出現如下字樣就說明主從已經切換了,而且原主節點此時也變成了從節點 192.168.1.106(192.168.1.106:3306) (current master) +--192.168.1.101(192.168.1.101:3306) +--192.168.1.107(192.168.1.107:3306)
11、再次啟動MHA
nohup masterha_manager --conf=/etc/masterha/app1.cnf &> /data/masterha/app1/manager.log & #在後臺執行,並剝離與當前終端的關系 #當主節點再次down掉,此程序會自動結束同時主從節點自動切換。然後我們還要再次手動開啟MHA
至此實驗結束
本文出自 “a_pan” 博客,謝絕轉載!
MySQL高可用解決方案---MHA