【MySQL】【高可用】从masterha_master_switch工具简单分析MHA的切换逻辑

简介：masterha_master_switch作为一个切换工具被集成在MHA程序包中，

安装：编译安装MHA manager后会在/usr/local/bin/中生成二进制可执行程序masterha_master_switch。

使用：

$masterha_master_switch --help
Usage:
    # For master failover

    masterha_master_switch --master_state=dead
    --global_conf=/etc/masterha_default.cnf
    --conf=/usr/local/masterha/conf/app1.cnf --dead_master_host=host1

    # For online master switch

    masterha_master_switch --master_state=alive
    --global_conf=/etc/masterha_default.cnf
    --conf=/usr/local/masterha/conf/app1.cnf

    See online reference
    (http://code.google.com/p/mysql-master-ha/wiki/masterha_master_switch)
    for details.

在这里，我习惯将一套主从的配置都放在app1.cnf中，并且更改为业务相关的名称，如mainBusiness.cnf

分析：

目标：获取masterha_master_switch的在线切换逻辑

环境：MHA manager 192.168.1.8

       MHA node1+MySQL5.7+GTID 192.168.1.109+PORT3109     主

       MHA node1+MySQL5.7+GTID 192.168.1.110+PORT3110     从

配置文件内容：

manager_workdir=/data/mha/mainBusiness                 #设置MHA的工作目录
manager_log=/data/mha/mainBusiness/manager.log         #MHA manager的日志输出
remote_workdir=/data/mha/                              #预设MHA node端的工作目录

master_binlog_dir= /data/mysql/3109/log/,/data/mysql/3110/log/  #预设MHA node端的binlog目录
#secondary_check_script= masterha_secondary_check -s 192.168.1.109 -s 192.168.1.110
secondary_check_script= masterha_secondary_check -s 192.168.1.109 -s 192.168.1.110 --user=root --master_host=192.168.1.109 --master_port=3109          

ping_interval=1                                       #设置MHA manager的检测间隔（1秒）

[server1]
hostname=MySQL-Cent7-IP001109
ip=192.168.1.109
port=3109
ssh_user=root
ssh_port=22
candidate_master=1                                    #设置该节点是否可以提升为主，1为是,0否
check_repl_delay=0                                    #发生故障后是否检查本实例主从落后程度,0否,1是

[server2]
hostname=MySQL-Cent7-IP001110
ip=192.168.1.110
port=3110
ssh_user=root
ssh_port=22
candidate_master=1                                    #设置该节点是否可以提升为主，1为是,0否
check_repl_delay=0                                    #发生故障后是否检查本实例主从落后程度,0否,1是
    在MHA manager端上执行：

$masterha_master_switch --master_state=alive --conf=/etc/mha/mainBusiness.cnf  --orig_master_is_new_slave
#--master_state             指明在线切换
#--orig_master_is_new_slave 指定原先的主作为从库挂到新的主上

MHA manager端输出如下

#####################输出段1###########################
[info] MHA::MasterRotate version 0.57.
[info] Starting online master switch..        #开始在线切换
[info]
[info] * Phase 1: Configuration Check Phase.. #阶段1,检查配置
[info]
[warning] Global configuration file /etc/masterha_default.cnf not found. Skipping..             #我这里没有使用全局参数文件，会有报错跳过，没关系
[info] Reading application default configuration from /etc/mha/mainBusiness.cnf..               #程序从mainBusiness文件中读取配置
[info] Reading server configuration from /etc/mha/mainBusiness.cnf..
[info] GTID failover mode = 1                #启用GTID故障转移模式
[info] Current Alive Master: MySQL-Cent7-IP001109(192.168.1.109:3109)  #列出当前存活的主实例
[info] Alive Slaves:                         #列出当前存活的从实例
[info]   MySQL-Cent7-IP001110(192.168.1.110:3110)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
[info]   GTID ON                             #从采用了GTID模式
[info]   Replicating from 192.168.1.109(192.168.1.109:3109)
[info]   Primary candidate for the new Master (candidate_master is set)

It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on MySQL-Cent7-IP001109(192.168.1.109:3109)? (YES/no):
#处于事务一致性考虑，程序询问是否临时关闭非事务型的表

原master，3109端显示如下

#####################输出段1###########################
SET wait_timeout=86400;                                #设置连接超时时间，防止切换时翻车
SELECT @@global.server_id As Value;
SELECT VERSION() AS Value;                             #获取用于复制的server—id
SELECT @@global.gtid_mode As Value;                    #获取自身是否使用了GTID复制
SHOW GLOBAL VARIABLES LIKE ‘log_bin‘;                  #检查自身是否启用了binlog
SHOW MASTER STATUS;                                    #获取自身的事务执行情况
SELECT @@global.datadir AS Value;                      #获取自身数据文件的存储位置
SELECT @@global.slave_parallel_workers AS Value;       #检查是否采用了多线程复制
SHOW SLAVE STATUS;                                     #获取自身作为从库时的事务执行情况
SELECT @@global.read_only As Value;                    #获取自身是否开启了只读
SELECT @@global.relay_log_purge As Value;              #检查自身是否开启了relay log自动清除

原slave,3110端显示如下

SELECT @@global.server_id As Value;
SELECT VERSION() AS Value;
SELECT @@global.gtid_mode As Value;
SHOW GLOBAL VARIABLES LIKE ‘log_bin‘;
SHOW MASTER STATUS;
SELECT @@global.datadir AS Value;
SELECT @@global.slave_parallel_workers AS Value;
SHOW SLAVE STATUS;
SELECT @@global.read_only As Value;
SELECT @@global.relay_log_purge As Value;
SELECT @@global.relay_log_info_repository AS Value;     #差异处，获取自身relay信息保存形式（table）
SELECT Relay_log_name FROM mysql.slave_relay_log_info;  #差异处，获取正在使用的relay文件名称
SELECT @@global.datadir AS Value;
SHOW SLAVE STATUS;
SELECT Repl_slave_priv AS Value FROM mysql.user WHERE user = ‘repl‘;  #差异处，检查复制用户是否具有复制权限

第一部分小结：

        读取配置文件，确认主从关系与复制方式；

        根据主从关系复制方式，连接主库：设置必要参数，获取的复制详细信息/

                            连接从库：获取复制的详细信息，获取relay信息，获取repl账号并确认权限

接MHA manager端输出确认输入yes后

MHA manager端输出如下：

#####################输出段2###########################
[info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..
[info]  ok.               #注意，这里虽然显示关闭了非事务表，但是上面的抓包语句里面并没有出现相关语句
[info] Checking MHA is not monitoring or doing failover..  #检查MHA是否工作，切换时要求MHA manager停止运行
[info] Checking replication health on MySQL-Cent7-IP001110.. #检查主从健康程度
[info]  ok.
[info] Searching new master from slaves..                    #开始在从库中选取一个新主
[info]  Candidate masters from the configuration file:       #列出候选从库
[info]   MySQL-Cent7-IP001109(192.168.1.109:3109)  Version=5.7.19-log log-bin:enabled
[info]     GTID ON                                          #检查GTID开启情况
[info]   MySQL-Cent7-IP001110(192.168.1.110:3110)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
[info]     GTID ON                                          #检查GTID开启情况
[info]     Replicating from 192.168.1.109(192.168.1.109:3109)
[info]     Primary candidate for the new Master (candidate_master is set)
[info]  Non-candidate masters:
[info]  Searching from candidate_master slaves which have received the latest relay log events..
[info] #在所有从库中选取relay log最新的一个作为新的主库
From:
MySQL-Cent7-IP001109(192.168.1.109:3109) (current master)
 +--MySQL-Cent7-IP001110(192.168.1.110:3110)

To:
MySQL-Cent7-IP001110(192.168.1.110:3110) (new master)
 +--MySQL-Cent7-IP001109(192.168.1.109:3109)

Starting master switch from MySQL-Cent7-IP001109(192.168.1.109:3109) to MySQL-Cent7-IP001110(192.168.1.110:3110)? (yes/NO):
#程序询问是否可以进行切换了

master，3109端显示如下

#####################输出段2###########################
USE `unknown_database`;
FLUSH NO_WRITE_TO_BINLOG TABLES;                                         -- 锁非事务表
SELECT GET_LOCK(‘MHA_Master_High_Availability_Monitor‘, ‘0‘) AS Value;   -- 加一个模拟锁，防止出现切换程序多开的问题，这样多开的程序以为获取不到同名锁就会失败退出，
#GET_LOCK(str,time) -- str为锁的名称，0表示持续锁,5.7.5之后可以存在多个名称不同的GET_LOCK
SHOW PROCESSLIST;

原slave，3110端显示如下

#####################输出段2###########################
USE `unknown_database`;
SELECT GET_LOCK(‘MHA_Master_High_Availability_Failover‘, ‘0‘) AS Value;
SHOW SLAVE STATUS;
SHOW SLAVE STATUS;

第二部分小结：

        1.确认可以保存关闭非事务表后，关闭非事务表，加模拟锁防止切换程序多开造成切换异常

        2.从候选从库中选出拥有最新数据的从库，并将其设为要切换到的主库

接MHA manager端输出确认可以切换后

MHA manager端输出如下：

#####################输出段3###########################
[info] Checking whether MySQL-Cent7-IP001110(192.168.1.110:3110) is ok for the new master..
[info]  ok.   #检查上一步中被选定的新主库的是否真正可以成为主
[info] MySQL-Cent7-IP001109(192.168.1.109:3109): SHOW SLAVE STATUS returned empty result. To check replication filtering rules, temporarily executing CHANGE MASTER to a dummy host.          #没有检查到原来主（现在被作为从）作为从库的残留信息，不管3721先将其挂到一个空主上
[info] MySQL-Cent7-IP001109(192.168.1.109:3109): Resetting slave pointing to the dummy host.
[info] ** Phase 1: Configuration Check Phase completed.
[info] # 配置检查阶段结束
[info] * Phase 2: Rejecting updates Phase..
[info] #
master_ip_online_change_script is not defined. If you do not disable writes on the current master manually, applications keep writing on the current master. Is it ok to proceed? (yes/NO):
#切换程序检测到主机虚拟IP地址切换的地址没有定义，如果只切换主从身份的话，应用还会写到原来的主上，需要设置只读。询问是否真的要切换，这里我们只是做切换实验，先观察下两个实例的输出，然后直接切换即可。

原master，3109端显示如下

USE `unknown_database`;
FLUSH NO_WRITE_TO_BINLOG TABLES;                                         #强制保存并关闭非事务型表，防止事务不一致
SELECT GET_LOCK(‘MHA_Master_High_Availability_Monitor‘, ‘0‘) AS Value;
SHOW PROCESSLIST;
SHOW SLAVE STATUS;
CHANGE MASTER TO MASTER_HOST=‘dummy_host‘;                               #将原主作为从切换到一个莫须有的主机上
SHOW SLAVE STATUS;
RESET SLAVE /*!50516 ALL */;                                             #尝试清除自己之前残存的slave属性的信息，若本机不为主时，需要！
SELECT RELEASE_LOCK(‘MHA_Master_High_Availability_Monitor‘) As Value;

原slave，3110端显示如下

USE `unknown_database`;
SELECT GET_LOCK(‘MHA_Master_High_Availability_Failover‘, ‘0‘) AS Value;
SHOW SLAVE STATUS;
SHOW SLAVE STATUS;
SHOW PROCESSLIST;

第三部分总结：

    1.检查选定的从库的详细信息，确认真的是否可以作为新的主库

    2.处理从库之间的数据比对，若只有一个主和从，则将原主库先挂到一个莫须有的空主上

                            若有两个以上的从库，则需清理从库原来的slave记录

接MHA manager端输出确认，强制切换后：

MHA manager端输出如下：

#####################输出段4###########################
[info] Locking all tables on the orig master to reject updates from everybody (including root):
[info] Executing FLUSH TABLES WITH READ LOCK..
[info]  ok.   #所有的表都禁止写操作
[info] Orig master binlog:pos is 3109binlog.000070:536.
[info]  Waiting to execute all relay logs on MySQL-Cent7-IP001110(192.168.1.110:3110)..
[info]  master_pos_wait(3109binlog.000070:536) completed on MySQL-Cent7-IP001110(192.168.1.110:3110). Executed 0 events.
[info]   done.#将从库已经获得，但还未来得及执行的事务应用到自身，和其他没有跟上的从库
[info] Getting new master`s binlog name and position..
[info]  3110binlog.000049:536
[info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST=‘MySQL-Cent7-IP001110 or 192.168.1.110‘, MASTER_PORT=3110, MASTER_AUTO_POSITION=1, MASTER_USER=‘repl‘, MASTER_PASSWORD=‘xxx‘;
[info] Setting read_only=0 on MySQL-Cent7-IP001110(192.168.1.110:3110)..
[info]  ok.   #即将所有其他从库都用change master的语句切换到新的主，即原来的从110上
[info]
[info] * Switching slaves in parallel..
[info]        #即将并行切换所有从库
[info] Unlocking all tables on the orig master:
[info] Executing UNLOCK TABLES..
[info]  ok.   #释放原主库的表锁
[info] Starting orig master as a new slave..
[info]  Resetting slave MySQL-Cent7-IP001109(192.168.1.109:3109) and starting replication from the new master MySQL-Cent7-IP001110(192.168.1.110:3110)..
[info]  Executed CHANGE MASTER.
[info]  Slave started.
[info] All new slave servers switched successfully.
[info]
[info] * Phase 5: New master cleanup phase..
[info]        #即将清理新从库的主从信息，切换到主库
[info]  MySQL-Cent7-IP001110: Resetting slave info succeeded.
[info] Switching master to MySQL-Cent7-IP001110(192.168.1.110:3110) completed successfully.
              #切换完成

新slave，3109端显示如下：

#####################输出段4###########################
USE ``;
SELECT CONNECTION_ID() AS Value;
SET wait_timeout=86400;
SET GLOBAL read_only=1;                           #将自己设为只读
SHOW MASTER STATUS;
UNLOCK TABLES;                                    #释放表锁
CHANGE MASTER TO MASTER_HOST=‘192.168.1.110‘, MASTER_PORT=3110, MASTER_USER=‘repl‘, MASTER_PASSWORD=‘123456‘, MASTER_AUTO_POSITION=1; #把自己指向MHA选定的新主
START SLAVE;
SHOW SLAVE STATUS;                                #差异处，启动slave身份
SELECT RELEASE_LOCK(‘MHA_Master_High_Availability_Failover‘) As Value;   #释放锁止同应用的并发锁

新master，3110端显示如下：

#####################输出段4###########################
SHOW SLAVE STATUS;
SELECT MASTER_POS_WAIT(‘3109binlog.000070‘,‘536‘,0) AS Result;      #检查自己是否执行完差异事务
STOP SLAVE SQL_THREAD;                                              #停止从库SQL线程
SHOW SLAVE STATUS;
SHOW MASTER STATUS;
SELECT @@global.read_only As Value;
SELECT @@global.read_only As Value;
SET GLOBAL read_only=0;                                             #取消只读状态
USE ``;
SELECT UNIX_TIMESTAMP();
SELECT @@GLOBAL.SERVER_ID;
SET @master_heartbeat_period= 30000001024;
SET @master_binlog_checksum= @@global.binlog_checksum;
SELECT @master_binlog_checksum;
SELECT @@GLOBAL.GTID_MODE;
SELECT @@GLOBAL.SERVER_UUID;
SET @slave_uuid= ‘28ea40ab-9bbd-11e7-8cd1-000c29c31069‘;            #写入从库的UUID
STOP SLAVE;                                                         #停止自身作为从库的身份
SHOW SLAVE STATUS;
RESET SLAVE /*!50516 ALL */;                                        #清除自身作为从库的所有记录
SHOW SLAVE STATUS;
SELECT RELEASE_LOCK(‘MHA_Master_High_Availability_Failover‘) As Value; #释放锁止同应用的并发锁

第四部分总结：

    1.检查选定的新主实例relay日志是否存在未执行完的原主事务，并应用到新主

    原主库：锁止，记录主从信息，释放锁，将自己指向新的主,启动从库身份

    新主库:  自己执行完未来得及执行完的事务后停止自己从库身份，取消只读，清除自身作为从的记录

    最后释放切换程序的并发锁

原文地址：http://blog.51cto.com/l0vesql/2060910

时间： 2024-08-25 23:20:12

【MySQL】【高可用】从masterha_master_switch工具简单分析MHA的切换逻辑的相关文章

MySQL高可用复制管理工具 —— Orchestrator介绍

背景 在MySQL高可用架构中,目前使用比较多的是Percona的PXC,Galera以及MySQL 5.7之后的MGR等,其他的还有的MHA,今天介绍另一个比较好用的MySQL高可用复制管理工具:Orchestrator(orch). Orchestrator(orch):go编写的MySQL高可用性和复制拓扑管理工具,支持复制拓扑结构的调整,自动故障转移和手动主从切换等.后端数据库用MySQL或SQLite存储元数据,并提供Web界面展示MySQL复制的拓扑关系及状态,通过Web可更改MyS

MySQL 高可用架构在业务层面的应用分析

MySQL 高可用架构在业务层面的应用分析 http://mp.weixin.qq.com/s?__biz=MzAxNjAzMTQyMA==&mid=208312443&idx=1&sn=f9a0d03dd9a1cf3b3575c0241291e421&scene=22&srcid=seLU5tmZumKLzwVBIHzM#rd http://mp.weixin.qq.com/s?__biz=MzAxNjAzMTQyMA==&mid=208312443&am

MySQL高可用工具--orchestrator

orchestrator是一款MySQL高可用工具,其支持: 集群拓扑探测 集群拓扑重塑 故障恢复 提供3种使用方式: 命令行 HTTP API web页面 orchestator github地址 原文地址:https://www.cnblogs.com/lanyangsh/p/10629019.html

基于PXC的MySQL高可用环境简单部署

PXC简介 Percona XtraDB Cluster(简称PXC集群)提供了MySQL高可用的一种实现方法. 1.集群是有节点组成的,推荐配置至少3个节点,但是也可以运行在2个节点上. 2.每个节点都是普通的mysql/percona服务器,可以将现有的数据库服务器组成集群,反之,也可以将集群拆分成单独的服务器. 3.每个节点都包含完整的数据副本. PXC集群主要由两部分组成:Percona Server with XtraDB和Write Set Replication patches(使

MySQL高可用之MHA的搭建

MySQL MHA架构介绍: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正的高可用. 该软件由两部分组成:MHA Manag

MySQL高可用系列之MHA（一）

MHA,即Master High Availability Manager and Tools for MySQL,是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQL Replication(二层)环境,目的在于维持Master主库的高可用性. 一.简介 学习一个高可用小软件,不但要熟悉其功能,还要了解其架构及工作原理. 1.  架构 从架构上来说,MHA分为如下两大部分: (1) Node 我们知道,MHA是基于MySQL Replication环境的,

MySQL高可用架构-MHA环境部署记录

一.MHA介绍 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是日本的一位 MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQLReplication(二层)环境,目的在于维持Master主库的高可用性.是一套优秀的作为MySQL高可用性 环境下故障切

基于 MHA 的MySQL高可用-CentOS7（理论）

MHA 简介 MHA(Master High Availability)目前在 MySQL 高可用方面是一个相对成熟的解决方案, 它由日本 DeNA 公司的 youshimaton 员工(现就职于 Facebook 公司)开发,是一套优秀的作 为 MySQL 高可用性环境下故障切换和主从角色提升的高可用软件.在 MySQL 故障切换过程 中,MHA 能做到在 0~30 秒之内自动完成数据库的主从故障切换操作,并且在进行故障切换 的过程中,MHA 能在最大程度上保证数据的一致性,以达到真正意义上的

# IT明星不是梦 # MySQL高可用集群之MMM

MySQL高可用集群之MMM 一.MMM简介 MMM即Multi-Master Replication Manager for MySQL(mysql多主复制管理器),基于perl实现,关于mysql主主复制配置的监控.故障转移和管理的一套可伸缩的脚本套件(在任何时候只有一个节点可以被写入),MMM也能对从服务器进行读负载均衡,所以可以用它来在一组用于复制的服务器启动虚拟IP,除此之外,它还有实现数据备份.节点之间重新同步功能的脚本.MySQL本身没有提供replication failover