MySQL主从复制切换，通常是指在主库出现故障或需要维护时，将一个从库提升为新的主库，并让其他从库指向新主库的过程。这个过程也叫“主从切换”或“故障转移”。以下是实现MySQL主从切换的常用操作方法。
确认当前主从状态
切换前，先检查各节点的复制状态，确保数据尽可能一致。
1. 在原主库上执行：SHOW MASTER STATUS; 查看当前主库的二进制日志文件名和位置。
2. 在各个从库上执行：SHOW SLAVE STATUS\G 查看复制是否正常运行（Slave_IO_Running 和 Slave_SQL_Running 为 Yes），并记录 Relay_Master_Log_File 和 Exec_Master_Log_Pos，用于判断从库的数据同步进度。
选择合适的从库作为新主库
选择延迟最小、数据最完整的从库作为候选主库。
比较各从库的 Seconds_Behind_Master 值，越小越好。 确保该从库已应用完所有中继日志（Relay Log）。 可执行 STOP SLAVE; 暂停复制，防止在切换过程中接收到旧主库的数据。提升从库为新主库
在选定的从库上执行以下操作：
1. 停止从库复制线程：STOP SLAVE;
2. 重置主库信息（清除原有复制配置）：RESET SLAVE ALL;
3. 开启写权限（如之前设置只读）：如果从库设置了 read_only=1，需关闭：
SET GLOBAL read_only = OFF;
同时建议检查 super_read_only 是否也关闭（如有启用）。
此时，该从库已成为可写的主库。
重新配置其他从库指向新主库
将剩余从库的复制源更改为新的主库。
1. 在每个从库上执行：STOP SLAVE;
CHANGE MASTER TO
MASTER_HOST='新主库IP',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_LOG_FILE='新主库的binlog文件名',
MASTER_LOG_POS=新主库的binlog位置;
START SLAVE;
2. 获取新主库的 binlog 位置：在新主库上执行 SHOW MASTER STATUS; 获取正确的 File 和 Position。
验证复制状态
在所有从库上执行 SHOW SLAVE STATUS\G，确认：
Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 0（表示已追平）可以插入测试数据验证是否正常复制。
更新应用连接配置
如果应用直连数据库主库，需将应用的数据库连接地址指向新的主库IP或域名。使用中间件（如ProxySQL、MaxScale）的，需更新其路由规则。
注意事项
切换期间尽量避免对原主库写入，防止数据分裂。 若原主库恢复，不要直接重新加入为主库，应作为从库重新配置，防止环形复制或数据冲突。 推荐使用 GTID 模式进行复制，可简化切换过程，避免日志位置匹配错误。 生产环境建议结合 MHA、Orchestrator 等工具实现自动切换。基本上就这些。手动切换虽可行，但要注意步骤顺序和数据一致性，避免服务中断或数据丢失。
