MySQL主从切换的核心是原从库升主、原主库降从，需确保数据一致性和服务连续性。切换前须确认从库已追平主库（Seconds_Behind_Master=0、位点或GTID一致）；切换中在主库加读锁并记录binlog位置，再于从库执行STOP SLAVE、RESET SLAVE ALL、关闭read_only；切换后原主库需CHANGE MASTER TO新主库并验证复制状态及数据同步。
MySQL主从切换的核心是让原从库升为主库，原主库降为从库，整个过程需确保数据一致性、服务连续性，并避免脑裂。关键不在于命令本身，而是切换前的检查、切换中的顺序控制和切换后的验证。
确认从库已追平主库数据
这是切换的前提。若从库延迟较大，直接切换会导致数据丢失。
- 在从库执行 SHOW SLAVE STATUS\G，检查 Seconds_Behind_Master 是否为 0；
- 同时核对 Read_Master_Log_Pos 和主库的 Master_Log_File + Exec_Master_Log_Pos（可通过主库 SHOW MASTER STATUS 获取）是否一致；
- 如有 GTID，确
认 Retrieved_Gtid_Set 等于 Executed_Gtid_Set，且与主库的 gtid_executed 完全一致。
停止主库写入并确认无新事务
避免切换窗口期产生新数据，造成主从不一致。
- 在主库执行 FLUSH TABLES WITH READ LOCK;（注意：该操作会阻塞写，需快速操作）；
- 再执行一次 SHOW MASTER STATUS; 记录当前 binlog 文件名与位置（或 GTID set），后续从库将以此为起点同步；
- 保持连接不退出，锁未释放前不要断开——这是保证位置精确的关键。
提升从库为主库并重置复制关系
从库“转正”后，需关闭 SQL 线程、清除旧主信息，并开放写权限。
- 在原从库执行：
STOP SLAVE;
RESET SLAVE ALL;（清空 relay log 和 master info）；
SET GLOBAL read_only = OFF;（如已启用 read_only，需关闭）；
- 此时该库已成为新主库，应用可指向它继续读写；
- 原主库重启复制时，需用 CHANGE MASTER TO 指向新主库，并指定新主库当前的 binlog 位置或 GTID。
恢复原主库为从库并验证同步
原主库角色转换后，必须重新建立复制链路，并持续观察。
- 在原主库执行：
STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='新主库IP', MASTER_USER='repl', ...（填入新主库信息及刚才记录的 binlog 位置或 MASTER_AUTO_POSITION=1）；
START SLAVE;
- 立即检查 SHOW SLAVE STATUS\G，确认 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes；
- 插入一条测试数据到新主库，确认能否在原主库（现从库）中及时查到。
整个流程不复杂但容易忽略细节，尤其锁表时机、GTID一致性校验和复制参数重配。自动化工具（如 MHA、Orchestrator）可大幅降低人工误操作风险，但理解底层逻辑仍是安全切换的基础。
认 Retrieved_Gtid_Set 等于 Executed_Gtid_Set，且与主库的 gtid_executed 完全一致。