MySQL5.7高可用MHA
阿新 • • 發佈：2020-11-22
MySQL高可用MHA
一、架構工作原理
主庫宕機處理過程 1. 監控節點 (通過配置檔案獲取所有節點資訊) 系統,網路,SSH連線性 主從狀態,重點是主庫 2.選主 2.1.優先順序(主觀)，如果在節點配置時，加入了candidate_ master= 1引數。 如果備選主，日誌量落後master太多 (後master 100M的relay logs的話，)也不會被選擇新主。可以通過check repl delay=0， 不檢查日誌落後的情景。 2.2.日誌量最接近主庫 2.3.日誌量一樣。配置檔案順序。 3.日誌補償 #情況1: ssh能連上，通過save binary logs立即儲存缺失部分的日誌到從庫(/var/tmp目錄下)並恢復。 #情況2: ssh不能連，兩個從庫進行relaylog日誌diff(apply diff relay logs)差異補償。 4.主從身份切換，所有從庫取消和原有主庫的複製關係(stop slave; reset slave all)新主庫和剩餘從庫 重新構建主從關係。 5.故障庫自動被剔除叢集(masterha conf host配置資訊去掉) 6. MHA是一次性的高可用，Failover後， Manager自動推出。
二、架構介紹
1主2從，master：master slave：slave1 slave2 ）：
MHA 高可用方案軟體構成
Manager軟體：選擇一個從節點安裝
Node軟體：所有節點都要安裝
# 架構不足的地方
0.應用透明
1.資料補償
2.自動提醒
3.自愈功能待開發....
MHA + k8s + Operator官方
8.0 MGR + mysqlsh
三、 MHA軟體構成
Manager工具包主要包括以下幾個工具： masterha_manger 啟動MHA masterha_check_ssh 檢查MHA的SSH配置狀況 masterha_check_repl 檢查MySQL複製狀況 masterha_master_monitor 檢測master是否宕機 masterha_check_status 檢測當前MHA執行狀態 masterha_master_switch 控制故障轉移（自動或者手動） masterha_conf_host 新增或刪除配置的server資訊 Node工具包主要包括以下幾個工具： 這些工具通常由MHA Manager的指令碼觸發，無需人為操作 save_binary_logs 儲存和複製master的二進位制日誌 apply_diff_relay_logs 識別差異的中繼日誌事件並將其差異的事件應用於其他的 purge_relay_logs 清除中繼日誌（不會阻塞SQL執行緒）
四、MHA環境搭建
4.1、環境規劃
主庫:
192.168.1.111 Node軟體
從庫:
192.168.1.112 Node軟體
192.168.1.113 Node軟體 Manager軟體（生產建議把Manager軟體獨立放另一臺伺服器上）
4.2、準備環境（略。1主2從GTID）
看另外的筆記吧，簡單明瞭
4.3、配置各節點互信（免密登入）
master： rm -rf /root/.ssh ssh-keygen cd /root/.ssh mv id_rsa.pub authorized_keys scp -r /root/.ssh 192.168.1.112:/root scp -r /root/.ssh 192.168.1.113:/root
4.4、配置關鍵程式軟連線(三臺機器上都是)
ln -s /data/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /data/mysql/bin/mysql /usr/bin/mysql
4.5、 安裝mha、Node
mha官網：https://code.google.com/archive/p/mysql-master-ha/
github下載地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads
4.5.1、所有節點安裝Node軟體依賴包
# 下載好mha4mysql-node-0.56-0.el6.noarch.rpm，上傳到三臺機器的/app目錄下，執行以下命令
[root@slave1 app]# yum install perl-DBD-MySQL -y
[root@slave1 app]# rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
4.6、在主庫新建使用者
grant all privileges on *.* to mha@'192.168.1.%' identified by 'mha';
grant all privileges on *.* to mha@'%' identified by 'mha';
#兩個從庫檢查
mysql -p123 -e "select user,host from mysql.user;"
4.7、軟體安裝（在從庫192.168.1.113 上）
# 把下載好的軟體mha4mysql-manager-0.56-0.el6.noarch.rpm上傳到slave2的/app目錄下，執行以下命令
[root@slave2 app]# yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
[root@slave2 app]# rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm
4.7.1、 Manager配置檔案（在從庫192.168.1.113 上）
# 建立配置檔案目錄、建立日誌目錄
[root@slave2 app]# mkdir -p /etc/mha
[root@slave2 app]# mkdir -p /var/log/mha/app1
# 編輯mha配置檔案
cat > /etc/mha/app1.cnf << EFO
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/mysql #主節點日誌檔案目錄
user=mha #mha工作過程中專用的使用者，剛剛上面新建的
password=mha #mha工作過程中專用的使用者，剛剛上面新建的
ping_interval=2 #監控間隔時間，2秒一次
repl_password=123 #主從複製的密碼
repl_user=tzh #主從複製的使用者
ssh_user=root
[server1]
hostname=192.168.1.111
port=3306
[server2]
hostname=192.168.1.112
port=3306
[server3]
hostname=192.168.1.113
port=3306
EFO
4.8、狀態檢查（在從庫192.168.1.113 上）
# 互信檢查
[root@slave2 app]# masterha_check_ssh --conf=/etc/mha/app1.cnf
# 看到如下日誌表示成功
Sun Nov 22 04:10:12 2020 - [info] All SSH connection tests passed successfully.
# 主從狀態檢查
[root@slave2 app]# masterha_check_repl --conf=/etc/mha/app1.cnf
# 看到如下日誌表示成功
MySQL Replication Health is OK.
4.9、開啟MHA（在從庫192.168.1.113 上）
[root@slave2 app]# 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 &
4.10、檢視MHA狀態
[root@slave2 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:19660) is running(0:PING_OK), master:192.168.1.111
[root@slave2 ~]# mysql -umha -pmha -h 192.168.1.111 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 51 |
+---------------+-------+
[root@slave2 ~]# mysql -umha -pmha -h 192.168.1.112 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 52 |
+---------------+-------+
[root@slave2 ~]# mysql -umha -pmha -h 192.168.1.113 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 53 |
+---------------+-------+
4.11、故障模擬及處理
### 停主庫master
[root@master app]# systemctl stop mysqld
觀察manager 日誌 tail -f /var/log/mha/app1/manager
末尾必須顯示successfully，才算正常切換成功。
Master 192.168.1.111(192.168.1.111:3306) is down!
Check MHA Manager logs at slave2:/var/log/mha/app1/manager for details.
Started automated(non-interactive) failover.
Selected 192.168.1.112(192.168.1.112:3306) as a new master.
192.168.1.112(192.168.1.112:3306): OK: Applying all logs succeeded.
192.168.1.113(192.168.1.113:3306): OK: Slave started, replicating from 192.168.1.112(192.168.1.112:3306)
192.168.1.112(192.168.1.112:3306): Resetting slave info succeeded.
Master failover to 192.168.1.112(192.168.1.112:3306) completed successfully.
4.12、故障恢復
A、修復主庫
[root@master app]# systemctl start mysqld
B、恢復主從結構
CHANGE MASTER TO
MASTER_HOST='192.168.1.112', #現在112是主庫了
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1,
MASTER_USER='tzh',
MASTER_PASSWORD='123';
start slave ;
C、修改配置檔案
[root@slave2 ~]# vim /etc/mha/app1.cnf 加上這段（當你開啟會驚喜的發現沒有了這段哦）
[server1]
hostname=192.168.1.111
port=3306
D、啟動MHA
[root@slave2 ~]# 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 &
五、Manager額外引數介紹
說明：
主庫宕機誰來接管？
1. 所有從節點日誌都是一致的，預設會以配置檔案的順序去選擇一個新主。
2. 從節點日誌不一致，自動選擇最接近於主庫的從庫
3. 如果對於某節點設定了權重（candidate_master=1），權重節點會優先選擇。
但是此節點日誌量落後主庫100M日誌的話，也不會被選擇。可以配合check_repl_delay=0，關閉日誌量的檢查，強制選擇候選節點。
(1) ping_interval=1
#設定監控主庫，傳送ping包的時間間隔，嘗試三次沒有迴應的時候自動進行failover
(2) candidate_master=1
#設定為候選master，如果設定該引數以後，發生主從切換以後將會將此從庫提升為主庫，即使這個主庫不是叢集中事件最新的slave
(3)check_repl_delay=0
#預設情況下如果一個slave落後master 100M的relay logs的話，
MHA將不會選擇該slave作為一個新的master，因為對於這個slave的恢復需要花費很長時間，通過設定check_repl_delay=0,MHA觸發切換在選擇一個新的master的時候將會忽略複製延時，這個引數對於設定了candidate_master=1的主機非常有用，因為這個候選主在切換的過程中一定是新的master
六、MHA 的vip功能
6.1、新增引數（Manager上，slave3）
注意：/usr/local/bin/master_ip_failover，必須事先準備好 #自帶vip只能在同機房實現
[root@slave2 ~]# vim /etc/mha/app1.cnf
# 加在[server default]標籤下即可
master_ip_failover_script=/usr/local/bin/master_ip_failover
6.1.2、指令碼
[root@slave2 ~]# vim /usr/local/bin/master_ip_failover
#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';
use Getopt::Long;
my (
$command, $ssh_user, $orig_master_host, $orig_master_ip,
$orig_master_port, $new_master_host, $new_master_ip, $new_master_port
);
my $vip = '192.168.1.254/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key down";
GetOptions(
'command=s' => \$command,
'ssh_user=s' => \$ssh_user,
'orig_master_host=s' => \$orig_master_host,
'orig_master_ip=s' => \$orig_master_ip,
'orig_master_port=i' => \$orig_master_port,
'new_master_host=s' => \$new_master_host,
'new_master_ip=s' => \$new_master_ip,
'new_master_port=i' => \$new_master_port,
);
exit &main();
sub main {
print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";
if ( $command eq "stop" || $command eq "stopssh" ) {
my $exit_code = 1;
eval {
print "Disabling the VIP on old master: $orig_master_host \n";
&stop_vip();
$exit_code = 0;
};
if ($@) {
warn "Got Error: $@\n";
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "start" ) {
my $exit_code = 10;
eval {
print "Enabling the VIP - $vip on the new master - $new_master_host \n";
&start_vip();
$exit_code = 0;
};
if ($@) {
warn $@;
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "status" ) {
print "Checking the Status of the script.. OK \n";
exit 0;
}
else {
&usage();
exit 1;
}
}
sub start_vip() {
`ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
sub stop_vip() {
return 0 unless ($ssh_user);
`ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}
sub usage {
print
"Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}
# 給許可權
[root@slave2 ~]# chmod +x /usr/local/bin/master_ip_failover
# 主庫手工加VIP
# 手工在主庫上繫結vip，注意一定要和配置檔案中的ethN一致，我的是ens33:1(1是key指定的值)
[root@master ~]# yum install net-tools -y #三臺機器都得安裝
[root@master ~]# ifconfig ens33:1 192.168.1.254/24
[root@master ~]# ifconfig ens33:1 down
6.2、郵件提醒
#沒做
1. 引數：
report_script=/usr/local/bin/send
2. 準備郵件指令碼
send_report
(1)準備發郵件的指令碼(上傳 email_2019-最新.zip中的指令碼，到/usr/local/bin/中)
(2)將準備好的指令碼新增到mha配置檔案中,讓其呼叫
3. 修改manager配置檔案，呼叫郵件指令碼
vi /etc/mha/app1.cnf
report_script=/usr/local/bin/send
（3）停止MHA
masterha_stop --conf=/etc/mha/app1.cnf
（4）開啟MHA
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 &
(5) 關閉主庫,看警告郵件
6.3、重啟mha
[root@master ~]# masterha_stop --conf=/etc/mha/app1.cnf
[root@master ~]# 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 &
七、binlog server（slave2上）
binlogserver配置：
找一臺額外的機器，必須要有5.6以上的版本，支援gtid並開啟，我們直接用的第二個slave（db03）
vim /etc/mha/app1.cnf
# 在最後加上就行
[binlog1]
no_master=1 #主庫宕機、切換的時候不切到這裡了
hostname=192.168.1.113 #本機ip
master_binlog_dir=/data/mysql/binlog #日誌目錄
# 建立目錄
# 修改完成後，將主庫binlog拉過來（從000001開始拉，之後的binlog會自動按順序過來）
[root@slave2 ~]# mkdir -p /data/mysql/binlog
[root@slave2 ~]# chown mysql.mysql -R /data/mysql/binlog
#拉取主庫binlog日誌
[root@slave2 ~]# cd /data/mysql/binlog ----->必須進入到自己建立好的目錄
#host是主庫的IP,不做這個會報錯哦
[root@slave2 binlog]# mysqlbinlog -R --host=192.168.1.111 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
注意：
#到主庫show master status;看看在使用那個binlog檔案，從這個開始啦就行！
拉取日誌的起點,需要按照目前從庫的已經獲取到的二進位制日誌點為起點
mysqlbinlog -R --host=192.168.1.111 --user=mha --password=mha --raw --stop-never mysql-bin.000xxx &
# 檢視
[root@slave2 binlog]# ll
total 16
-rw-r----- 1 root root 177 Nov 22 00:05 mysql-bin.000001
-rw-r----- 1 root root 3435 Nov 22 00:05 mysql-bin.000002
-rw-r----- 1 root root 379 Nov 22 00:05 mysql-bin.000003
-rw-r----- 1 root root 359 Nov 22 00:05 mysql-bin.000004
八、再次測試，把主庫停機
# 關閉主庫
[root@master ~]# systemctl stop mysqld
# 觀察slave2上的日誌情況
[root@slave2 ~]# tail -f /var/log/mha/app1/manager
主庫宕機，binlogserver 自動停掉，manager 也會自動停止。
處理思路：
1、重新獲取新主庫的binlog到binlogserver中
2、重新配置檔案binlog server資訊
3、最後再啟動MHA
故障修復：
1. 恢復故障節點
（1）例項宕掉
/etc/init.d/mysqld start
（2）主機損壞，有可能資料也損壞了
備份並恢復故障節點。
2.恢復主從環境
看日誌檔案：恢復新主庫的日誌
CHANGE MASTER TO MASTER_HOST='192.168.1.112', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='tzh', MASTER_PASSWORD='123';
start slave ;
3.恢復manager
3.1 修好的故障節點配置資訊，加入到配置檔案
[server1]
hostname=10.0.0.51
port=3306
3.2 檢視VIP是否在master，不在就手動加
3.2 啟動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 &