使用masterha_master_switch工具实现MySQL高可用MHA的自动切换
发表于:2025-11-07 作者:千家信息网编辑
千家信息网最后更新 2025年11月07日,本文主要给大家介绍使用masterha_master_switch工具实现MySQL高可用MHA的自动切换,文章内容都是笔者用心摘选和编辑的,具有一定的针对性,对大家的参考意义还是比较大的,下面跟笔者
千家信息网最后更新 2025年11月07日使用masterha_master_switch工具实现MySQL高可用MHA的自动切换
本文主要给大家介绍使用masterha_master_switch工具实现MySQL高可用MHA的自动切换,文章内容都是笔者用心摘选和编辑的,具有一定的针对性,对大家的参考意义还是比较大的,下面跟笔者一起了解下使用masterha_master_switch工具实现MySQL高可用MHA的自动切换吧。
简介:masterha_master_switch作为一个切换工具被集成在MHA程序包中,
安装:编译安装MHA manager后会在/usr/local/bin/中生成二进制可执行程序masterha_master_switch。
使用:
$masterha_master_switch --helpUsage: # 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-IP001109ip=192.168.1.109port=3109ssh_user=rootssh_port=22candidate_master=1 #设置该节点是否可以提升为主,1为是,0否check_repl_delay=0 #发生故障后是否检查本实例主从落后程度,0否,1是[server2]hostname=MySQL-Cent7-IP001110ip=192.168.1.110port=3110ssh_user=rootssh_port=22candidate_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-idSELECT @@global.gtid_mode As Value; #获取自身是否使用了GTID复制SHOW GLOBAL VARIABLES LIKE 'log_bin'; #检查自身是否启用了binlogSHOW 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; -- 刷新表缓存到硬盘,同时不记录这条到binlogSELECT GET_LOCK('MHA_Master_High_Availability_Monitor', '0') AS Value; -- 加一个模拟锁,防止出现切换程序多开的问题,这样多开的程序以为获取不到同名锁就会失败退出,#GET_LOCK(str,time) -- str为锁的名称,0表示持续锁,5.7.5之后可以存在多个名称不同的GET_LOCKSHOW 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'; #写入从库的UUIDSTOP SLAVE; #停止自身作为从库的身份SHOW SLAVE STATUS; RESET SLAVE /*!50516 ALL */; #清除自身作为从库的所有记录SHOW SLAVE STATUS;SELECT RELEASE_LOCK('MHA_Master_High_Availability_Failover') As Value; #释放锁止同应用的并发锁看完以上关于使用masterha_master_switch工具实现MySQL高可用MHA的自动切换,很多读者朋友肯定多少有一定的了解,如需获取更多的行业知识信息 ,可以持续关注我们的行业资讯栏目的。
切换
输出
检查
信息
程序
主从
事务
文件
配置
实例
差异
数据
工具
名称
情况
应用
原主
故障
目录
程度
数据库的安全要保护哪些东西
数据库安全各自的含义是什么
生产安全数据库录入
数据库的安全性及管理
数据库安全策略包含哪些
海淀数据库安全审计系统
建立农村房屋安全信息数据库
易用的数据库客户端支持安全管理
连接数据库失败ssl安全错误
数据库的锁怎样保障安全
k22r-02服务器
像素工厂服务器怎么加mod
科技最高境界就是互联网吗
软件开发做哪方面越老越吃香
如何查询手机云端数据库
我国软件开发企业发展前景
网络安全模式可以玩游戏吗
金蝶商如何收缩数据库
僵尸入侵服务器
互联网科技公司行业背景
网络安全标语解读
苹果提示云彩服务器已崩溃
榆林网络技术产品
图数据库与图计算
服务器rpc错误什么意思
服务器宝藏
5g时代的网络安全工作
统计局要求企业填的数据库
简单软件开发软件
网络安全特色大学
黄浦区服务器设备回收公司哪里有
服务器跑ansys效果一般
ecs服务器在哪执行命令
服务器虚拟机控制未运行
首届锦途工程网络安全员
集团公司软件开发
奇异果园app软件开发
网络安全防护和软件开发
杨浦区信息化软件开发哪家好
杭州睿趣网络技术