如何使用mysqldump初始化MySQL主从复制

必须停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被重复执行，主从数据错位。

1. 若从库已报错（如Slave_SQL_Running: No），先确认错误是否已解决，再决定是否需要重新初始化
2. dump前务必检查主库SHOW MASTER STATUS;，记录当前File和Position，这是后续CHANGE REPLICATION SOURCE TO的基准点
3. 不要在业务高峰期执行，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

注意点：

1. --set-gtid-purged=OFF必须显式指定，否则MySQL 5.7+默认为AUTO，可能在GTID模式下报错ERROR 1840 (HY000)
2. --master-data=1会生成可执行的CHANGE MASTER TO语句，=2则生成注释，更安全（避免误执行）
3. 如果导出全库，用--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。

所以导入前必须临时关闭：

1. SET GLOBAL super_read_only = OFF;（优先关这个，它覆盖read_only）
2. SET GLOBAL read_only = OFF;（如果super_read_only没开，就关这个）
3. 导入完成、启动复制前，再按原配置设回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线程已停——这步是为「对齐数据起点」。

但这只是临时状态。真正要恢复复制，必须：

1. 先STOP SLAVE;（或STOP REPLICA;），否则CHANGE REPLICATION SOURCE FILTER等命令会失败
2. 清理旧的过滤规则，比如删掉REPLICATE_IGNORE_TABLE=ttdb.t1，否则该表永远不同步
3. 再START SLAVE;，让SQL线程从刚才停住的位置继续执行后续事件

最容易忽略的是：UNTIL停住后，SHOW SLAVE STATUSG里的Seconds_Behind_Master可能显示NULL或0，但Slave_SQL_Running是No——这不是异常，是预期状态；你得主动STOP再START，它才会真正“接上”。