导出时必须同时使用--single-transaction和--master-data=2，前者确保innodb一致性快照，后者在dump头部写入准确binlog坐标；从库需配置唯一server-id、read_only=1，并用dump文件中的坐标执行change master to，而非show master status；gtid模式下须加master_auto_position=1且mysqldump指定--set-gtid-purged=off；启动复制后须检查seconds_behind_master和slave_sql_running_state，并确保relay-log路径对mysql用户可写。
导出时必须加 --single-transaction 和 --master-data=2
这两个参数缺一不可，否则从库启动后大概率报错 Got fatal error 1236 或同步中断。其中：--single-transaction 保证 InnoDB 表在导出过程中获得一致性快照（不锁表），而 --master-data=2 会在 dump 文件头部写入注释形式的 binlog 坐标，例如：-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=45678;。这个坐标是后续 CHANGE MASTER TO 的起点，不能靠 SHOW MASTER STATUS 临时查——因为导出期间主库可能已推进 binlog。
导入前必须确认从库 server-id 唯一且 read_only=1
从库配置文件（my.cnf）里必须设置：server-id 不能和主库或其他从库重复；read_only=1 是硬性防护，防止应用误连从库写入数据导致主从不一致。注意：read_only 对 SUPER 权限用户无效，所以复制账号不能用 root，必须用专设的 repl 用户（仅授 REPLICATION SLAVE 权限）。
- 重启 MySQL 才能使新配置生效，别跳过这步
- 如果从库已存在旧数据，先清空再导入，否则可能主键冲突或触发唯一索引报错
CHANGE MASTER TO 必须用 dump 文件里的坐标，不是当前 SHOW MASTER STATUS
很多人在导入后执行 CHANGE MASTER TO 时，习惯性去主库执行 SHOW MASTER STATUS 拿最新坐标，这是错的。因为 dump 文件记录的是“导出那一刻”的 binlog 位置，从库必须从那个点开始追，才能和 dump 数据严丝合缝对上。正确做法是：
- 用
head -n 50 backup.sql | grep "CHANGE MASTER"提取 dump 文件开头的那行注释 - 把提取出的
MASTER_LOG_FILE和MASTER_LOG_POS值，填进CHANGE MASTER TO语句 - 如果主库启用了 GTID，需额外加
MASTER_AUTO_POSITION=1，并确保--set-gtid-purged=OFF已在 mysqldump 中指定（否则导入会失败）
启动复制后立刻检查 Seconds_Behind_Master 和 Slave_SQL_Running_State
START SLAVE 不等于复制就通了。真正要盯的是 SHOW SLAVE STATUS\G 输出里的两个字段：
-
Seconds_Behind_Master：应逐步归零，长期 >0 说明有延迟或卡住 -
Slave_SQL_Running_State：正常应为Slave has read all relay log; waiting for more updates；若显示Reading event from the relay log且不动，大概率 SQL 线程报错（比如主键冲突、缺失表），此时要看Last_SQL_Error
最容易被忽略的是 relay log 写权限问题：从库的 relay-log 路径（默认在 datadir 下）必须被 mysql 用户可写，否则 I/O 线程能连上主库，但写不了中继日志，Slave_IO_Running 会显示 No，错误日志里出现 Failed to open the relay log。
