登录
  • 欢迎访问悠扬的技术博客,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站😉

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

Mysql 悠扬 967次浏览 已收录 0个评论

架构图

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

一、环境说明

是否还记得我的机器选择的节点是130呢,看看mha通信是否正常,其他的先别整,跟着我走

常用命令说明

请确保mha服务正常启动,别跟着执行哦,这是做个记录🐱‍👤

manager组件

masterha_check_ssh 检查 MHA 的 SSH 配置状况
masterha_check_repl 检查 MySQL 复制状况
masterha_manger 启动 manager的脚本
masterha_check_status 检测当前 MHA 运行状态
masterha_master_monitor 检测 master 是否宕机
masterha_master_switch 控制故障转移(自动或者手动)
masterha_conf_host 添加或删除配置的 server 信息
masterha_stop 关闭manager

node组件

save_binary_logs 保存和复制 master 的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的 slave
filter_mysqlbinlog 去除不必要的 ROLLBACK 事件

检查ssh

masterha_check_ssh --conf=/etc/mha/app1.cnf

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

检查复制情况

masterha_check_repl --conf=/etc/mha/app1.cnf

[root@d-sn-003 scripts]# masterha_check_repl conf=/etc/mha/app1.cnf

…..省略输出
MySQL Replication Health is OK.

检查mha状态

masterha_check_status --conf=/etc/mha/app1.cnf
[root@d-sn-003 scripts]# masterha_check_status –conf=/etc/mha/app1.cnf
…..省略输出 app1 is stopped(2:NOT_RUNNING).

启动MHA Manager,推荐使用这个,有啥区别,查阅linux黑洞

nohup masterha_manager --conf=/etc/mha/app1.cnf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &

关闭 MHA-manager

masterha_stop --conf=/etc/mha/app1.cnf

二、配置vip

找到mha4mysql-manager/samples/scripts下面的几个执行文件。看过我其他两篇文章的人知道,我的在下面放着。

[root@d-sn-003 scripts]# pwd
/etc/mha/scripts
[root@d-sn-003 scripts]# ls
master_ip_failover master_ip_online_change power_manager send_report
master_ip_failover 自动切换时 VIP 管理的脚本
master_ip_online_change 在线切换时 vip 的管理
power_manager 故障发生后关闭主机的脚本
send_report 因故障切换后发送报警的脚本

修改内容如下:(删除原有内容,直接复制并修改vip相关参数,vip自定义)

echo '' > /etc/mha/scripts/master_ip_failover
vim /etc/mha/scripts/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.32.231';         #指定vip的地址,虚拟网卡地址
my $brdc = '192.168.32.255';        #指定vip的广播地址。广播地址,和真实网卡一致,见下面红色的标记
my $ifdev = 'ens33';          #指定vip绑定的网卡
my $key = '1';            #指定vip绑定的虚拟网卡序列号
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";   #代表此变量值为ifconfig ens33:1 192.168.32.130
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key down";  #代表此变量值为ifconfig ens33:1 192.168.32.130 down
my $exit_code = 0;           #指定退出状态码为0
#my $ssh_start_vip = "/usr/sbin/ip addr add $vip/24 brd $brdc dev $ifdev label $ifdev:$key;/usr/sbin/arping -q -A -c 1 -I $ifdev $vip;iptables -F;";
#my $ssh_stop_vip = "/usr/sbin/ip addr del $vip/24 dev $ifdev label $ifdev:$key";
##################################################################################
    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 \"`;
}
## A simple system call that disable the VIP on the old_master
sub stop_vip() {
    `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";
}

说明文件:

manager_log manager日志
manager_workdir manager工作目录
master_binlog_dir master保存binlog的位置,这里的路径要与master里配置的binlog的路径一致,以便MHA能找到
master_ip_failover_script 设置自动failover时候的切换脚本,也就是上面的那个脚本
master_ip_online_change_script 设置手动切换时候的切换脚本
report_script 设置发生切换后发送的报警的脚本
secondary_check_script 指定检查的从服务器IP地址
user 设置监控用户
password 监控用户的那个密码
repl_user 设置复制用户的用户
repl_password 设置复制用户的密码
ping_interval 设置监控主库,发送ping包的时间间隔1秒,默认是3秒,尝试三次没有回应的时候自动进行failover
shutdown_script 设置故障发生后关闭故障主机脚本(该脚本的主要作用是关闭主机防止发生脑裂,这里没有使用)
ssh_user 设置ssh的登录用户名
candidate_master 设置为候选master,设置该参数以后,发生主从切换以后将会将此从库提升为主库,即使这个主库不是集群中最新的slave
check_repl_delay 默认情况下如果一个slave落后master 超过100M的relay logs的话,MHA将不会选择该slave作为一个新的master, 因为对于这个slave的恢复需要花费很长时间;通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时,这个参数对于设置了candidate_master=1的主机非常有用,因为这个候选主在切换的过程中一定是新的master

示例:

[server default]
manager_log=/var/log/mha/app1/manager.log
manager_workdir=/var/log/mha/app1.log
master_binlog_dir=/usr/local/mysql/data
master_ip_failover_script=/etc/mha/scripts/master_ip_failover
master_ip_online_change_script=/etc/mha/scripts/master_ip_online_change
ping_interval=1
remote_workdir=/tmp
repl_user=repl
repl_password=Root2020@
report_script=/etc/mha/scripts/send_report
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.32.129 -s 192.168.32.130
shutdown_script=””
ssh_user=root
user=manager
password=Root2020@

[server1]
hostname=192.168.32.128
port=3306

[server2]
hostname=192.168.32.129
port=3306
candidate_master=1

check_repl_delay=0

[server3]
hostname=192.168.32.130
port=3306

遇到一个问题做记录:找不到binlog地址,这是接文章二里面更详细的操作

000020 --slave_pass=xxx
Wed Mar 10 14:18:58 2021 - [info] Connecting to root@192.168.32.129(192.168.32.129:22)..
Can't exec "mysqlbinlog": 没有那个文件或目录 at /usr/local/share/perl5/MHA/BinlogManager.pm line 106.
mysqlbinlog version command failed with rc 1:0, please verify PATH, LD_LIBRARY_PATH, and client options
at /usr/local/bin/apply_diff_relay_logs line 532.

解决方案记录:

在三台节点分别执行

192.168.2.128 [root ~]$ ln -s /usr/local/mysql/bin/mysqlbinlog /usr/local/bin/mysqlbinlog
192.168.2.128 [root ~]$ ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql

192.168.2.129 [root ~]$ ln -s /usr/local/mysql/bin/mysqlbinlog /usr/local/bin/mysqlbinlog
192.168.2.129 [root ~]$ ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql

192.168.2.130 [root ~]$ ln -s /usr/local/mysql/bin/mysqlbinlog /usr/local/bin/mysqlbinlog
192.168.2.130 [root ~]$ ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql

我的这一步就修复了

另一种情况,还是报错,纠结N久,才发现原因是:原来Failover两种方式:一种是虚拟IP地址,一种是全局配置文件。MHA并没有限定使用哪一种方式,而是让用户自己选择,虚拟IP地址的方式会牵扯到其它的软件,比如keepalive软件,而且还要修改脚本master_ip_failover。

所以先暂时注释master_ip_failover_script= /usr/local/bin/master_ip_failover这个选项。后面引入keepalived后和修改该脚本以后再开启该选项

192.168.2.130 [root ~]$ grepvim master_ip_failover /etc/masterha/app1.cnf
#master_ip_failover_script= /usr/local/bin/master_ip_failover 

三、开启MHA测试故障转移

1.启动服务

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover /var/log/mha/app1/manager.log 2>&1 &
查看日志
tail -f /var/log/mha/app1/manager.log

2.开启虚拟网卡

在master上面手动开启vip,128节点

[root@d-sn-003 scripts]# ifconfig ens33:1 192.168.32.231/24
[root@d-sn-003 scripts]# ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.32.130 netmask 255.255.255.0 broadcast 192.168.32.255
inet6 fe80::a871:7019:a8b2:4dd3 prefixlen 64 scopeid 0x20<link>
inet6 fe80::b7f3:a1ad:d5fd:4703 prefixlen 64 scopeid 0x20<link>
inet6 fe80::e0ff:2f78:bcb:3556 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:c1:ba:8d txqueuelen 1000 (Ethernet)
RX packets 174639 bytes 103095302 (98.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 207823 bytes 162574377 (155.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens33:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.32.231 netmask 255.255.255.0 broadcast 192.168.32.255
ether 00:0c:29:c1:ba:8d txqueuelen 1000 (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 24826 bytes 41912418 (39.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 24826 bytes 41912418 (39.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复
3.模拟故障,自动故障转移

在 Master 节点 Mysql1 上停止mysql服务
systemctl stop mysqld
此时经过脚本处理,虚拟网卡漂移到129节点去了,去129上面看网卡
ifconfig

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

故障转移已完成,查看日志128 master is down!

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

四、故障修复

查看当前129主节点,slave关系
[root@d-sn-002 ~]# mysql -e “show master status;” -uroot -pRoot2020@
mysql: [Warning] Using a password on the command line interface can be insecure.
+——————+———-+————–+——————+——————-+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+——————+———-+————–+——————+——————-+
| mysql-bin.000009 | 504 | | | |
+——————+———-+————–+——————+——————-+
mysql -e “show slave hosts;” -uroot -pRoot2020@

可以看到当前129挂载了一个slave节点server_id是3,也就是manager配置的server3 130节点

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

1.开始故障恢复

先去MHA日志里面找找恢复语句

grep “All other slaves should start replication from here” /var/log/mha/app1/manager.log
[root@d-sn-003 ~]# grep “All other slaves should start replication from here” /var/log/mha/app1/manager.log
Thu Mar 11 10:38:49 2021 – [info] All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST=’192.168.32.129′, MASTER_PORT=3306, MASTER_LOG_FILE=’mysql-bin.000009′, MASTER_LOG_POS=504, MASTER_USER=’repl’, MASTER_PASSWORD=’xxx’;
你可别直接去128上面执行个密码是XXX的命令,替换成自己的
去128节点,启动mysql
systemctl restart mysqld
mysql -uroot -pRoot2020@
CHANGE MASTER TO MASTER_HOST=’192.168.32.129′, MASTER_PORT=3306, MASTER_LOG_FILE=’mysql-bin.000009′, MASTER_LOG_POS=504, MASTER_USER=’repl’, MASTER_PASSWORD=’Root2020@’;
start slave;
show slave status\G;
# 在130上检查
masterha_check_repl --conf=/etc/mha/app1.cnf

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

看看129上面,slave host情况,server1 128恢复过来已经重新建立主从关系了

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

在 manager 节点上修改配置文件app1.cnf(再把这个128节点添加进去,因为它检测掉失效时候会自动消失)
vim /etc/masterha/app1.cnf

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

具体内容如下:

[server default]
manager_log=/var/log/mha/app1/manager.log
manager_workdir=/var/log/mha/app1.log
master_binlog_dir=/usr/local/mysql/data
master_ip_failover_script=/etc/mha/scripts/master_ip_failover
master_ip_online_change_script=/etc/mha/scripts/master_ip_online_change
password=Root2020@
ping_interval=1
remote_workdir=/tmp
repl_password=Root2020@
repl_user=repl
report_script=/etc/mha/scripts/send_report
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.32.128 -s 192.168.32.130
shutdown_script=””
ssh_user=root
user=manager

[server1]
candidate_master=1
check_repl_delay=0
hostname=192.168.32.128
port=3306

[server2]
hostname=192.168.32.129
port=3306

[server3]
hostname=192.168.32.130
port=3306

进行检查配置

执行命令:masterha_check_repl --conf=/etc/mha/app1.cnf

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

重启MHA进行检查
masterha_stop --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover /var/log/mha/app1/manager.log 2>&1 &
masterha_check_status --conf=/etc/mha/app1.cnf

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

检测一下,执行命令
masterha_check_repl --conf=/etc/mha/app1.cnf

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

搞定,收工

2.主库故障手动转移

Switchover切换:手动切换128为主库,129为备库,但是这个玩意下是不是就谈不到什么高可用了,服务在当前状态已经停止了

在主库故障后,MHA进程未启动的情况下,我们手动来切换。这种情况为MySQL主从关系中主库因为故障宕机了,但是MHA Master监控并没有开启,这个时候就需要手动来failover了。该情况下,日志打印输出和自动failover是没有什么区别的。需要注意的是,如果主库未宕机,那么不能手动执行故障切换,会报错的。

查看集群状态,主从连接情况
[root@d-sn-003 ~]# masterha_check_repl –conf=/etc/mha/app1.cnf
Fri Mar 12 08:47:02 2021 – [info] Reading default configuration from /etc/masterha_default.cnf..
……..省略输出

mysql: [Warning] Using a password on the command line interface can be insecure.
done.
Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Fri Mar 12 08:49:58 2021 – [info] Slaves settings check done.
Fri Mar 12 08:49:58 2021 – [info]
192.168.32.129(192.168.32.129:3306) (current master)
+–192.168.32.128(192.168.32.128:3306)
+–192.168.32.130(192.168.32.130:3306)

Fri Mar 12 08:49:58 2021 – [info] Checking replication health on 192.168.32.128..
Fri Mar 12 08:49:58 2021 – [info] ok.
Fri Mar 12 08:49:58 2021 – [info] Checking replication health on 192.168.32.130..
Fri Mar 12 08:49:58 2021 – [info] ok.
Fri Mar 12 08:49:58 2021 – [info] Checking master_ip_failover_script status:
Fri Mar 12 08:49:58 2021 – [info] /etc/mha/scripts/master_ip_failover –command=status –ssh_user=root –orig_master_host=192.168.32.129 –orig_master_ip=192.168.32.129 –orig_master_port=3306

IN SCRIPT TEST====/sbin/ifconfig ens33:1 down==/sbin/ifconfig ens33:1 192.168.32.231===

Checking the Status of the script.. OK
Fri Mar 12 08:49:58 2021 – [info] OK.
Fri Mar 12 08:49:58 2021 – [warning] shutdown_script is not defined.
Fri Mar 12 08:49:58 2021 – [info] Got exit code 0 (Not master dead).

检查MHA运行状态,stop状态下才能执行手动切换
[root@d-sn-003 ~]# masterha_check_status –conf=/etc/mha/app1.cnf
app1 is stopped(2:NOT_RUNNING).
检查SSH互信状态,别在这个上面载跟头
[root@d-sn-003 ~]# masterha_check_ssh –conf=/etc/mha/app1.cnf
……..
Fri Mar 12 09:18:01 2021 – [debug] Connecting via SSH from root@192.168.32.130(192.168.32.130:22) to root@192.168.32.129(192.168.32.129:22)..
Fri Mar 12 09:18:01 2021 – [debug] ok.
Fri Mar 12 09:18:01 2021 – [info] All SSH connection tests passed successfully.
查看虚拟网卡状态
[root@d-sn-002 ~]# ifconfig
不存在需要新建,存在就不要执行了
#建立主节点虚拟网卡
ifconfig ens33:1 192.168.32.231/24
不截图了,就是129上面虚拟网卡启用上面有,这个搞错了,把自己打一顿去

开始模拟故障 :idea: 

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

关闭主库129
systemctl stop mysql
在130管理节点上面执行
masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=dead --ignore_last_failover --interactive=0 \
--dead_master_host=192.168.32.129  --dead_master_host=192.168.32.129 --dead_master_port=3306  \
--new_master_host=192.168.32.128 --new_master_port=3306

执行情况👀

[root@d-sn-003 ~]# masterha_master_switch –conf=/etc/mha/app1.cnf –master_state=dead –ignore_last_failover –interactive=0 \
> –dead_master_host=192.168.32.129  –dead_master_host=192.168.32.129 –dead_master_port=3306  \
> –new_master_host=192.168.32.128 –new_master_port=3306
–dead_master_ip=<dead_master_ip> is not set. Using 192.168.32.129.
–dead_master_port=<dead_master_port> is not set. Using 3306.
Fri Mar 12 10:19:18 2021 – [info] Reading default configuration from /etc/masterha_default.cnf..
Fri Mar 12 10:19:18 2021 – [info] Reading application default configuration from /etc/mha/app1.cnf..
Fri Mar 12 10:19:18 2021 – [info] Reading server configuration from /etc/mha/app1.cnf..

去128上面看网卡已经飘过去了

Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复

剩下的流程不写了,就写下流程,一旦遇到了,别抓虾,我不推荐手动切,这是一旦宕机,MHA又没有启动,没办法的办法

  1. 重启129节点,旧的master节点,重新挂载成128的slave节点
  2. 修改mha配置文件,把检测和主备节点顺序进行调整
  3. 启动MHA,过程中别忘记检测每个组件,别在小问题上翻船。

3.配置邮件预警功能,注意手动切和自动切都会发送邮件

1.安装所需工具包
yum -y install cpan
cpan install Email::Simple
cpan install Email::Sender::Simple
cpan install Email::Sender::Transport::SMTP::TLS
2.修改mha配置邮件发送脚本
vim /etc/mha/app1.cnf
加入如下:脚本路径配置,放在ip漂移脚本下面
report_script = /etc/mha/scripts/send_report
3.修改邮件脚本
#!/usr/bin/perl

#  Copyright (C) 2011 DeNA Co.,Ltd.
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#   along with this program; if not, write to the Free Software
#  Foundation, Inc.,
#  51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA

## Note: This is a sample script and is not complete. Modify the script based on your environment.

use strict;
use warnings FATAL => 'all';
use Mail::Sender;
use Getopt::Long;

#new_master_host and new_slave_hosts are set only when recovering master succeeded
my ($dead_master_host, $new_master_host, $new_slave_hosts, $subject, $body);

my $smtp='smtp.qq.com';          # 这里的smtp可以查看要使用的邮箱的smtp值, 或者百度
my $mail_from='xxx@qq.com';# 填写邮箱
my $mail_user='xxx@qq.com';# 填写邮箱
my $mail_pass='toymwrgrpdghbiei';# 注意这里的密码是邮箱开启smtp服务时设定的密码, 不是邮箱的登陆密码
#my $mail_to=['to1@qq.com','to2@qq.com'];
my $mail_to='xxx@qq.com';      # 接受邮件的邮箱

GetOptions(
  'orig_master_host=s' => \$dead_master_host,
  'new_master_host=s'  => \$new_master_host,
  'new_slave_hosts=s'  => \$new_slave_hosts,
  'subject=s'          => \$subject,
  'body=s'             => \$body,
);

# Do whatever you want here
mailToContacts($smtp,$mail_from,$mail_user,$mail_pass,$mail_to,$subject,$body);

sub mailToContacts {
    my ($smtp, $mail_from, $mail_user, $mail_pass, $mail_to, $subject, $msg ) = @_;
    open my $DEBUG, "> /var/log/mha/app1/manager.log" # 这里的路径需要修改你自己的日志配置
        or die "Can't open the debug    file:$!\n";
    my $sender = new Mail::Sender {
        ctype        => 'text/plain;charset=utf-8',
        encoding    => 'utf-8',
        smtp        => $smtp,
        from        => $mail_from,
        auth        => 'LOGIN',
        TLS_allowed    => '0',
        authid        => $mail_user,
        authpwd        => $mail_pass,
        to        => $mail_to,
        subject        => $subject,
        debug        => $DEBUG
    };
    $sender->MailMsg(
        {
            msg => $msg,
            debug => $DEBUG
        }
    ) or print $Mail::Sender::Error;
    return 1;
}

exit 0;
4.启动MHA 停止主节点,看看有没有邮件发送成功,你可一定要记着,虚拟网卡要跟着主节点
masterha_check_repl --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover /var/log/mha/app1/manager.log 2>&1 &
masterha_check_status --conf=/etc/mha/app1.cnf
查看日志,看邮件发送情况
tail -f /var/log/mha/app1/manager.log

 

4.mysql-utilities包

        MySQL Utilities 是一组基于python语言编写的python库的命令行实用工具集,依赖于python 2.6。该工具提供了MySQL数据库运维工程中常用的一些工具,诸如克隆、复制、比较、差异、导出、导入、安装、配置、索引、磁盘查看等等。有了这个工具包,就好比那些个神医大夫,不管大病小病,先去搞个化验,搞个CT,你也可以当华佗。MySQL Utilities提供了各种平台的软件包,如果没有找到对应自己平台的包,可以通过源码进行编译安装。

5.MySQL主从同步搭建方法

数据安全,备份很重要,主从同步是最常用的方案。一方面保证了数据安全,另一方面能满足实时的数据查询统计的需要,并且不影响主库性能。
常用的建立主从同步的方法有以下三种:
1)、直接复制数据库目录到从库实例中,启动从库实例并开启从库同步。
此方法只能针对数据库是MyISAM类型的,原因是此类型的数据库所有表结构和表数据都存放在对应的数据库名称的目录下。而InnoDB类型的数据库则不行,因为此类型数据库的数据结构与数据是分开存放于不同文件中的。
这里简单讲一下这两种引擎的区别:InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型,这两个表类型各有优劣,视具体应用而定。基本的差别为:MyISAM类型不支持事务处理等高级处理,而InnoDB类型支持。MyISAM类型的表强调的是性能,其执行数度比InnoDB类型更快,但是不提供事务支持,而InnoDB提供事务支持已经外部键等高级数据库功能。
2)、通过mysqldump导出数据,再通过mysql导入到从库实例,启动从库同步。
此方法能确保数据的完整性和通用性,在不同版本之间可以完成数据还原。但时间会相对较长,主要表现在导入时比较慢。适合在不同版本间或时间较充裕时选用。
3)、通过innobackupex工具在线热备。
此方法主要特点是能在不影响主库的业务使用同时进行整个数据库实例的备份,执行时间的长短取决于整个数据库的大小。常用于还没有任何从库且主库业务不能中断的应用场景。
 
在这里我主要细讲一下第2种方式,其他方法可以找相应的文档或资料学习。
主要步骤如下 :

1、部署从库实例;
2、在主库添加从库同步权限;
     GRANT Replication slave,Replication client ON *.* TO tongbu@host IDENTIFIED BY ‘tongbu’;
3、在主库锁表后,导出数据并记录快照点参数;

     FLUSH tables with read lock; show master status; 记录好File和Position值。
4、数据导出完成后,解锁表;
     Unlock tables;
5、在从库实例上导入数据,并启用同步操作;
     stop slave;
     change master to master_host=’IP’, master_port = xxxx, master_user=’tongbu’, master_password=’tongbu’,  master_log_file=’File’, master_log_pos= Position;
     start slave;
6、查看从库同步状态;
    Show slave status\G
关键看Slave_IO_Running 和 Slave_SQL_Running 值,如果全部为Yes,说明同步起来了。
再看Seconds_Behind_Master 值,如果为正数n,说明有n条SQL待同步,如果为0说明已经实时同步成功。
搭建从库的时候需要注意的一些地方:
  1. 从库实例的版本不能低于主库的,一般是采用相同版本或者更高版本;
  2. 复制数据时务必保证其完整性和一致性;
  3. 从库实例的server-id必须与主库不同;
  4. 在主库快照时必须记录好相应的文件名和位置点;
  5. 从库同步起来后,务必加好状态监控.

6. mha启动脚本配置解决进程异常退出

cd /etc/mha/
vi start_mha.sh

编写如下脚本

#!/bin/bash
/usr/bin/nohup /usr/local/bin/masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover /var/log/mha/app1/manager.log 2>&1 &

退出后运行脚本就可以,查看执行状态可以通过如下:

1.ps aux|grep master
2. masterha_check_status –conf=/etc/mha/app1.cnf

五、手动安全停止集群服务

1.端口vip虚拟网卡配置,vip网卡下线

2.关闭MHA服务,让MHA下线,这样不会发生主从切换

3.查看slave数据同步情况,等待数据同步完成

4.关闭slave 从节点数据库

5.关闭master主节点数据库

六、MHA日志清理

删除方式:
    方式一:通过MHA中自带的工具 purge_relay_logs 工具来删除。(安全) 最好后面直接加到定时任务中
    方式二:手动删除 relay log。   

方式一:

purge_relay_logs --user=root --password=xxx自己的密码 --host=127.0.0.1 --disable_relay_log_purge  (默认就行了,不写目录什么的了)

可能会报:

打开的文件过多 at /usr/local/bin/purge_relay_logs line 82.
             main::open_relay_logs() called at /usr/local/bin/purge_relay_logs line 236
             eval {...} called at /usr/local/bin/purge_relay_logs line 172
             main::main() called at /usr/local/bin/purge_relay_logs line 73

解决办法:

查看linux打开文件数允许
ulimit -n 
临时设置一个数值(按需设置)
ulimit -n 4096

方式二:(有点危险,谨慎操作)

(1) 统计所有关于relay的文件(包括 relay_log_name.index)总个数

ls -A1 |grep relay | sort -rn | wc -l

(2) 列出要删除所有有关relay的文件:

ls -A1 |grep relay | sort -rn | tail -n 100

说明: 100 为要删除的relay logs 数量

(3) 确定没有问题,删除relay logs:

ls -A1 |grep relay | sort -rn | tail -n 100 | xargs rm -rf {}

注意:
要保留最新的两个relay log
要保留relay log的index文件
relay log的index一般命名为: relay_log_name.index
例如: relay-bin.index

七、记一次MHA高可用切换一半服务器断电后的情况

       只做场景文字说明,和问题排查记录,发生问题的时候,有点奇怪,server节点配置信息文件my.cnf文件中记录的serverid已经发送变更,但是主从关系没有变更成功,主从节点均出现binlog日志,查看发现目前其实主节点并没有自动切换成功,查看master和slave状态情况发现,binlog日志配置信息已经脱节很久了,这时就得取舍了,一是否需要停机,完全删除从库,拷贝导入一次主库数据,二是选择忽略这部分数据丢失,优先进行主从信息建立恢复,默认从库丢掉这一部分数据,这时有问题就来了,可能主库有结构变更,从库结构已经不一致,那么这时会有假象,mha恢复成功一段时间后继续出现同步异常,此时就要根据日志分析,手动处理表结构,出现问题表进行结构调整与主库保存一直,而后重新建立关联进行观察,反复操作,直到MHA恢复正常。

      个人建议金融电商等对数据要求高的服务,进行如下操作:

  1. 找一台全新的服务器,进行同网段文件拷贝,拷贝mysql数据文件到新服务器,进行配置启动mysql服务,这个过程取决于数据盘大小,请进行自我评估
  2. 快速修复,配置主库业务重启,配置虚拟ip恢复vip代理,按上面所说快速恢复主从关系
  3. 使用第三方插件入DataX,与新服务器上的mysql进行数据对比,进行数据补偿操作,这时别用自增ID,有什么坑应该都懂得

以上说法仅供参考,生产环境请根据场景进行评估,别看到方案就按照别人的直接操作 :P 

记录下本次异常排错查看命令:

show binlog events;
show master logs;
show variables like 'log_%';
set global sql_slave_skip_counter=1;
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_PORT=xxx, MASTER_LOG_FILE='mysql-bin.002244', MASTER_LOG_POS=830023131, MASTER_USER='repl',MASTER_PASSWORD='xxx';

 

 

 


版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复
喜欢 (1)
支付宝[]
分享 (0)
悠扬
关于作者:
10年以上工作经验,从事2年微服务架构搭建工作,有大数据处理相关工作经验,使用spring全家桶包括:Spring,SpringBoot,SpringCloud 数据层组件服务使用SpringDataJpa,Mybatis以及其他第三方组件Sharding-JDBC,Sharding-Proxy分库分表。熟悉微服务,服务降级,限流,分流,做过项目源码修改,有cat,apollo,nacos使用经验,有Lostash,Elasticsearch,kibana,mysqlMHA生产实践经验,使用开源代码Apache Sarding项目,修改源码支持mysql分库分表使用年月日小时分库分表,docker做集群服务,Jekins做项目发布,GitLab做项目管理,使用docker容器部署,熟悉消息队列RabbitMQ,Kafka,ActiveMQ。RuoYi-Vue-Atomikos项目开源加入生态圈组件,项目支持分布式事务,界面添加多数据源,数据源动态配置,切面切换,多数据源事务支持,支持区域数据源配置,用于区域数据切分,数据层次分库。项目地址:https://gitee.com/zsiyang/ruoyi-vue-atomikos
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址