必须确认从库已完全追平：Slave_IO_Running=No、Slave_SQL_Running=Yes、SHOW PROCESSLIST显示“Has read all relay log”，再核对Relay_Master_Log_File与Exec_Master_Log_Pos；之后STOP SLAVE、RESET SLAVE ALL、关闭read_only，最后用SHOW MASTER STATUS配置其他从库。
能换，但必须先确认从库已完全应用完所有中继日志，否则必然丢数据；关键不是“停不停”，而是“有没有真正追平”。
怎么判断从库是否真的追平了原主库？
很多人只看 Seconds_Behind_Master = 0 就动手，这是最常见误操作起点。这个值在主库宕机后会变成 NULL 或停滞不更新，完全不可信。
真正可靠的判断依据是这三点同时满足：
-
Slave_IO_Running: No（说明已连不上原主库，IO线程停了） -
Slave_SQL_Running: Yes（SQL线程还在跑） - 执行
SHOW PROCESSLIST，看到 SQL 线程的State是Has read all relay log; waiting for more updates
再查 Relay_Master_Log_File 和 Exec_Master_Log_Pos，这两个值代表它最后执行到原主库哪条 binlog，后续切换时其他节点要用。
STOP SLAVE 和 RESET SLAVE ALL 的区别与风险
STOP SLAVE 只暂停复制线程，master.info 和 relay-log.info 文件都还留着；而 RESET SLAVE ALL 会彻底删掉这两个文件，清空所有复制元数据。
所以：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 计划内切换且原主库确定不再回归 → 用
RESET SLAVE ALL - 只是临时断开、后续可能切回 → 用
STOP SLAVE+ 手动记录SHOW SLAVE STATUS\G输出，避免信息丢失
特别注意：如果复制参数写死在 my.cnf 里（比如 master-host=），RESET SLAVE ALL 后重启 MySQL 仍会读配置自动重连，导致意外恢复旧关系 —— 这就是为什么官方强烈建议不要把复制配置放配置文件里。
CHANGE MASTER TO 指向新主库时最关键的三个参数
其他参数可以省略，但这三个必须显式指定，否则容易连错位置或跳过事务：
-
MASTER_LOG_FILE = 'mysql-bin.000012'：必须填新主库上SHOW MASTER STATUS返回的File值，不是从旧状态里抄的 -
MASTER_LOG_POS = 154：对应上面File的起始偏移，通常为 154（MySQL 8.0+ 默认），但不能假设，得实查 -
MASTER_AUTO_POSITION = 0：如果没开 GTID，必须显式关掉，否则CHANGE MASTER TO会忽略MASTER_LOG_FILE和MASTER_LOG_POS，直接报错
示例命令：
CHANGE MASTER TO MASTER_HOST='192.168.1.20', MASTER_USER='repl', MASTER_PASSWORD='repl_pass', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=154, MASTER_AUTO_POSITION=0;
切换后最容易被跳过的验证动作
很多故障出现在“以为切成功了”之后，尤其是以下三项常被跳过：
- 在新主库执行一条带时间戳的测试写入：
INSERT INTO test_switch VALUES (NOW()); - 立即在新从库查这条记录是否出现、时间是否一致
- 检查新从库的
SHOW SLAVE STATUS\G中Seconds_Behind_Master是否保持为 0，且Retrieved_Gtid_Set和Executed_Gtid_Set相等（若启用 GTID）
特别注意：应用连接字符串里的 host 和端口是否已指向新主库，DNS 缓存 或连接池可能仍连着老地址 —— 这类问题不会报错，只会静默写错库。
