必须先执行 STOP REPLICA（MySQL 8.0.22+）或 STOP SLAVE（旧版本），确认 Slave_IO_Running 和 Slave_SQL_Running 均为 No 后，再执行 CHANGE MASTER TO 或 CHANGE REPLICATION SOURCE TO，否则报 ERROR 3021。
CHANGE MASTER TO 报 ERROR 3021 怎么办
直接执行 CHANGE MASTER TO 却报 ERROR 3021 (HY000): This operation cannot be performed with a running replication thread，说明复制线程还在跑。这不是配置写错了，是操作顺序错了。
必须先停掉复制，再改配置：
-
STOP REPLICA;（MySQL 8.0.22+）或STOP SLAVE;（旧版本） - 确认
SHOW REPLICA STATUS\G中Slave_IO_Running和Slave_SQL_Running都是No - 此时才能安全执行
CHANGE MASTER TO或CHANGE REPLICATION SOURCE TO
漏掉 STOP 这一步，后续所有位点、GTID、auto_position 设置都会被忽略或静默失败。
用 SHOW MASTER STATUS 获取新主库位点时容易错哪
很多人在新主库上随手执行一次 SHOW MASTER STATUS 就抄下 File 和 Position，结果从库启动后卡在 Waiting for master to send event——因为没等主库把最后一批事务刷进 binlog 文件。
正确做法是切换前就强制刷盘：
- 在原主库（尚未停写时）先执行
FLUSH LOGS;和FLUSH BINARY LOGS; - 再立即执行
SHOW MASTER STATUS;，记下输出的File和Position - 这个组合值才是“已持久化、可被从库安全消费”的终点位置
如果跳过 FLUSH 直接查，Position 可能指向内存中未落盘的日志偏移，从库 IO 线程会找不到对应事件。
GTID 模式下该用 MASTER_AUTO_POSITION 还是手动指定 file/pos
只要新主库和待配置的从库都开启 gtid_mode=ON 且 enforce_gtid_consistency=ON，就必须用 MASTER_AUTO_POSITION = 1，不能填 MASTER_LOG_FILE 和 MASTER_LOG_POS。
原因很实际：
- 手动填 file/pos 在 GTID 模式下会被忽略，
START REPLICA后仍走 auto-position 流程 - 但如果
source_auto_position=0（默认值），而你又没清空gtid_purged，从库会拒绝连接，报错The slave has purged... - 所以 GTID 场景下，必须先
RESET REPLICA ALL;，再确认SELECT @@gtid_mode, @@enforce_gtid_consistency;全是ON，最后执行：CHANGE REPLICATION SOURCE TO SOURCE_HOST='xxx', SOURCE_USER='repl', SOURCE_PASSWORD='xxx', SOURCE_AUTO_POSITION = 1;
从库启同步后 Seconds_Behind_Master 一直不归零怎么办
常见假象：Slave_IO_Running: Yes、Slave_SQL_Running: Yes，但 Seconds_Behind_Master 停在某个正数不动，或者反复跳变。
先别急着跳过错误，重点排查这三处：
- 查
SHOW REPLICA STATUS\G中的Retrieved_Gtid_Set是否为空——为空说明 IO 线程根本没拉到任何新事务，可能是网络不通、账号权限不足、或新主库的bind-address没放开 - 看
Executed_Gtid_Set是否包含从库自己误写的 GTID（比如运维连上去执行过 INSERT）——若有，必须先RESET MASTER;清空本地 GTID 日志，否则无法对齐 - 检查新主库是否启用了
replica_parallel_type = LOGICAL_CLOCK，而从库是旧版本或未配一致；此时 SQL 线程可能卡在并行调度逻辑里，临时关掉：SET GLOBAL replica_parallel_type = 'DATABASE';
真正棘手的是 relay log 已存在但对应 binlog 被 purge 的情况——这时不是配置问题，而是数据链断了，得重建从库，不能硬扛。
