主从切换后原主库重做从库需先STOP REPLICA，再CHANGE REPLICATION SOURCE TO；若GTID不一致须统一配置并RESET REPLICA ALL；重建时优先用mysqldump --single-transaction或mysqlpump，禁用--all-databases；跳过冲突必须用SET GTID_NEXT，不可用sql_slave_skip_counter。
主从切换后原主库变从库，CHANGE REPLICATION SOURCE TO 报错 ERROR 3021
切换后原主库要重做为从库，但直接执行 CHANGE REPLICATION SOURCE TO 常报 ERROR 3021 (HY000): This operation cannot be performed with a running replication thread。根本原因是复制线程还在跑，而你没停它。
- 必须先执行
STOP REPLICA;（MySQL 8.0.22+）或STOP SLAVE;（旧版本），再改配置 - 如果之前没记录新主库的
source_log_file和source_log_pos，不能靠猜——得去新主库查SHOW MASTER STATUS;的输出 - MySQL 8.0.26+ 默认启用
replica_parallel_type = LOGICAL_CLOCK，若原主库是旧版本或配置不一致，启复制时可能卡在Retrieved_Gtid_Set不同步，建议切前统一关闭并清理 GTID 相关状态
重建从库数据：用 mysqldump 还是 mysqlpump？
不是所有场景都适合 dump，选错工具会导致锁表时间长、GTID 冲突或无法恢复。
- 如果原主库写压力大、不能长时间锁表：
mysqldump --single-transaction --master-data=2 --triggers --routines --databases db1 db2是底线选择；--single-transaction依赖 InnoDB，MyISAM 表仍会锁 - MySQL 5.7+ 推荐用
mysqlpump，支持并行导出、自动跳过系统库，但默认不导出mysql.user表权限，需显式加--include-databases=mysql并手动处理权限 - 千万别用
mysqldump --all-databases恢复到 GTID 模式的新从库——它会把原主库的gtid_executed写死进 SQL，导致后续复制报ERROR 1872
RESET REPLICA ALL 后还连不上？检查 source_auto_position 和 gtid_mode
清空复制状态后连不上，大概率是 GTID 配置没对齐。新主库和待重建的从库必须严格满足：两者 gtid_mode=ON、enforce_gtid_consistency=ON，且 source_auto_position=1。
- 执行
RESET REPLICA ALL;后，务必确认SELECT @@gtid_mode, @@enforce_gtid_consistency;返回都是ON，否则START REPLICA会静默失败 - 如果新主库开了
source_auto_position=1，从库也必须开，否则即使 binlog 位置对，也会因 GTID 集合不匹配拒绝连接 -
SHOW REPLICA STATUS\G里Retrieved_Gtid_Set为空、Executed_Gtid_Set有值，说明从库自己执行过事务（比如误操作写了数据），必须先RESET MASTER;清空本地 GTID 日志，再重新拉取
跳过临时冲突：用 SET GLOBAL gtid_next 还是 sql_slave_skip_counter？
重建后偶尔遇到主键冲突或 duplicate entry，别急着跳过——先看是不是因为从库残留了旧数据没清干净。
- MySQL 5.7.6+ 必须用 GTID 方式跳过：
SET SESSION gtid_next='xxx-xxx-xxx:1'; BEGIN; COMMIT; SET SESSION gtid_next='AUTOMATIC';，其中xxx-xxx-xxx:1要换成实际冲突事务的 GTID，从SHOW REPLICA STATUS\G的Last_IO_Error里找 -
sql_slave_skip_counter在 GTID 模式下已禁用，强行设会报ERROR 1790，别试 - 跳过只是应急，真正该做的是：重建前用
SELECT COUNT(*) FROM mysql.gtid_executed;确认从库是否干净；如有残留，RESET MASTER;比手动删表更安全
重建从库最耗时间的环节不在 dump 或导入，而在 GTID 集合校验和 relay log 回放。哪怕数据量不大，只要新主库 binlog 里有大量小事务，从库初始化时就容易卡在 Waiting for source to send event ——这不是网络问题，是 GTID 协议本身的同步开销。动手前，务必在测试环境走一遍完整流程，尤其验证 SHOW REPLICA STATUS 里的 Seconds_Behind_Source 是否真实归零。
