主从切换本质是受控角色互换，需确保零数据丢失与最小中断：先验证从库同步健康（io/sql线程运行且延迟为0），再stop slave并记录show master status位点，接着修改server-id、启用log_bin、关闭read_only并重启，最后更新应用或中间件写流量指向新主库。
将从库提升为新的业务主库，本质是一次受控的主从角色切换，目标是零数据丢失、最小化写入中断，并确保应用能无缝接管。关键不在“怎么执行命令”，而在“切换前是否准备充分”和“切换后能否稳住流量”。
确认从库已完全同步且状态健康
这是切换的前提，跳过等于埋雷。
- 在从库上执行 SHOW SLAVE STATUS\G，重点检查三项： Slave_IO_Running = Yes（IO线程正常拉日志）、 Slave_SQL_Running = Yes（SQL线程正常回放）、 Seconds_Behind_Master = 0（无复制延迟）
- 若使用 GTID，还需确认 Retrieved_Gtid_Set 和 Executed_Gtid_Set 完全一致；若用传统 position 复制，比对 Master_Log_File/Read_Master_Log_Pos 与 Relay_Master_Log_File/Exec_Master_Log_Pos 是否相等
- 检查错误日志中近期无
duplicate key、no such table或relay log corruption类报错
停止复制并固化当前状态
避免切换过程中新事件干扰，同时为后续原主库降级做准备。
- 在从库上执行：STOP SLAVE;
- 立即执行：SHOW MASTER STATUS;，记录返回的 File 和 Position（或 Executed_Gtid_Set）。这是原主库后续接入时需要的起点
- 可选但推荐：执行 RESET SLAVE ALL; 清除旧复制元数据（避免残留配置干扰），但仅在确认不再回切原主库时操作
配置从库为可写主库
不是改几个参数就完事，而是让它真正具备主库能力。
- 修改 my.cnf（或 my.ini）中的 [mysqld] 段： 设置唯一且不同于原主库的 server-id（如原主库是 1，这里设为 2）； 启用二进制日志：log_bin = mysql-bin； 可加 binlog_format = ROW（若原主库已是 ROW，必须保持一致）； 关闭只读：read_only = OFF（默认值，但显式设更稳妥）
- 重启 MySQL 服务使配置生效
- 重启后验证：SHOW VARIABLES LIKE 'server_id';、SHOW VARIABLES LIKE 'log_bin';、SELECT @@read_only; 均应符合预期
完成切换并更新业务链路
这一步决定业务是否感知到切换——它不发生在数据库里，而发生在应用和中间件中。
- 将应用的数据源连接地址，由原主库 IP/端口，切换至新主库（即刚升级的原从库）
- 若使用 VIP、LVS、DNS 或 Proxy（如 ProxySQL、ShardingSphere-Proxy），需更新路由规则，把写流量全部导向新主库
- 切流后，立即在新主库上执行一条简单写操作（如 INSERT INTO test_switch VALUES (NOW());），确认写入成功且无权限/认证错误
- 监控新主库的 QPS、TPS、慢查询、连接数，对比切换前基线，确认负载承接正常
整个过程不复杂，但容易忽略前置校验和流量切换的协同。只要同步状态准、配置改得清、切流动作快，一次主从转换就能做到用户无感。
