必须执行 RESET SLAVE ALL 清空残留元数据，再用 CHANGE REPLICATION SOURCE TO 明确指定 SOURCE_AUTO_POSITION=1 或 SOURCE_LOG_FILE+SOURCE_LOG_POS，且主从 GTID 配置须严格一致，否则 START SLAVE 报“Could not initialize master info structure”。
能平滑加，但必须清空旧复制状态、校验GTID、控制binlog保留窗口——跳过任何一步都可能卡在 START SLAVE 报错。
新从库启动失败：Could not initialize master info structure
这是最常卡住的地方：MySQL尝试复用残留的复制元数据（比如 5.7 的 master.info 文件或 8.0+ 的系统表），但里面记录的 binlog 位置或 GTID 集已失效。
- 执行
RESET SLAVE ALL（注意是ALL），它会清掉所有中继日志、复制状态和元数据存储 - 再执行
CHANGE REPLICATION SOURCE TO（5.7 是CHANGE MASTER TO），明确指定参数 - 不要依赖 mysqld 启动时自动读取旧配置——哪怕你刚初始化完空实例，也可能残留 systemd 或 docker 初始化脚本写入的无效配置
SOURCE_AUTO_POSITION = 1 和手动指定 SOURCE_LOG_FILE 的取舍
本质是让 MySQL 自己找起点，还是你来指定起点。选错会导致复制跳事务或直接报 GTID conflict。
- 用
SOURCE_AUTO_POSITION = 1：要求主库未 purge 过所需 binlog，且新节点@@GLOBAL.GTID_EXECUTED必须为空（或与 dump 记录一致）；适合全新空白节点 - 用
SOURCE_LOG_FILE+SOURCE_LOG_POS：绕过 GTID，走传统文件偏移；适合主库 binlog 已被清理，或你想从某个已知备份点（如mysqldump --master-data=2输出的CHANGE MASTER TO）开始追 - 严禁混用：
SOURCE_AUTO_POSITION = 1时再传SOURCE_LOG_FILE会被忽略，但参数冲突可能引发不可预期行为
mysqldump 全量导入后，为什么复制一启就跳事务？
因为普通 mysqldump 不保证导出时刻的 GTID 集与实际数据快照对齐，尤其当主库持续写入时。
- 必须加
--single-transaction --master-data=2：前者保证一致性快照，后者在 dump 开头插入带MASTER_LOG_FILE和MASTER_LOG_POS的注释 - 导入后别急着启复制：先运行
SELECT @@GLOBAL.GTID_EXECUTED;，确认结果与 dump 文件里记录的SET @@GLOBAL.GTID_PURGED完全一致 - 更稳妥可选
mydumper（支持并发、压缩、GTID 友好）或mysqlpump（5.7+ 官方替代）
扩容期间主库 binlog 被 purge 导致从库追不上
新增从库同步耗时若超过 binlog_expire_logs_seconds 设置，就会因主库删了旧日志而中断复制。
- 扩容前务必检查主库当前最早 binlog 时间：
SHOW BINARY LOGS;，估算同步完成所需时间 - 临时调大
binlog_expire_logs_seconds，建议比预估扩容时间多留至少 2 小时缓冲 - 同步延迟显示为
NULL时，不是慢，而是 IO 线程根本连不上或找不到日志——优先查SHOW SLAVE STATUS\G中的Seconds_Behind_Master、IO_Running、SQL_Running和Retrieved_Gtid_Set
真正容易被忽略的是：GTID 模式下主从 enforce_gtid_consistency 和 gtid_mode 必须严格一致，哪怕只差一个节点设成 OFF，START SLAVE 就会静默拒绝，错误日志里只有一行模糊提示。
