确认从库已同步完成
切换前必须确保从库的复制已追上主库，否则会丢失数据。执行 SHOW SLAVE STATUS\G，重点检查以下两项：
Seconds_Behind_Master = 0：表示从库没有延迟 Slave_IO_Running 和 Slave_SQL_Running 都为 Yes：说明复制线程正常运行若存在延迟，可等待同步完成，或在业务低峰期操作；必要时用 SELECT MASTER_POS_WAIT() 等待指定 binlog 位置。
停止原主库写入并刷新读写状态
为避免切主过程中产生新数据，需临时阻断原主库的写操作：
在原主库执行 FLUSH TABLES WITH READ LOCK;（全局只读锁） 再执行 SHOW MASTER STATUS; 记下当前 binlog 文件名和 position，后续从库需基于此点恢复 保持连接不退出，防止锁自动释放此时应用应停止向原主库写入，可配合服务层配置或代理（如 ProxySQL、HAProxy）将流量切至只读模式。
提升从库为新主库
在目标从库上执行以下步骤：
停止复制：STOP SLAVE; 重置复制信息（清除旧主配置）：RESET SLAVE ALL; 开启写能力（如有 read_only=ON，需关闭）：SET GLOBAL read_only = OFF; 确认无误后，该库即可作为新主库接受写请求注意：若使用 GTID 复制，还需记录 SELECT @@GLOBAL.GTID_EXECUTED;，供后续其他从库重新指向新主时使用。
重新配置其他从库指向新主
原集群中其余从库需重新指向新的主库：
在每个从库上先执行 STOP SLAVE; 使用 CHANGE MASTER TO 指向新主库 IP、端口、账号密码，并指定正确的 binlog 文件与 position（或 GTID） 启动复制：START SLAVE;，再用 SHOW SLAVE STATUS\G 验证若原主库后续要转为从库，也按同样方式配置它指向新主库即可。
清理与验证
切换完成后需做几项收尾工作：
在原主库执行 UNLOCK TABLES; 解除读锁 检查新主库的写入是否正常（如插入测试数据、查 binlog 是否更新） 验证各从库同步状态、延迟、错误日志（Last_IO_Errno、Last_SQL_Errno） 更新应用配置、DNS、中间件路由规则等，确保后续流量正确打到新主库整个过程建议在维护窗口内操作，并提前做好回滚预案（如保留原主库 binlog、备份关键位点）。
