主从切换后如何恢复原始架构：重建从库数据的方法
主从切换后原主库变从库，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执行历史，然后再重新拉取数据。 - 怎么判断从库是不是“不干净”？看
跳过临时冲突：用 SET GLOBAL gtid_next 还是 sql_sla ve_skip_counter？
数据重建后，偶尔会碰到主键冲突或者数据重复的错误。先别急着跳过，得排查一下是不是从库的旧数据没清理干净导致的。
- 对于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_sla ve_skip_counter这个参数在GTID模式下已经被禁用了。如果强行设置，会直接报ERROR 1790，所以千万别试。- 当然，跳过冲突只是应急手段。真正治本的方法是在重建前就做好检查：用
SELECT COUNT(*) FROM mysql.gtid_executed;确认从库的GTID执行集是否干净。如果有残留，执行RESET MASTER;通常比手动去删表要安全得多。
最后说点经验之谈。重建从库最耗时的环节，往往不是数据dump或者导入，而是GTID集合的校验和relay log的回放。哪怕数据量不大，只要新主库的binlog里堆积了大量的小事务，从库在初始化时就很容易卡在 Waiting for source to send event 这个状态——这通常不是网络问题，而是GTID协议本身在同步时需要付出的开销。所以，在正式操作前，务必在测试环境把整个流程完整走一遍，尤其要验证 SHOW REPLICA STATUS 里那个 Seconds_Behind_Source 的延迟，是不是真实地降到了零。
