必须先执行 STOP SLAVE，因为 MySQL 不允许在复制线程运行时修改主库连接参数；CHANGE MASTER TO 是原子性操作，会清空 relay log 并重置位点，若 I/O 或 SQL 线程仍在运行，将触发锁冲突或报错 ERROR 1198/1200。
直接结论：MySQL 5.7 中切换复制源必须先 STOP SLAVE，再执行 CHANGE MASTER TO，最后 START SLAVE；跳过 STOP SLAVE 会报错或导致状态不一致。
为什么必须先执行 STOP SLAVE
MySQL 不允许在复制线程运行时修改主库连接参数。CHANGE MASTER TO 是原子性配置变更操作，底层会清空 relay log 并重置 SQL 线程位点。如果 I/O 或 SQL 线程仍在运行，会触发锁冲突或报错：ERROR 1198 (HY000): This operation cannot be performed with a running slave IO thread 或 ERROR 1200 (HY000): The server is not configured as slave（后者常因未正确初始化复制元数据导致）。
常见误操作是只改了配置却没停服务，结果 SHOW SLAVE STATUS\G 里 Slave_IO_Running 和 Slave_SQL_Running 仍为 Yes，但新配置根本没生效。
- 务必在执行
CHANGE MASTER TO前确认复制已停止：STOP SLAVE; - 执行后检查
SHOW SLAVE STATUS\G中Seconds_Behind_Master是否为NULL（表示已停止） - 若中途失败，不要直接
START SLAVE，先用RESET SLAVE ALL;清理残留元数据（尤其在多源复制场景下）
CHANGE MASTER TO 必填参数与 GTID 模式差异
是否启用 GTID 决定你该提供哪类日志定位信息。MySQL 5.7 默认支持 GTID，但很多生产环境仍用传统 file/pos 方式——两者不能混用，否则启动失败。
启用 GTID（gtid_mode=ON）时：
- 必须设置
MASTER_AUTO_POSITION=1 - 禁止指定
MASTER_LOG_FILE和MASTER_LOG_POS，否则报错：ERROR 3079 (HY000): Cannot use MASTER_LOG_FILE and MASTER_LOG_POS when MASTER_AUTO_POSITION = 1 - 示例：
CHANGE MASTER TO MASTER_HOST='192.168.1.2', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_AUTO_POSITION=1;
禁用 GTID（传统模式）时：
- 必须显式提供
MASTER_LOG_FILE和MASTER_LOG_POS，值来自新主库的SHOW MASTER STATUS - 忽略
MASTER_AUTO_POSITION或设为 0（默认） - 示例：
CHANGE MASTER TO MASTER_HOST='192.168.1.2', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=194;
多源复制下切换单个通道的注意事项
MySQL 5.7 多源复制要求每个主源必须有独立通道名（channel），切换时必须显式指定 FOR CHANNEL 'xxx'，否则操作默认作用于匿名通道（即传统单主），其他通道不受影响，极易误判。
- 查看当前所有通道：
SELECT * FROM performance_schema.replication_connection_configuration; - 切换指定通道：
CHANGE MASTER TO MASTER_HOST='192.168.1.3', ... FOR CHANNEL 'master_b'; - 启动指定通道：
START SLAVE FOR CHANNEL 'master_b'; - 检查通道状态：
SHOW SLAVE STATUS FOR CHANNEL 'master_b'\G - 遗漏
FOR CHANNEL会导致新配置写入匿名通道，而原通道继续连旧主，且SHOW SLAVE STATUS默认只显示匿名通道，容易漏看
切换后验证与常见卡点
启动复制后不能只看 Slave_IO_Running: Yes 就认为成功——SQL 线程可能卡在某个错误上，Seconds_Behind_Master 保持不变或持续增长。
- 重点检查：
Slave_SQL_Running_State字段，正常应为Slave has read all relay log; waiting for more updates - 若出现
Fatal error: ... duplicate entry，说明新主库已有从库缺失的数据，需手动跳过（SET GLOBAL sql_slave_skip_counter = 1;）或修复数据一致性 - 若报
UUID mismatch错误（The slave I/O thread stops because master and slave have equal MySQL server UUIDs），不是网络问题，而是从库auto.cnf文件被意外覆盖或复制，需删掉/var/lib/mysql/auto.cnf并重启 mysqld 生成新 UUID - 切换后首次
SHOW SLAVE STATUS\G中的Master_Host、Master_UUID必须与新主库一致，否则配置未生效
最易被忽略的是：切换前未校验新主库的 binlog 是否开启、server-id 是否唯一、复制用户权限是否正确——这些基础项一旦出错，START SLAVE 表面成功，实则 I/O 线程几秒后自动退出，日志里只有一行 Connection refused 或超时，排查时容易绕远路。
