必须停slave，但应只停sql线程以保证数据一致性并避免relay log堆积；mysqldump需配合--single-transaction和--master-data=2，导入前须关闭super_read_only和read_only。
mysqldump初始化主从前必须停slave吗
必须停，但不是无差别停整个复制。关键在于避免dump过程中从库SQL线程继续执行 relay log，导致数据不一致。
推荐只停SQL线程：STOP SLAVE SQL_THREAD;（MySQL 5.7）或 STOP REPLICA SQL_THREAD;（MySQL 8.0.22+）。这样IO线程仍可接收主库binlog，后续追平更快。
常见错误是直接STOP SLAVE;后长时间不恢复，导致relay log堆积、延迟飙升；更糟的是dump中途未停SQL线程，INSERT/UPDATE被重复执行，主从数据错位。
- 若从库已报错（如
Slave_SQL_Running: No），先确认错误是否已解决，再决定是否需要重新初始化 - dump前务必检查主库
SHOW MASTER STATUS;，记录当前File和Position，这是后续CHANGE REPLICATION SOURCE TO的基准点 - 不要在业务高峰期执行，
FLUSH TABLES WITH READ LOCK虽短暂，但会阻塞DML
mysqldump导出时--single-transaction和--master-data=2怎么配
--single-transaction保证InnoDB表一致性快照，但它**不能替代锁表**，也不适用于MyISAM表；--master-data=2则把CHANGE MASTER TO语句以注释形式写入dump文件——这两者要一起用，且顺序无关，但缺一不可。
典型命令：mysqldump -uroot -p --single-transaction --master-data=2 --set-gtid-purged=OFF ttdb t1 > /tmp/t1.sql
注意点：
-
--set-gtid-purged=OFF必须显式指定，否则MySQL 5.7+默认为AUTO，可能在GTID模式下报错ERROR 1840 (HY000) -
--master-data=1会生成可执行的CHANGE MASTER TO语句，=2则生成注释，更安全（避免误执行） - 如果导出全库，用
--all-databases；导出单库加-B（即--databases），否则库名不会出现在CREATE DATABASE语句中
导入dump文件前为什么必须关read_only和super_read_only
从库通常启用了read_only=ON或super_read_only=ON，这是防止误操作的保护机制，但也会直接拒绝source或mysql -e "source ..."这类写操作，报错ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement。
所以导入前必须临时关闭：
-
SET GLOBAL super_read_only = OFF;（优先关这个，它覆盖read_only） -
SET GLOBAL read_only = OFF;（如果super_read_only没开，就关这个） - 导入完成、启动复制前，再按原配置设回
ON，否则从库可能被应用层写入，破坏主从关系
别漏掉SET max_execution_time=0;——大表导入容易超时，尤其在有max_execution_time限制的环境里，否则INSERT中途被kill，数据残缺。
start slave until指定POS后为什么还要stop再start
用START SLAVE UNTIL MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;是为了让SQL线程执行到dump时刻对应的binlog位置，停在那个点上。此时IO线程仍在运行，relay log持续增长，但SQL线程已停——这步是为「对齐数据起点」。
但这只是临时状态。真正要恢复复制，必须：
- 先
STOP SLAVE;（或STOP REPLICA;），否则CHANGE REPLICATION SOURCE FILTER等命令会失败 - 清理旧的过滤规则，比如删掉
REPLICATE_IGNORE_TABLE=ttdb.t1，否则该表永远不同步 - 再
START SLAVE;，让SQL线程从刚才停住的位置继续执行后续事件
最容易忽略的是：UNTIL停住后，SHOW SLAVE STATUS\G里的Seconds_Behind_Master可能显示NULL或0，但Slave_SQL_Running是No——这不是异常，是预期状态；你得主动STOP再START，它才会真正“接上”。
