【MHA高可用】
【MHA高可用】
目录
1.MHA介绍
2.MHA的优缺点
2.1：优点
2.2：缺点
3.实验环境
4.基于GTID技术搭建主从复制
4.1.安装密码插件
4.2.修改配置文件
4.3.mysql主从配置指定端口
4.3.1.在主服务器上建立帐户并授权
4.3.2.配置从服务器Slave
4.3.3.启动从服务器复制
4.3.4.检查主.从服务器复制功能状态
4.配置SSH免密登录
4.1.配置所有主机相互ssh登录免密验证
4.2.测试免密
5.安装MHA-Manager和Node软件
5.1.在撰写栏配置yum源
5.2.安装MHA依赖环境
5.3.上传manager和node安装包
5.4.安装node节点
5.5.安装manager节点
5.6.检查安装完成后的依赖包
6.配置MHA-Manager和Node软件
6.1.创建MHA管理账户并授权
6.2.创建MHA目录文件夹
6.3.添加配置文件
7.测试MHA配置
7.1.检查MHA的SSH配置状况
7.2.测试检查MySQL复制状况
7.3.检查MHA运行状态
8.启动MHA-Manager
8.1.启动参数注释
8.2.在前台启动管理节点
8.3.生产上启动管理节点命令
8.4.二个常见问题
9.自动切换
9.1.杀掉主库mysql进程
9.2.在管理节点上查看主库状态
9.3.查看新的主从关系
9.4.恢复故障的主库master
9.4.1.启动管理节点失败
9.4.2.启动挂掉的数据库
9.4.3.重新指定主从关系
9.4.4.重新启动管理节点
10. 添加虚拟IP
10.1添加虚拟IP
10.2修改配置文件
10.3添加虚拟IP脚本
10.4重新启动manager
10.5测试虚拟IP是否漂移
10.5.1停掉主库mysql服务
10.5.2重新搭建主从关系
10.5.3重新启动管理节点
11. MHA故障切换发送邮件告警
11.1关闭MHA监控
11.2修改配置文件
11.3添加发送邮件脚本
11.4.重新启动管理节点
12. 手动切换
12.1检查是否切换过
12.2.关闭MHA监控
12.3.在线切换
12.4.检查是否切换成功
13. MHA在线切换的原理
13.1. 配置检查
13.2. 阻止对当前master的更新
13.3. 清理新master的相关信息
1.MHA介绍
MHA: Master High Availability
github地址: https://github.com/yoshinorim
在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。
MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。（一般不建议放在主节点上，因为一旦主节点上的服务器故障，直接导致管理节点故障）
MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没办法保存二进制日志，只进行故障转移而丢失了最新的数据。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。
2.MHA的优缺点
2.1：优点
1）自动故障转移快（10-30秒）
2）主库崩溃不存在数据一致性问题
3）不需要对当前mysql环境做重大修改
4）不需要添加额外的服务器(仅一台manager就可管理上百个replication)
5）性能优秀，可工作在半同步复制和异步复制，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。
6）只要replication支持的存储引擎，MHA都支持，不会局限于innodb
2.2：缺点
1、需要编写脚本或利用第三方工具来实现VIP的配置
2、MHA启动后只会对主数据库进行监控
3、需要基于SSH免认证配置，存在一定的安全隐患
4、没有提供从服务器的读负载均衡功能
5、虽然MHA试图从宕机的主服务器上保存二进制日志，但也会有问题。例如，如果主服务器硬件故障或无法通过ssh访问，
MHA没法保存二进制日志，只进行故障转移而丢失最新数据。
6、当主DB故障，切换到另外的服务器上后，即使恢复了原来的主DB，也不能立即加入整套MHA系统中，得重新部署。
而且当发生一次切换后，管理节点的监控进程就会自动退出，需要用脚本来自动启动。另外还得删除app1.failover.complete这个文件，否则新的主DB出现问题MHA就不会切换了。
3.实验环境
|
IP |
主机 |
系统 |
MySQL |
角色 |
软件 |
|
192.168.230.101 |
db01 |
CentOS7.6 |
5.7.28 |
Manager |
manager+node |
|
192.168.230.102 |
db02 |
CentOS7.6 |
5.7.28 |
Master |
node |
|
192.168.230.103 |
db03 |
CentOS7.6 |
5.7.28 |
Slave1 |
node |
|
192.168.230.104 |
db04 |
CentOS7.6 |
5.7.28 |
Slave2 |
node |
4.基于GTID技术搭建主从复制
GTID (Global Transaction ID)，也就是全局事务ID, 其保证为每一个在master主上提交的事务在复制集群中可以生成一个唯一的ID
基于GTID的复制是从MySQL5.6开始支持的一种新的复制方式，此方式与传统基于binlog日志的方式存在很大的差异，在原来的基于日志的复制中，slave从服务器连接到master主服务器并告诉主服务器要从哪个二进制日志的偏移量开始执行增量同步，这时我们如果指定的日志偏移量不对，这与可能造成主从数据的不一致，而基于GTID的复制会避免。
在基于GTID的复制中，首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值，然后主库会有把所有没有在从库上执行的事务，发送到从库上进行执行，并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次，这样可以避免由于偏移量的问题造成数据不一致。
GTID=source_id:transaction_id
source_id就是执行事务的主库的server-uuid值
server-uuid值是在mysql服务首次启动生成的，保存在数据库的数据目录中，在数据目录中有一个auto.conf文件
show variables like '%uuid%';
事务ID则是从1开始自增的序列，表示这个事务是在主库上执行的第几个事务
Binlog日志还是需要开启的。
主库修改配置文件my.cnf:
环境:
|
主机 |
角色 |
IP |
系统版本 |
|
db02 |
master |
192.168.230.102 |
CentOS 7.6 |
|
db03 |
slave1 |
192.168.230.103 |
CentOS 7.6 |
|
db04 |
slave2 |
192.168.230.104 |
CentOS 7.6 |
4.1.安装密码插件
在102，103，104数据库上：
|
mysql> INSTALL PLUGIN validate_password SONAME 'validate_password.so'; Query OK, 0 rows affected (0.01 sec) |
4.2.修改配置文件
192.168.230.102(master):
|
[mysqld] validate_password = OFF character_set_server = utf8mb4 server_id = 102 log_bin = mysql-bin gtid_mode = ON enforce_gtid_consistency = ON log_slave_updates = ON binlog-ignore-db = mysql binlog-ignore-db = information_schema binlog-ignore-db = performance_schema binlog-ignore-db = sys
show variables like '%log_bin%'; show variables like '%gtid%';
注意: 主库需要开启binlog，从库不是必须的，在这我们开启，因为slave可能会提升为master。 |
192.168.230.103(slave1)
|
[mysqld] validate_password=OFF character_set_server = utf8mb4 server_id = 103 log_bin = mysql-bin gtid_mode = ON enforce_gtid_consistency = ON log_slave_updates = ON read_only = ON binlog-ignore-db = mysql binlog-ignore-db = information_schema binlog-ignore-db = performance_schema binlog-ignore-db = sys
show variables like '%read_only %'; show variables like '%log_bin%'; show variables like '%gtid%'; |
192.168.230.104(slave2)
|
[mysqld] validate_password=OFF character_set_server = utf8mb4 server_id = 104 log_bin = mysql-bin gtid_mode = ON enforce_gtid_consistency = ON log_slave_updates = ON read_only = ON binlog-ignore-db = mysql binlog-ignore-db = information_schema binlog-ignore-db = performance_schema binlog-ignore-db = sys
show variables like '%log_bin%'; show variables like '%gtid%'; show variables like '%read_only %'; |
4.3.mysql主从配置指定端口
4.3.1.在主服务器上建立帐户并授权
在102，103，104上(因为从库可能会切换成主库)
grant replication slave,replication client on *.* TO 'repl'@'%' identified by '123456';
show master status;
4.3.2.配置从服务器Slave
CHANGE MASTER TO MASTER_HOST='192.168.3.236',master_port=33071,MASTER_USER='repl',MASTER_PASSWORD='123456',MASTER_AUTO_POSITION=1;
端口：
主从的端口不一致，不影响主从复制，但是若主库的端口不是3306，则在change master to的时候，需要指定主库端口
MASTER_AUTO_POSITION=1;
若从库数据是从主库备份恢复来的，则MASTER_AUTO_POSITION=0，且需要指定binlog的日志文件和位置。
4.3.3.启动从服务器复制
start slave;
show slave status\G;
4.3.4.检查主.从服务器复制功能状态
show master status\G;
show slave status\G
show processlist;
4.配置SSH免密登录
4.1.配置所有主机相互ssh登录免密验证
4.2.1：在101，102，103，104上
ssh-keygen -t rsa（生成密钥）
ssh 192.168.230.102 date（需要输入密码，还未免密登录）
ssh-
4.2.2：在101，102，103，104上
ssh-copy-id 192.168.230.101
ssh-copy-id 192.168.230.102
ssh-copy-id 192.168.230.103
ssh-copy-id 192.168.230.104
4.2.测试免密
ssh 192.168.230.101 date
ssh 192.168.230.102 date
ssh 192.168.230.103 date
ssh 192.168.230.104 date
5.安装MHA-Manager和Node软件
5.1.在撰写栏配置yum源
1在101，102，103，104上
在撰写栏测试是否能上网？
ping www.qq.com
2在101，102，103，104上
cd /opt
上传文件
3在101，102，103，104上
rpm -ivh epel-release-7-12.noarch.rpm（因为MHA是用perl语言写的，所以需要配置其所需的环境）
4会发现在yum源仓库多了一个软件：
cd /etc/yum.repos.d/
5清除下载的yum软件包
yum clean all
6把服务器的包信息下载到本地电脑缓存起来，提高检索速度
yum makecache
5.2.安装MHA依赖环境
原因：由于MHA是perl语言开发的所以需要安装依赖环境（所有节点安装）
安装:
mysql-community-libs-compat-5.7.28-1.el7.x86_64.rpm
1安装前准备：
在官网下载
2检查是否有依赖包
rpm -qa|grep mariadb
rpm -e --nodeps mariadb-libs-5.5.56-2.el7.x86_64
rpm -qa|grep mariadb
3解压安装包
tar -xvf mysql-5.7.25-1.el7.x86_64.rpm-bundle.tar
4安装所需的依赖包：
rpm -ivh mysql-community-common-5.7.25-1.el7.x86_64.rpm
rpm -ivh mysql-community-libs-5.7.25-1.el7.x86_64.rpm
5在101，102，103，104上：
查询是否有此包：
rpm -qa |grep mysql
若没有：
rpm -ivh mysql-community-libs-compat-5.7.25-1.el7.x86_64.rpm
5.3.上传manager和node安装包
1.在101上
上传安装包到/opt:
mha4mysql-manager-0.58-0.el7.centos.noarch
mha4mysql-node-0.58-0.el7.centos.noarch
2.node节点安装包复制到102，103，104上
scp mha4mysql-node-0.58-0.el7.centos.noarch 192.168..3.102:opt/soft
cd /opt
ls
5.4.安装node节点
1.在101，102，103，104上
yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager
2.在101，102，103，104上安装node节点
rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm
5.5.安装manager节点
在101上
rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm
注意：必须先安装node节点，再安装manger节点
5.6.检查安装完成后的依赖包
rpm -ql mha4mysql-manager
|
/usr/bin/masterha_check_repl 检查MySQL复制状况 /usr/bin/masterha_check_ssh 检查MHA的SSH配置状况 /usr/bin/masterha_check_status 检测当前MHA运行状态 /usr/bin/masterha_conf_host 添加或删除配置信息 /usr/bin/masterha_manager 启动MHA /usr/bin/masterha_master_monitor 检测master是否宕机 /usr/bin/masterha_master_switch 控制故障转移（自动或者手动） /usr/bin/masterha_secondary_check /usr/bin/masterha_stop 停止MHA |
rpm -ql mha4mysql-node（manager上发现故障，会调用这些脚本）
|
/usr/bin/apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的slave /usr/bin/filter_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用这个工具） /usr/bin/purge_relay_logs 清除中继日志（不会阻塞SQL线程） /usr/bin/save_binary_logs 保存和复制master的二进制日志 |
6.配置MHA-Manager和Node软件
6.1.创建MHA管理账户并授权
在102，103，104上：
grant all privileges on *.* to 'mha'@'%' identified by '123456';
flush privileges;
6.2.创建MHA目录文件夹
在101上：
配置mha-manager管理节点
mkdir -p /etc/masterha/app1 #管理的工作目录
touch /etc/masterha/app1/manager.log #日志文件
mkdir -p /etc/conf/masterha
touch /etc/conf/masterha/app1.cnf
6.3.添加配置文件
vim /etc/conf/masterha/app1.cnf
7.测试MHA配置
7.1.检查MHA的SSH配置状况
masterha_check_ssh --conf=/etc/conf/masterha/app1.cnf
注意配置文件不能有空格，否则可能会报错
7.2.测试检查MySQL复制状况
masterha_check_repl --conf=/etc/conf/masterha/app1.cnf
7.3.检查MHA运行状态
masterha_check_status --conf=/etc/conf/masterha/app1.cnf
8.启动MHA-Manager
8.1.启动参数注释
在101上启动管理节点
--nohup 代表在后台启动
/etc/masterha/app1/manager.log 日志目录
2>&1 标准输出和标准错误都放到日志里面
/etc/conf/masterha/app1.cnf 配置文件
& 代表在后台启动
8.2.在前台启动管理节点
masterha_manager --conf=/etc/conf/masterha/app1.cnf
另启窗口：
cat /etc/masterha/app1/manager.log
ps -ef |grep mha
ps -ef |grep master
检查运行状态：
masterha_check_status --conf=/etc/conf/masterha/app1.cnf
8.3.生产上启动管理节点命令
nohup masterha_manager --conf=/etc/conf/masterha/app1.cnf > /etc/masterha/app1/manager.log 2>&1 &
若前台启动命令失败，可用后台启动命令
8.4.二个常见问题
在101，102，103，104上 systemctl disable libvirtd.service iptables -L 列出所有规则 iptables -F 清除所有
在101，102，103，104上 修改配置文件： vi /etc/ssh/sshd_config
useDNS no 重启服务： service sshd restart
全部重启服务后，发现登录比之前快
iptables -L
|
参数:
|
(1) ping_interval=3 #设置监控主库，发送ping包的时间间隔，尝试三次没有回应的时候自动进行failover (2) candidate_master=1 使用场景:两地三中心,指定库切换为主 #设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave (3)check_repl_delay=0（就算落后100M,也会选取指定从库提升为主库） #默认情况下如果一个slave落后master 100M的relay logs的话， MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master (4)no_master=1 意味着这个server从来不会成为新的master
关于主库只读: read_only super_read_only（如果为on,root账户也没有写的权限） |
9.自动切换
9.1.杀掉主库mysql进程
在102上：
ps -ef |grep mysqld
杀掉mysql进程：
pkill mysql
查看进程：
ps -ef |grep mysqld
9.2.在管理节点上查看主库状态
在101上:
ps -ef |grep master(发现master还在运行)
查看日志：
ps -ef |grep master
查看日志：
cat /etc/masterha/app1/manager.log
9.3.查看新的主从关系
1：在103上
show variables like '%read_only%';
发现read_only已经关闭
show master status\G;
2：在104上上继续上述7.3操作
然后测试103，与104之间的同步能否进行?
9.4.恢复故障的主库master
9.4.1.启动管理节点失败
在101上：
masterha_manager --conf=/etc/conf/masterha/app1.cnf
ps -ef |grep master
查看日志
cat /etc/masterha/app1/manager.log
ll
cat app1.failover.complete
9.4.2.启动挂掉的数据库
在102上：
systemctl start mysqld
启动失败
cd /etc
将此文件的内容复制到my.cnf文件中，启动成功
9.4.3.重新指定主从关系
CHANGE MASTER TO MASTER_HOST='192.168.230.103',MASTER_USER='repl',MASTER_PASSWORD='123456',MASTER_AUTO_POSITION=1;
start slave;
show slave status\G;
测试一下主从关系是否成功
然后测试103作为主库，102，104作为从库，是否同步成功？
9.4.4.重新启动管理节点
在101上：
重新启动监控：
nohup masterha_manager --conf=/etc/conf/masterha/app1.cnf > /etc/masterha/app1/manager.log 2>&1 &
查看日志
cat /etc/masterha/app1/manager.log
在101上：
查看主从关系：
masterha_check_repl --conf=/etc/conf/masterha/app1.cnf
10. 添加虚拟IP
10.1添加虚拟IP
在103上：
ifconfig
ifconfig ens33:1 192.168.230.105/24
Ifconfig
此时可以用 192.168.230.105这个IP连接工具
若连接失败，可以修改密码，再连接
去除vip：(不用操作，因为此处需要手动添加vip)
ifconfig ens33:1 down
ifconfig
10.2修改配置文件
vi /etc/conf/masterha/app1.cnf
添加VIP:
master_ip_failover_script=/usr/local/bin/master_ip_failover
10.3添加虚拟IP脚本
vi /usr/local/bin/master_ip_failover
添加执行权限
chmod +x /usr/local/bin/master_ip_failover
10.4重新启动manager
测试一下主从关系是否成功，添加完虚拟ip配置文件，主从关系可能失效，启动manager后，再次测试
nohup masterha_manager --conf=/etc/conf/masterha/app1.cnf > /etc/masterha/app1/manager.log 2>&1 &
查看日志：
cat /etc/masterha/app1/manager.log
10.5测试虚拟IP是否漂移
10.5.1停掉主库mysql服务
在103上：
ps -ef |grep mysql
pkill mysql
在101上：
查看日志
tail -f /etc/masterha/app1/manager.log
在102，103上：
Ifconfig
发现vip已经漂移到102上
在客户端上：
对客户端几户没有影响，会有0-30秒的时间不能用
用vip测试主从；
102与104之间的主从关系；
10.5.2重新搭建主从关系
在103上：
systemctl start mysqld
stop slave;
CHANGE MASTER TO MASTER_HOST='192.168.230.102',MASTER_USER='repl',MASTER_PASSWORD='123456',MASTER_AUTO_POSITION=1;
start slave;
show slave status\G;
10.5.3重新启动管理节点
在101上：
ps -ef |grep master
cd /etc/masterha/app1
ll
删除此文件
rm -rf app1.failover.complete
重新启动管理节点：
nohup masterha_manager --conf=/etc/conf/masterha/app1.cnf > /etc/masterha/app1/manager.log 2>&1 &
查看日志：
cat /etc/masterha/app1/manager.log
11. MHA故障切换发送邮件告警
11.1关闭MHA监控
在101上：
masterha_stop --conf=/etc/conf/masterha/app1.cnf
查看进程：
ps -ef|grep master
11.2修改配置文件
在101上：
vi /etc/conf/masterha/app1.cnf
发送邮件:
report_script=/usr/local/bin/send_mail
11.3添加发送邮件脚本
修改配置
vi /usr/local/bin/send_mail
chmod +x /usr/local/bin/send_mail
设置-账户
11.4.重新启动管理节点
nohup masterha_manager --conf=/etc/conf/masterha/app1.cnf > /etc/masterha/app1/manager.log 2>&1 &
查看主从关系：
masterha_check_repl --conf=/etc/conf/masterha/app1.cnf
在102上：
pkill mysql
12. 手动切换
12.1检查是否切换过
在101上：
ps -ef |grep master
ls
rm app1.failover.complete
12.2.关闭MHA监控
masterha_stop --conf=/etc/conf/masterha/app1.cnf
12.3.在线切换
masterha_master_switch --conf=/etc/conf/masterha/app1.cnf --master_state=alive --new_master_host=192.168.230.103 --new_master_port=3306 --orig_master_is_new_slave
12.4.检查是否切换成功
在101，102，103：
show slave status\G;
Ifconfig(发现VIP并未漂移过来)
其中，
--orig_master_is_new_slave是将原master切换为新主的slave，默认情况下，是不添加的。
--running_updates_limit默认为1s，即如果主从延迟时间（Seconds_Behind_Master），或master show processlist中dml操作大于1s，则不会执行切换。
|
[root@db01 ~]# masterha_master_switch --conf=/etc/conf/masterha/app1.cnf --master_state=alive --new _master_host=192.168.230.103 --new_master_port=3306 --orig_master_is_new_slaveSun Dec 15 18:46:04 2019 - [info] MHA::MasterRotate version 0.58. Sun Dec 15 18:46:04 2019 - [info] Starting online master switch.. Sun Dec 15 18:46:04 2019 - [info] Sun Dec 15 18:46:04 2019 - [info] * Phase 1: Configuration Check Phase.. Sun Dec 15 18:46:04 2019 - [info] Sun Dec 15 18:46:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.Sun Dec 15 18:46:04 2019 - [info] Reading application default configuration from /etc/conf/masterha /app1.cnf..Sun Dec 15 18:46:04 2019 - [info] Reading server configuration from /etc/conf/masterha/app1.cnf.. Sun Dec 15 18:46:05 2019 - [info] GTID failover mode = 1 Sun Dec 15 18:46:05 2019 - [info] Current Alive Master: 192.168.230.102(192.168.230.102:3306) Sun Dec 15 18:46:05 2019 - [info] Alive Slaves: Sun Dec 15 18:46:05 2019 - [info] 192.168.230.103(192.168.230.103:3306) Version=5.7.28-log (olde st major version between slaves) log-bin:enabledSun Dec 15 18:46:05 2019 - [info] GTID ON Sun Dec 15 18:46:05 2019 - [info] Replicating from 192.168.230.102(192.168.230.102:3306) Sun Dec 15 18:46:05 2019 - [info] 192.168.230.104(192.168.230.104:3306) Version=5.7.28-log (olde st major version between slaves) log-bin:enabledSun Dec 15 18:46:05 2019 - [info] GTID ON Sun Dec 15 18:46:05 2019 - [info] Replicating from 192.168.230.102(192.168.230.102:3306)
It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 192.168.230.102(192.168.230.102:3306)? (YES/no): yesSun Dec 15 18:46:45 2019 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long tim e..Sun Dec 15 18:46:45 2019 - [info] ok. Sun Dec 15 18:46:45 2019 - [info] Checking MHA is not monitoring or doing failover.. Sun Dec 15 18:46:45 2019 - [info] Checking replication health on 192.168.230.103.. Sun Dec 15 18:46:45 2019 - [info] ok. Sun Dec 15 18:46:45 2019 - [info] Checking replication health on 192.168.230.104.. Sun Dec 15 18:46:45 2019 - [info] ok. Sun Dec 15 18:46:45 2019 - [info] 192.168.230.103 can be new master. Sun Dec 15 18:46:45 2019 - [info] From: 192.168.230.102(192.168.230.102:3306) (current master) +--192.168.230.103(192.168.230.103:3306) +--192.168.230.104(192.168.230.104:3306)
To: 192.168.230.103(192.168.230.103:3306) (new master) +--192.168.230.104(192.168.230.104:3306) +--192.168.230.102(192.168.230.102:3306)
Starting master switch from 192.168.230.102(192.168.230.102:3306) to 192.168.230.103(192.168.230.10 3:3306)? (yes/NO): yesSun Dec 15 18:47:18 2019 - [info] Checking whether 192.168.230.103(192.168.230.103:3306) is ok for the new master..Sun Dec 15 18:47:18 2019 - [info] ok. Sun Dec 15 18:47:18 2019 - [info] 192.168.230.102(192.168.230.102:3306): SHOW SLAVE STATUS returned empty result. To check replication filtering rules, temporarily executing CHANGE MASTER to a dummy host.Sun Dec 15 18:47:18 2019 - [info] 192.168.230.102(192.168.230.102:3306): Resetting slave pointing t o the dummy host.Sun Dec 15 18:47:18 2019 - [info] ** Phase 1: Configuration Check Phase completed. Sun Dec 15 18:47:18 2019 - [info] Sun Dec 15 18:47:19 2019 - [info] * Phase 2: Rejecting updates Phase.. Sun Dec 15 18:47:19 2019 - [info] master_ip_online_change_script is not defined. If you do not disable writes on the current master m anually, applications keep writing on the current master. Is it ok to proceed? (yes/NO): yesSun Dec 15 18:48:45 2019 - [info] Locking all tables on the orig master to reject updates from ever ybody (including root):Sun Dec 15 18:48:45 2019 - [info] Executing FLUSH TABLES WITH READ LOCK.. Sun Dec 15 18:48:45 2019 - [info] ok. Sun Dec 15 18:48:45 2019 - [info] Orig master binlog:pos is mysql-bin.000010:983. Sun Dec 15 18:48:45 2019 - [info] Waiting to execute all relay logs on 192.168.230.103(192.168.230 .103:3306)..Sun Dec 15 18:48:45 2019 - [info] master_pos_wait(mysql-bin.000010:983) completed on 192.168.230.1 03(192.168.230.103:3306). Executed 0 events.Sun Dec 15 18:48:45 2019 - [info] done. Sun Dec 15 18:48:45 2019 - [info] Getting new master's binlog name and position.. Sun Dec 15 18:48:45 2019 - [info] mysql-bin.000011:194 Sun Dec 15 18:48:45 2019 - [info] All other slaves should start replication from here. Statement s hould be: CHANGE MASTER TO MASTER_HOST='192.168.230.103', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='xxx';Sun Dec 15 18:48:45 2019 - [info] Setting read_only=0 on 192.168.230.103(192.168.230.103:3306).. Sun Dec 15 18:48:45 2019 - [info] ok. Sun Dec 15 18:48:45 2019 - [info] Sun Dec 15 18:48:45 2019 - [info] * Switching slaves in parallel.. Sun Dec 15 18:48:45 2019 - [info] Sun Dec 15 18:48:45 2019 - [info] -- Slave switch on host 192.168.230.104(192.168.230.104:3306) sta rted, pid: 11045Sun Dec 15 18:48:45 2019 - [info] Sun Dec 15 18:48:47 2019 - [info] Log messages from 192.168.230.104 ... Sun Dec 15 18:48:47 2019 - [info] Sun Dec 15 18:48:45 2019 - [info] Waiting to execute all relay logs on 192.168.230.104(192.168.230 .104:3306)..Sun Dec 15 18:48:45 2019 - [info] master_pos_wait(mysql-bin.000010:983) completed on 192.168.230.1 04(192.168.230.104:3306). Executed 0 events.Sun Dec 15 18:48:45 2019 - [info] done. Sun Dec 15 18:48:45 2019 - [info] Resetting slave 192.168.230.104(192.168.230.104:3306) and starti ng replication from the new master 192.168.230.103(192.168.230.103:3306)..Sun Dec 15 18:48:45 2019 - [info] Executed CHANGE MASTER. Sun Dec 15 18:48:46 2019 - [info] Slave started. Sun Dec 15 18:48:47 2019 - [info] End of log messages from 192.168.230.104 ... Sun Dec 15 18:48:47 2019 - [info] Sun Dec 15 18:48:47 2019 - [info] -- Slave switch on host 192.168.230.104(192.168.230.104:3306) suc ceeded.Sun Dec 15 18:48:47 2019 - [info] Unlocking all tables on the orig master: Sun Dec 15 18:48:47 2019 - [info] Executing UNLOCK TABLES.. Sun Dec 15 18:48:47 2019 - [info] ok. Sun Dec 15 18:48:47 2019 - [info] Starting orig master as a new slave.. Sun Dec 15 18:48:47 2019 - [info] Resetting slave 192.168.230.102(192.168.230.102:3306) and starti ng replication from the new master 192.168.230.103(192.168.230.103:3306)..Sun Dec 15 18:48:47 2019 - [info] Executed CHANGE MASTER. Sun Dec 15 18:48:57 2019 - [info] Slave started. Sun Dec 15 18:48:57 2019 - [info] All new slave servers switched successfully. Sun Dec 15 18:48:57 2019 - [info] Sun Dec 15 18:48:57 2019 - [info] * Phase 5: New master cleanup phase.. Sun Dec 15 18:48:57 2019 - [info] Sun Dec 15 18:48:57 2019 - [info] 192.168.230.103: Resetting slave info succeeded. Sun Dec 15 18:48:57 2019 - [info] Switching master to 192.168.230.103(192.168.230.103:3306) complet ed successfully.[root@db01 ~]# |
13. MHA在线切换的原理
13.1. 配置检查
包括读取MHA的配置文件app1.cnf及检查当前slave的健康状态
执行FLUSH NO_WRITE_TO_BINLOG TABLES
13.2. 阻止对当前master的更新
执行FLUSH TABLES WITH READ LOCK
设置原master的read_only=1
等待新master执行完所有的relay log
设置新master的read_only=0
将其他slave指向新的master
所有切换完毕，然后在原master执行unlock tables
将原master切为slave(--orig_master_is_new_slave参数
13.3. 清理新master的相关信息
主要是执行了reset slave all操作，清除之前的复制信息。
在线切换时，可以打开general log，观察各个服务器的操作信息。
浙公网安备 33010602011771号