主库切换需先确认从库复制状态正常，选择最新从库提升为主库并启用binlog，其余从库重新指向新主库并启动复制，最后更新应用端或中间件的主库地址为新IP，建议结合VIP或自动化工具减少风险。
MySQL主库切换通常发生在主从架构中，当原主库出现故障或需要维护时，需将一个从库提升为新的主库。这个过程也叫“主从切换”或“故障转移”。以下是常见的主库切换操作方法。
确认当前主从状态
在切换前，先确认各节点的复制状态和数据一致性：
- 登录各个从库，执行 SHOW SLAVE STATUS\G，检查 Slave_IO_Running 和 Slave_SQL_Running 是否为 Yes，确保复制正常。
- 查看 Seconds_Behind_Master，确认从库没有延迟。
- 记录当前主库的 File 和 Position（即 Binlog 文件名和位置），用于后续比对。
选择并提升新主库
选择一个数据最新、运行稳定的从库作为新主库：
- 停止该从库的复制线程：STOP SLAVE;
- 断开与旧主库的连接：RESET SLAVE ALL;
- 启用二进制日志（如未开启），确保配置文件中有：
log-bin=mysql-bin
server-id=2（需唯一） - 重启 MySQL 或确认 binlog 已生效。
重新配置其他从库指向新主库
将剩余从库的主库指向新提升的主库：
- 在每个从库上执行：
CHANGE MASTER TO
MASTER_HOST='新主库IP',
MASTER_USER='repl',
MASTER_PASSWORD='密码',
MASTER_LOG_FILE='新主库的Binlog文件名',
MASTER_LOG_POS=对应位置; - 启动复制：START SLAVE;
- 再次检查 SHOW SLAVE STATUS\G，确认复制正常运行。
应用端更新主库地址
切换完成后，应用程序必须连接到新的主库：
- 修改应用配置中的数据库写入地址为主库新IP。
- 如有使用中间件（如 MHA、MaxScale、ProxySQL），更新其主库路由规则。
- 建议通过域名或VIP方式管理主库地址，避免硬编码IP。
基本上就这些。整个过程要小心操作，避免数据丢失或复制中断。如果是生产环境，建议在低峰期进行，并提前备份关键节点。自动化工具如 MHA 或 Orchestrator 可减少人为错误，提高切换效率。
