主从切换后如何恢复原始架构：重建从库数据的方法

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

主从切换后原主库变从库，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 SLA VE;（旧版本），把线程停掉，然后再去调整复制源配置。
• 如果切换时没记下新主库的 source_log_file 和 source_log_pos，千万别凭感觉猜。老老实实去新主库跑一遍 SHOW MASTER STATUS;，把输出的信息抄下来再用。
• 这里有个版本差异带来的坑：MySQL 8.0.26+ 默认开启了 replica_parallel_type = LOGICAL_CLOCK。如果原主库是旧版本，或者配置没对齐，启动复制时很可能卡在 Retrieved_Gtid_Set 不同步上。稳妥起见，切换前最好统一关闭相关配置，并把GTID状态清理干净。

重建从库数据：用 mysqldump 还是 mysqlpump？

数据重建不是“一个工具走天下”的活儿，选错了方法，轻则锁表影响业务，重则引发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
• 怎么判断从库是不是“不干净”？看 SHOW REPLICA STATUS\G 的输出。如果 Retrieved_Gtid_Set 是空的，但 Executed_Gtid_Set 却有值，这通常意味着从库自己本地执行过事务（比如误操作写了数据）。这时候，得先执行 RESET MASTER; 清空本地的GTID执行历史，然后再重新拉取数据。