一步步教你如何做MySQL 主从切换的超详细步骤
版本:
MySQL-5.7.32+GTID
前言:
本文讲述MySQL主从切换流程，切换步骤主要针对主备正常切换以及主库宕机备库切换两个场景，掌握正确的切换流程，可以有效避免切换过程中可能出现的数据不一致问题以及提高整体切换的时间
主从环境:
场景一:主备正常切换，此场景主要是针对在主备同步复制正常的情况下进行的主备切换，例如：灾备演练，计划性的主备切换。
切换步骤:
1 切断应用对主库的流量
2 主库备库设置只读
set global super_read_only=ON;
3 查看备库复制进程状态
确认Slave_IO_Running，Slave_SQL_Running状态为YES，Seconds_Behind_Master为0
4 比对主备两边的GTID是否一致
获取主备两边的executed_gtid集合，进行比对
通过GTID_SUBSET函数进行比对
若在master_gtid_executed中的GTID，也存在slave_gtid_executed中，则返回true(1)，否则返回false(0)
返回一，代表主库GTID已经在从库完成执行过，两边是一致的
5 从库停掉复制进程并清空主从信息
reset slave all;
6 从库关闭只读开启读写，转为新主库
set global super_read_only=off;
7 主库设置执行新主库的复制链路，转为新备库，完成主从切换
start slave;
show slave status\G
8 应用流量切向新主库
场景二:主库宕机备库切换为主库，这种情况主要是在异步模式或者非强一致半同步下，主库的异常宕机，可能存在数据没有完全同步到从库的情况，需要去核验追加数据。
1 对于主库宕机，数据库损坏没法正常启动时，如果binlog可以获取，则可以对binlog进行离线分析，获取差异的数据
获取备库那边已经执行过的gtid set
如果已经写入数据的新主库，不能直接读取binlog进行恢复，因为可能会出现数据不一致，主键冲突等问题，可以从binlog里面排除从库已经执行过的gtid并离线解析成sql语句，交给应用去分析是否补入数据
2b3039c9-57fa-11eb-b504-000c29ed797a:1-8256287,
3a59d149-d4b8-11eb-8cf6-000c29a6e7b4:1-10,
a0a3d4b2-fff8-11eb-a420-000c29a6e7be:1-10011′ /opt/mysql/log/nlog.000150 > /tmp/binlog_150_gtid.sql;
如果从库应用还未写入，未产生新数据，则可以从binlog里面排除从库已经执行过的gtid直接导入追加数据
2b3039c9-57fa-11eb-b504-000c29ed797a:1-8256287,
3a59d149-d4b8-11eb-8cf6-000c29a6e7b4:1-10,
a0a3d4b2-fff8-11eb-a420-000c29a6e7be:1-10011′ /opt/mysql/log/nlog.000150 | mysql -uroot -p -S /opt/mysql/3306/data/mysql.sock -P3306
2 对于主库宕机，但旧主库可以重新启动拉起，则在启动后，如果新主库应用还未写入新数据，可以将新主库change master复制继续指向旧主库，读取未应用的日志恢复；
已经写入数据的新主库，不能直接读取binlog进行恢复，因为可能会出现数据不一致，主键冲突等问题，而是应该将数据解析成sql语句，让应用去分析是否补入数据。
用my2sql在线解析binlog日志获取sql语句，需要获取开始的日志号以及读取位点，读取位点可以根据–exclude-gtids排除gtid后解析binlog的开始位置读取
目录下会生产forward+日志号的文本，里面存放解析出来的sql
总结
到此这篇关于MySQL主从切换的文章就介绍到这了,更多相关MySQL主从切换内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
