基於MHA+semi sync實現mysql數據庫的高可用
1、拓撲結構圖如下:
2、工作原理:
從宕機崩潰的master保存二進制日誌事件(binlog events)
識別含有最新更新的slave
應用差異的中繼日誌(relay log)到其他的slave
應用從master保存的二進制日誌事件(binlog events)
提升一個slave為新的master
使其他的slave連接新的master進行復制
3、工具包:
MHA軟件由兩部分組成,Manager工具包和Node工具包
1、 Manager工具包主要包括以下幾個工具:
masterha_check_ssh 檢查MHA的SSH配置狀況
masterha_check_repl 檢查MySQL復制狀況
masterha_manger 啟動MHA
masterha_check_status 檢測當前MHA運行狀態
masterha_master_monitor 檢測master是否宕機
masterha_master_switch 故障轉移(自動或手動)
masterha_conf_host 添加或刪除配置的server信息
2、Node工具包:這些工具通常由MHA Manager的腳本觸發,無需人為操作)主要包括以下幾個工具:
save_binary_logs 保存和復制master的二進制日誌
apply_diff_relay_logs 識別差異的中繼日誌事件並將其差異的事件應用於其他的slave
filter_mysqlbinlog 去除不必要的ROLLBACK事件(MHA已不再使用此工具)purge_relay_logs 清除中繼日誌(不會阻塞SQL線程)
二、實驗環境準備:
1、vmware中準備四臺虛擬主機
主機名分別為manager,master,slave1,slave2 系統為centos7
對應ip:192.168.190.128-131
2、setenforce 0 關掉selinux
iptables -F 清掉防火墻
3、配置好yum源,以及epel源
4、四臺虛擬主機保證時間同步,ntpdate命令
三、實驗步驟:
1、四臺主機實現ssh無密連接
ssh-keygen 任意一臺主機生成公鑰私鑰對
ssh-copy-id 192.168.190.128 生成文件在.ssh目錄
scp -r /root/.ssh 192.168.190.129
scp -r /root/.ssh 192.168.190.130
scp -r /root/.ssh 192.168.190.131
2、manager節點
(1) yum install mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm
(2) mkdir /data/mastermha/app1/ -pv
(3)vim /etc/mastermha/app1.cnf
[server default]
user=mhauser 主服務器的管理賬號
password=centos mhauser的密碼
manager_workdir=/data/mastermha/app1/ 工作目錄
manager_log=/data/mastermha/app1/manager.log 日誌目錄
remote_workdir=/data/mastermha/app1/
ssh_user=root ssh連接賬號
repl_user=repluser 復制賬號
repl_password=centos 復制賬號的密碼
ping_interval=1
[server1]
hostname=192.168.190.129 主服務器
candidate_master=1 有機會晉升為主
[server2]
hostname=192.168.190.130 從服務器
candidate_master=1 有機會晉升為主
[server3]
hostname=192.168.190.131 從服務器
candidate_master=1 有機會晉升為主
3、master,slave1,slave2節點
yum install mha4mysql-node-0.56-0.el6.noarch.rpm
4、master節點
(1)systemctl start mariadb
(2)vim /etc/my.cnf
log-bin 啟用二級制
server_id=1 服務器id,每個節點必須不同
innodb_file_per_table 每個庫,每張表
skip_name_resolve=1 通過ip連接,不解析主機名
log_slave_updates = 1 主從切換時用
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so" 加載半同步復制的插件,主從的都裝,主壞,從頂上時實現半同步
loose_rpl_semi_sync_master_enabled = 1 開啟主的半同步功能
loose_rpl_semi_sync_slave_enabled = 1 開啟從的半同步功能
loose_rpl_semi_sync_master_timeout = 5000
mysql
mysql>show master logs
mysql>grant replication slave on *.* to repluser@‘192.168.31.%‘ identified by ‘centos‘;
mysql>grant all on *.* to mhauser@‘192.168.190.%’ identified by ‘magedu‘;
show variables like ‘%semi%‘;
5、slave1節點和slave2節點
vim /etc/my.cnf
[mysqld]
server_id=2 不同節點此值各不相同
log-bin
read_only 只讀,對超級用戶無效,主壞切換為主時,全局變量會變
relay_log_purge=0 不刪除中繼日誌
skip_name_resolve=1 不解析主機名,通過ip連接
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so" 加載半同步復制的插件,主從的都裝,主壞,從頂上時實現半同步
loose_rpl_semi_sync_master_enabled = 1 開啟主的半同步功能
loose_rpl_semi_sync_slave_enabled = 1 開啟從的半同步功能
loose_rpl_semi_sync_master_timeout = 5000
mysql>CHANGE MASTER TO MASTER_HOST=‘MASTER_IP‘, MASTER_USER=‘repluser‘, MASTER_PASSWORD=‘centos‘, MASTER_LOG_FILE=‘mariadb-bin.000001‘, MASTER_LOG_POS=245;
6、 manager節點上進行測試
1、masterha_check_ssh --conf=/etc/mastermha/app1.cnf 檢測ssh連通性
2、masterha_check_repl --conf=/etc/mastermha/app1.cnf 檢測復制功能
3、masterha_manager --conf=/etc/mastermha/app1.cnf 啟動mha管理
4、停掉主節點的mariadb服務,查看對應的日誌
發現原來主節點已經轉移了
對於壞的故障主節點可以重新設置為集群裏面的從節點,需要再次修改manager的配置文件
註意:第一次主從切換時,/data/mastermha/app1/會生成app1.failover.complete空文件,下次再次切換的時候如果發現該目錄下存在該文件將不允許觸發切換,若再次切換,將其刪除。mha的管理工具,一次性在前臺執行,發生故障後,需手動再次開啟。
基於MHA+semi sync實現mysql數據庫的高可用