当前位置： 首页 > news >正文

MySQL的MHA高可用集群解决方案应用实战（下）

news 2025/10/7 9:14:37

MySQL的MHA高可用集群解决方案应用实战（上）https://coffeemilk.blog.csdn.net/article/details/152333810

一、MHA的配置

Home · yoshinorim/mha4mysql-manager Wikihttps://github.com/yoshinorim/mha4mysql-manager/wiki

 1.1、MHA的主配置文件介绍

MHA的主配置文件选项介绍
序号MHA的主配置文件选项说明
1user

默认root，表示MySQL的用户名。

之所以默认用root用户是因为MHA要通过此用户执行很多命令如：STOP SLAVE, CHANGE MASTER, RESET SLAVE等。

2password指定的MySQL user的密码，若指定了mysql用户为root，那么这里就是root用户的密码。
3ssh_user操作系统的用户名（Manager节点和mysql主从复制节点），因为要应用，解析各种日志，推荐使用root用户，默认是MHA manager上当前用户。
4ssh_port操作系统的ssh端口号（不指定端口号时默认是22）
5repl_userMySQL主从复制线程的用户名（最好加上）
6repl_passwordMySQL主从复制线程的密码（最好加上）
7ping_intervalMHA通过 ping SQL的方式监控master状态，此选项用来设置MHA manager多久去检查一次master，默认3秒，如果三次间隔都没反应，那么MHA就会认为master已经出现问题了。如果MHA Manager连不上Master是因为连接数过多错误或者认证失败，此时MHA将不会认为master出问题。
8secondary_check_script

默认情况下，MHA通过单个路由（即从Manager到Master）来检查Master的可用性，这种默认的监控机制不够完善，不过，MHA还提供了一个监控master的接口，那就是通过调用secondary_check_script参数，通过定义外部脚本来实现多路由监测。

MHA还提供了一个监控master的接口，那就是通过调用secondary_check_script参数，通过定义外部脚本来实现多路由监测【其中，masterha_secondary_check是MHA提供的一个监测脚本remote_host1、remote_host2是远程的两台主机，建议不要和MHA manager主机在同一个网段中】

#（示例如下）
secondary_check_script = masterha_secondary_check -s remote_host1 -s remote_host2

masterha_secondary_check脚本的监测机制是：

Manager-(A)->remote_host1-(B)->master_host
Manager-(A)->remote_host2-(B)->master_host

        监测脚本会首先通过Manager主机检测到远程主机的网络状态，这个过程是A，接着，再通过远程主机检查到master_host的状态，这个过程为B。
        在过程A中，Manager主机需要通过ssh连接到远程的机器上，所以需要manager主机到远程机器上建立public key信任。在过程B中，masterha_secondary_check是通过远程主机和Master建立TCP连接来测试Master是否存活的。

        在所有的路由中，如果A成功，B失败，那么MHA才认为master出现了问题，进而执行failover操作，其它情况，一律认为master是正常状态。也就是不会进行failover操作。一般来讲，　强烈推荐使用多个网络上的机器，通过不同路由策略来检查MySQL Master存活状态。

9master_ip_failover_script

此选项用来设置VIP漂移动作，默认MHA不会做VIP漂移，但可以通过master_ip_failover_script来指定一个VIP漂移脚本，MHA源码包中自带了一个VIP漂移脚本master_ip_failover，稍加修改就能使用。

10master_ip_online_changes_script这个参数有点类似于master_ip_failover_script,但这个参数不用于master故障转移，而是master在线的切换，使用masterha_master_switch命令手动切换MySQL主服务器时后会调用此脚本。 
11shutdown_script设置故障发生后关闭故障主机的脚本（该脚本的主要作用是关闭主机，防止发生脑裂），此脚本是利用服务器的远程控制IDRAC等，使用ipmitool强制去关机，以避免fence设备重启主服务器，造成脑列现象。
12report_script用来设置当新主服务器切换完成以后通过此脚本发送邮件报告。
13manager_workdirMHA Manager的工作目录，默认： /var/tmp
14manager_logMHA manager的日志目录，如果不设置，就是标准输出，和标准错误输出。
15master_binlog_dirmaster上产生binlog日志对应的binlog目录。默认是：/var/lib/mysql，这里是"/db/data"。
16portMySQL数据库的端口号（不指定端口号时默认是3306）
17check_repl_delay默认情况下，如果slave落后master 100M左右的relay log，MHA会放弃选择这个slave作为new master；但是，如果设置check_repl_delay=0，MHA会忽略这个限制，如果想让某个candidate_master=1特定的slave成为maseter，那么这个参数特别有用。
18candidate_master候选master，如果设置为1，那么这台机器被选举为新master的机会就越大（还要满足：binlog开启，无大延迟）
如果你设置了N台机器都为candidate_master=1，那么优先选举的顺序为从上到下。
19ignore_fail默认情况下，如果slave有问题（无法通过mysql，ssh连接，sql线程停止等等），MHA 将停止failover，如果不想让MHA manager停止，可以设置ignore_fail=1

        MHA的【master_ip_failover】文件，MHA没有vip漂移的功能，要实现VIP的自动漂移，需要一个脚本来完成，MHA manager会调用master_ip_failover_script三次，我们可以在MHA主配置文件通过添加master_ip_failover_script选项指定一个脚本来实现VIP的自动漂移功能。

        MHA在源码包中自带了一个实现VIP自动漂移的脚本master_ip_failover，但默认这个脚本无法使用，需要做一些修改（修改有注释内容提示的位置即可），修改后的master_ip_failover脚本内容如下【该脚本内容文件是：/etc/mha/scripts/master_ip_failover】，且需要给该文件授权【chmod 744 /etc/mha/scripts/master_ip_failover】：

#!/usr/bin/env perluse strict;
use warnings FATAL => 'all';use Getopt::Long;my ($command,          $ssh_user,        $orig_master_host, $orig_master_ip,$orig_master_ssh_port,$orig_master_port, $new_master_host, $new_master_ip,    $new_master_port,$new_master_ssh_port
);#这个【vip】【netdev 网卡名称】需要根据自己的实际情况修改
my $vip = '192.168.1.236/24';
my $key = '1';
my $netdev='ens33';
my $ssh_start_vip = "/sbin/ifconfig $netdev:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig $netdev:$key down";GetOptions('command=s'          => \$command,'ssh_user=s'         => \$ssh_user,'orig_master_ssh_port=i'  => \$orig_master_ssh_port,'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,'new_master_ssh_port=i'  => \$new_master_ssh_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 -p $new_master_ssh_port $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
sub stop_vip() {return 0  unless  ($ssh_user);`ssh -p $orig_master_ssh_port $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";
}

 1.2、配置MHA Manager的主配置文件

        在MHA的Manager服务器（192.168.1.10）上创建MHA的主配置文件（即：MHA Manager安装完成后，可在/etc/mha目录下手动创建一个文件，用来作为MHA的主配置文件，文件名称可以任意取名（如：创建一个app1.cnf文件）作为主配置文件）。

#在MHA的Manager服务器（192.168.1.10）上创建MHA的主配置文件，主配置文件的名称可以随便取名，如：【/etc/mha/app1.cnf】
mkdir -p /etc/mha/cd /etc/mhavi app1.cnf#MHA的主配置文件【/etc/mha/app1.cnf】详细内容如下：
[server default]
user=root
password=abc123456
ssh_port=22222
ssh_user=root
repl_user=repl_user
repl_password=repl_passwd
ping_interval=1
secondary_check_script = masterha_secondary_check -s 192.168.1.11 --port=22222
master_ip_failover_script="/etc/mha/scripts/master_ip_failover"
#master_ip_online_change_script="/etc/mha/scripts/master_ip_online_change"
#shutdown_script= /script/masterha/power_manager
report_script="/etc/mha/scripts/send_report"
manager_log=/etc/mha/app1/logs/manager.log 
manager_workdir=/etc/mha/app1[server1]
candidate_master=1
hostname=192.168.1.40
master_binlog_dir="/usr/local/mysql/mysql-8.0.43/data"
port=13336[server2]
candidate_master=1
hostname=192.168.1.41
master_binlog_dir="/usr/local/mysql/mysql-8.0.43/data"
check_repl_delay=0
port=13336[server3]
hostname=192.168.1.42
master_binlog_dir="/usr/local/mysql/mysql-8.0.43/data"
no_master=1
port=13336

编辑完成MHA的主配置文件后，还需要创建MHA主配置文件对应的目录内容：

#MHA Manager的主配置文件配置完成后，还需要创建MHA主配置文件对应的目录内容
mkdir -p /etc/mha/scripts
mkdir -p /etc/mha/app1/logs

 1.3、测试MHA Manager配置的正确性

        MHA提供了两个工具用来验证MHA环境配置的正确性，可通过【masterha_check_ssh】和【masterha_check_repl】两个命令来验证，详细操作如下：

#测试MHA Manager配置的正确性流程#1-通过masterha_check_ssh验证ssh信任登录是否配置成功（最后显示【All SSH connection tests passed successfully.】表示该测试成功）
masterha_check_ssh  --conf=/etc/mha/app1.cnf#2-masterha_check_repl验证mysql主从复制是否配置成功（最后显示【MySQL Replication Health is OK.】表示该测试成功）
masterha_check_repl --conf=/etc/mha/app1.cnf

注意：当验证mysql的主从复制是否配置成功时，会报错“

[error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/share/perl5/vendor_perl/MHA/NodeUtil.pm line 201.

[error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.”

时需要对 /usr/share/perl5/MHA/NodeUtil.pm 修改后再次运行检查命令即可解决：

#对【/usr/share/perl5/vendor_perl/MHA/NodeUtil.pm】文件进行修改：
vi /usr/share/perl5/vendor_perl/MHA/NodeUtil.pm#修改前的内容如下：
#sub parse_mysql_major_version($) {
#  my $str = shift;
#  my $result = sprintf( '%03d%03d', $str =~ m/(\d+)/g );
#  return $result;
#}#修改后的内容如下：
sub parse_mysql_major_version($) {my $str = shift;$str =~ /(\d+)\.(\d+)/;my $strmajor = "$1.$2";my $result = sprintf( '%03d%03d', $strmajor =~ m/(\d+)/g );return $result;
}

注意：当验证mysql的主从复制是否配置成功时，会报错“

There is no alive slave. We can't do failover.

Error happened on checking configurations.  at /usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm line 329.

Error happened on monitoring servers.”

        这是主从同步的问题，需要检查MySQL的Master节点是否为【可读写】、检查MySQL的Slave节点是否为【只读】后再次运行检查命令即可解决：

#查看MySQL的Master是否为可读写状态
SHOW GLOBAL VARIABLES LIKE 'read_only';#2-若Master(192.168.1.40)是只读状态则需要设置为可读写状态（若需要mysql重启后也是可读写则需修改MySQL的配置文件【/usr/local/mysql/mysql-8.0.43/etc/my.cnf】的read_only=0）
set global read_only = 0;#若Slave（192.168.1.41、192.168.1.42）是可读写状态则需要设置为只读状态（若需要mysql重启后也是只读状态则需要修改Mysql的配置文件【/usr/local/mysql/mysql-8.0.43/etc/my.cnf】的read_only=1）
set global read_only = 1;

注意：当验证mysql的主从复制是否配置成功时，会报错“

Failed to save binary log: Binlog not found from /db/data! If you got this error at MHA Manager, please set "master_binlog_dir=/path/to/binlager's configuration file and try again.”

        这是由于我们配置的MHA Manager的主配置文件【/etc/mha/app1.cnf】内容指定的MySQL的二进制文件所在的路径不正确导致的，我们只需要修改为正确的路径后再次运行检查命令即可解决：

#修改MHA Manager的主配置文件【/etc/mha/app1.cnf】中MySQL的二进制文件路径的【master_binlog_dir后面的路径为正确的路径保存重新验证即可】（如我这里正确的路径是"/usr/local/mysql/mysql-8.0.43/data"）
vi /etc/mha/app1.cnfmaster_binlog_dir="/usr/local/mysql/mysql-8.0.43/data"

到这里恭喜你，表示测试MHA Manager配置完成并通过。

二、启动与管理MHA

 2.1、启动MHA

启动MHA的参数介绍
序号启动MHA的参数说明
1--ignore_last_failover在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover（故障转移），之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件。
        默认情况下，MHA发生切换后会在MHA工作目录产生类似app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后删除该文件，我们这里为了方便，设置”--ignore_last_failover“参数。
2--remove_dead_master_conf设置了这个参数后，如果MHA failover结束后，MHA Manager会自动在配置文件中删除dead master的相关项，如果不设置，由于dead master的配置还存在文件中，那么当MHA failover后，当再次restart MHA manager后，会报错（there is a dead slave previous dead master）
3/tmp/manager_error.logs存放MHA运行过程中的一些警告或错误信息。
#启动MHA的操作流程#1-在Master节点服务器（192.168.1.40）上绑定VIP地址
#（注意：该操作只需第一次执行；当MHA接管了mysql主从复制后，就无需执行此操作了。所有VIP的漂移都有MHA来完成）
#【注意：Master节点的网卡名称需要根据自己的实际情况填写（通过【ip addr】获取网卡名称）、vip（192.168.1.236）也是需要根据自己的实际情况填写】移除指定vip命令是【/sbin/ifconfig ens33:1 down】或【ip addr del 192.168.1.236/24 dev ens33】
/sbin/ifconfig ens33:1 192.168.1.236#2-在MHA Manager服务器(192.168.1.10)上通过masterha_manager启动MHA监控（启动后需要查看MHA的状态确定是否真的启动成功了）
nohup masterha_manager --conf=/etc/mha/app1.cnf   --ignore_last_failover < /dev/null > /tmp/manager_error.log 2>&1 &#2.1在MHA Manager服务器(192.168.1.10)上查看MHA Manager的最新15条日志信息
tail -f /etc/mha/app1/logs/manager.log

 2.2、查看和停止MHA

#1-通过masterha_check_status查看MHA状态
masterha_check_status --conf=/etc/mha/app1.cnf#2-通过masterha_stop关闭MHA Manage监控
masterha_stop --conf=/etc/mha/app1.cnf

 2.3、使用vip地址访问测试MHA的MySQL集群和主从复制

        直接在同一局域网内的其他主机上使用MHA的MySQL集群VIP地址（192.168.1.236）访问操作：

关系数据库MySQL的常用基础命令详解实战https://blog.csdn.net/xiaochenXIHUA/article/details/151959864

#1-测试VIP地址（192.168.1.236）访问MHA的MySQL集群（即：在与该VIP地址同一局域网内随便找一台服务器使用vip地址登录MySQL【若可以正常登录，且在登录上的Mysql上执行查看主机名称与MHA的MySQL集群中的Master主机名称一致则表示成功，否则就是失败的】）
mysql -h 192.168.1.236 -P 13336 -uroot -p
select @@hostname;#2-测试MHA的MySQL集群的主从复制功能（即：在VIP登录的MySQL中创建一个数据库和表后，在进入到单个的Slave节点查看是否有刚才创建的数据库和表的数据内容，有则表示主从复制功能正常，否则就是失败）
show databases;
create database testdb;
show databases;use testdb;
show tables;create table testck(id int(4) not null primary key auto_increment,name char(20) not null,sex int(4) not null default '0');show tables;desc testck;insert into testck(name,sex) values("张三",26),("李四",25),("王五",27);select * from testck;

三、MHA集群测试

 3.1、自动故障切换和VIP漂移及其恢复原故障Master

        我们在这里进行手工模拟故障的MHA高可用MySQL集群测试，实现了：

《1》给MySQL集群的Master配置VIP地址(192.168.1.236)及其MHA监测。

《2》手动停止MySQL集群Master（192.168.1.40）的MySQL服务实现人为MySQL故障；且故障后MHA Manager监测实现选出新的Master（192.168.1.41），且将故障Master的VIP地址下线，同时自动漂移该VIP地址到新Master（192.168.1.41）上；最后将剩下的Slave（192.168.1.42）主从复制的原Master（192.168.1.40）调整为新Master（192.168.1.41）。

《3》我们将故障Master（192.168.1.40）恢复后，重新加入到MySQL集群中。

  3.1.1、模拟故障实现自动故障切换Failover

MHA集群的自动故障切换

要实现自动故障切换(Failover)，必须先启动MHA Manager，否则无法自动切换，当然手动切换不需要开启MHA Manager监控。

《1》手动杀掉主库mysql服务，模拟主库发生故障，进行自动故障切换(failover)操作。

《2》在MHA Manager服务器上查看MHA的切换日志【/etc/mha/app1/logs/manager.log】，了解整个切换过程。

从Failover的输出可以看出整个MHA的切换过程，共包括以下的步骤：
1

配置文件检查阶段，这个阶段会检查整个集群配置文件配置。

【需要启用 /etc/mha/app1.cnf 中的【master_ip_failover_script="/etc/mha/scripts/master_ip_failover"】】

2宕机的master处理，这个阶段包括虚拟ip摘除操作，主机关机操作。
3复制dead maste和最新slave相差的relay log，并保存到MHA Manger具体的目录下。
4识别含有最新更新的slave。
5应用从master保存的二进制日志事件（binlog events）。
6提升一个slave为新的master进行复制。
7使其他的slave连接新的master进行复制。

        停止Mysql集群的Master里面的Mysql服务后，我们在MHA Manager所在服务器上查看MHA的日志文件【/etc/mha/app1/logs/manager.log】，可以了解到如下内容：

注意：MHA Manager上显示“

ssh: connect to host 192.168.1.11 port 22: No route to host

Monitoring server 192.168.1.11 is NOT reachable!

At least one of monitoring servers is not reachable from this script. This is likely a network problem. Failover should not happen.”时是由于在MHA Manager上直接通过ssh无法直接免密登录到192.168.1.11服务器，我们需要将MHA Manager上的公钥复制一份到192.168.1.1服务器上后在查看即可。

#1-实现MHA Manager可以免密登录到192.168.1.11（即：将MHA Manager上的公钥复制一份到192.168.1.11服务器上）
ssh-copy-id -i /root/.ssh/id_ed25519.pub root@192.168.1.11#2-再次查看MHA Manager服务器上的MHA的日志输出（也可以直接在手动模拟故障前新开一个MHA Manager所在服务器的终端直接先运行【tail -f /etc/mha/app1/logs/manager.log】命令就可以实时查看日志信息了）
cat /etc/mha/app1/logs/manager.log

注意：MHA Manager所在的服务器会在故障自动切换完成后会停止MHA的监测。

  3.1.2、手动恢复原Master作为Slave并接入到新Master

#手动恢复原Master（192.168.1.40）的实操步骤#1-检查原Master（192.168.1.40）的服务状态（若已经停止则需要启动）
systemctl status mysqld.service
systemctl start mysqld.service#2-登录到原Master的MySQL中（192.168.1.40），实现将该MySQL作为Slave，且指定新的Master节点（192.168.1.41）
mysql -h 192.168.1.40 -P 13336 -uroot -pstop replica;CHANGE MASTER TO MASTER_HOST='192.168.1.41', MASTER_PORT=13336, MASTER_AUTO_POSITION=1, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passwd';start replica;show replica status\G;

  3.1.3、手动启动MHA

#手动启动MHA监测的实操步骤#1-通过masterha_check_ssh验证ssh信任登录是否配置成功（最后显示【All SSH connection tests passed successfully.】表示该测试成功，否则就是失败的需要解决后再进行下一个步骤）
masterha_check_ssh  --conf=/etc/mha/app1.cnf#2-masterha_check_repl验证mysql主从复制是否配置成功（最后显示【MySQL Replication Health is OK.】表示该测试成功，否则就是失败的需要解决后再进行下一个步骤）
masterha_check_repl --conf=/etc/mha/app1.cnf#3-在MHA Manager服务器(192.168.1.10)上通过masterha_manager启动MHA监控【启动MHA后一定要查看MHA的状态是【is running】才表示启动成功，否则就是失败的需要根据报错信息去解决后重试】
nohup masterha_manager --conf=/etc/mha/app1.cnf   --ignore_last_failover < /dev/null > /tmp/manager_error.log 2>&1 &#4-通过masterha_check_status查看MHA状态
masterha_check_status --conf=/etc/mha/app1.cnf#5-在MHA Manager服务器(192.168.1.10)上查看MHA Manager的最新15条日志信息
tail -f /etc/mha/app1/logs/manager.log

 3.2、手动故障切换Failover（MHA Manager必须没有运行）

        手动故障切换(failover)，这种场景意味着在业务上没有启用MHA自动切换功能，当主服务器故障时，人工手动调用MHA来进行故障切换操作。

#手动切换命令
masterha_master_switch --master_state=dead --conf=/etc/mha/app1.cnf \
--dead_master_host=192.168.1.40 --dead_master_port=13336  \
--new_master_host=192.168.1.41 --new_master_port=13336 --ignore_last_failover

注意：若MHA Manager检测到没有dead的server，就会报错，并结束failover，如下所示：

Mon Oct 21 21:23:33 2025 - [info] Dead Servers:
Mon Oct 21 21:23:33 2025 - [error][/usr/local/share/perl5/MHA/MasterFailover.pm, ln181] None of server is dead. Stop failover.
Mon Oct 21 21:23:33 2025 - [error][/usr/local/share/perl5/MHA/ManagerUtil.pm, ln178] Got ERROR:  at /usr/local/bin/masterha_master_switch line 53

 3.3、MHA Master在线切换

        MHA在线切换是MHA除了自动监控切换换提供的另外一种方式，多用于诸如硬件升级，MySQL数据库迁移等等。该方式提供快速切换和优雅的阻塞写入，无需关闭原有服务器，整个切换过程在0.5-2s 的时间左右，大大减少了停机时间。

#MHA Master在线切换
masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=192.168.1.41 --orig_master_is_new_slave --running_updates_limit=10000 --interactive=0
MHA Master在线切换基本步骤
序号MHA Master在线切换基本步骤
1检测MHA配置置及确认当前master
2决定新的master
3阻塞写入到当前master
4等待所有从服务器与现有master完成同步
5在新master授予写权限，以及并行切换从库
6重置原master为新master的slave

 3.4、如何将故障节点重新加入集群

如何将故障节点重新加入集群
通常情况下自动故障切换以后，原master可能已经废弃掉，待原master主机修复后，如果数据完整的情况下，可能想把原来master重新作为新主库的slave，这时可以借助当时自动切换时刻的MHA日志来完成对原master的修复。
序号如何将故障节点重新加入集群
1

若【启动MHA监测时】添加上了 【--remove_dead_master_conf】参数时，MHA failover结束后，MHA Manager会自动在配置文件中删除dead master的相关项；此时就需要【修改manager配置文件】。

#修改manager配置文件，重新添加被删除的server1内容，如下所示：
[server1]
candidate_master=1
hostname=192.168.1.40
master_binlog_dir="/usr/local/mysql/mysql-8.0.43/data"
port=13336
2

修复老的Master，然后将其设置为slave（即：我们可以从从自动切换时刻的MHA日志【/etc/mha/app1/logs/manager.log】上可以发现类似如下信息：）

#这个日志信息的含义是说，若Master主机修复好了，
#可以在修复好后的Master上执行CHANGE MASTER操作，作为新的slave库。
All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='192.168.1.41', MASTER_PORT=13336, MASTER_LOG_FILE='mysql-bin.000009',MASTER_LOG_POS=237, MASTER_USER='repl_user', MASTER_PASSWORD='xxx';#接着，在老的master执行如下命令：
mysql>CHANGE MASTER TO MASTER_HOST='192.168.1.41',MASTER_PORT=13336,MASTER_LOG_FILE='mysql-bin.000009',MASTER_LOG_POS=237,MASTER_USER='repl_user' MASTER_PASSWORD=repl_passwd;mysql>start replica；mysql>show replica status\G;#这样，数据就开始同步到老的master上了
#此时老的master已经重新加入集群，变成mha集群中的一个slave角色了。

3

在MHA Manger节点上重新启动监控进程

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

 3.5、使用MHA需要注意的问题

使用MHA需要注意的问题
序号使用MHA需要注意的问题
1

故障切换之后会产生一个app1.failover.complete文件，如果要进行第二次Failover测试，需要手工删除app1.failover.complete。

另一种方法是通过--ignore_last_failover参数来忽略.

masterha_master_switch --master_state=dead --conf=/etc/mha/app1.cnf  --dead_master_host=192.168.1.40 --dead_master_port=13336 --new_master_host=192.168.1.41 --new_master_port=13336 --ignore_last_failover
2一旦发生一次故障切换后，MHA Manager监控进程将会退出，无法继续进行监控，要再次开启监控，需将原故障数据库重新加入到MHA环境中来，然后设置为slave。最后再次在mha manager上开启对master的监控进程。
3

原主节点重新加入到MHA时只能设置为slave,并且需要执行

change master to MASTER_HOST='192.168.1.41', MASTER_USER='replicationuser',MASTER_PASSWORD='replicationuser',MASTER_LOG_FILE='mysql-bin.000004',MASTER_LOG_POS=106;

change信息可从MHA的切换日志【/etc/mha/app1/logs/manager.log】中获取到。

4

关于ip地址的接管有几种方式，这里采用的是MHA自动调用IP别名的方式，好处是在能够保证数据库状态与业务Ip 切换的一致性。启动管理节点之后 vip会自动别名到当前主节点上。

【VIP地址漂移也可以使用Keepalived配置】

http://www.dtcms.com/a/450204.html

相关文章：

  • 图说刚体运动概念凸显须重新认识测度论和“点无大小，线无宽度”公理
  • 人防网站建设查国外企业信息的网站
  • 做旅游网站的目的是什么wordpress批量修改文章内的代码
  • 禅城网站建设免费网站制作 优帮云
  • cms网站建设有多少条数据wordpress 框架解析
  • 网站的推广优化赣州网站建设哪家好
  • 智能建站系统怎么更换网站模板wordpress国产主题推荐
  • MySQL介绍和MySQL包安装 -- RHEL系列（Yum资源库安装MySQL）
  • 广东宣布即时优化调整seo诊断分析
  • 做网站的经验和体会论坛网站搭建
  • MySQL笔记---索引
  • 免费做自荐书的网站网站设计怎么算间距
  • 在线制作表白网站的源码雄安新区网站建设
  • 让“通感”更聪明：人工智能在通信感知一体化中的非线性建模优势
  • 2024年ASOC SCI2区TOP，费马-韦伯定位粒子群算法+无人机协同路径规划，深度解析+性能实测
  • 政务网站平台建设 招标河北省建设网站的网站首页
  • 怎样建设美食网站wordpress外网排版问题
  • 自助建站网站程序源码手机网站建设注册塔山双喜
  • 内卷式迷茫-当游戏沉迷与疯狂刷题成为“空心病”的双重面具-AI
  • dedecms 网站名称网站开发与建设方向
  • Oracle OCP认证考试题目详解082系列第56题
  • 织梦网站首页文字修改响应式网页制作
  • uv `pyvenv.cfg` is missing micromaba环境报错解决
  • 还原论与系统论在计算机科学中的应用
  • 做明星ps黄图网站陕西建设网网站集群
  • 制作公司网站用阿里云响应式网站 软件
  • 视频号下载器 (1)
  • 电源——BOOST电路设计实战
  • 专业app开发定制公司网络优化的内容包括哪些
  • 海南省两学一做网站flash同视频做网站