server-id必须全局唯一，否则从库拒绝连接或同步中断；主库须启用log-bin、设非默认server-id、binlog-format为ROW；从库配置不同server-id后，执行CHANGE REPLICATION SOURCE TO并START REPLICA，双线程为Yes才正常。
server-id 必须全局唯一，否则从库无法连接主库 —— 这是绝大多数失败案例的第一原因。
主库配置必须启用 log-bin 且 server-id 不为默认值
MySQL 容器默认不开启 binlog，也不设置有效 server-id，直接运行的容器无法作为主库。必须挂载自定义配置文件，并显式启用二进制日志：
-
server-id设为非 1 的整数（如101），同一网络内所有节点不能重复 - 必须包含
log-bin=mysql-bin（路径名可自定义，但推荐保持默认） -
binlog-format建议设为ROW，避免语句级复制在从库出错 - 不要用
skip-networking=1或bind-address=127.0.0.1，否则从库连不上
示例 /docker/mysql/master/conf/my.cnf：
[mysqld] server-id = 101 log-bin = mysql-bin binlog-format = ROW expire_logs_days = 7 max_connections = 500
从库启动前需先获取主库 SHOW MASTER STATUS 输出
从库启动后不能立即执行 CHANGE REPLICATION SOURCE TO —— 因为主库可能还没写入第一个 binlog 文件，或 position 为 0 导致同步失败。
- 先
docker exec -it mysql-master mysql -uroot -p123456进入主库 - 执行
SHOW MASTER STATUS;，记录File（如mysql-bin.000001）和Position（如156） - 确保主库已创建复制用户：
CREATE USER 'repl'@'%' IDENTIFIED BY 'repl123'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES; - 从库容器启动后，再执行
CHANGE REPLICATION SOURCE TO，SOURCE_LOG_FILE和SOURCE_LOG_POS必须严格匹配上一步结果
CHANGE REPLICATION SOURCE TO 参数名在 MySQL 8.0.23+ 已变更
如果你用的是 mysql:8.0.32 或更高版本，旧语法 MASTER_HOST 等已废弃，强行使用会报错 ERROR 1064 (42000)。
- 正确语法（MySQL 8.0.23+）：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='mysql-master', SOURCE_USER='repl', SOURCE_PASSWORD='repl123', SOURCE_PORT=3306, SOURCE_LOG_FILE='mysql-bin.000001', SOURCE_LOG_POS=156; - 旧语法（MySQL 5.7 / 8.0.22-）：
CHANGE MASTER TO MASTER_HOST='mysql-master', ... - 务必确认镜像标签：运行
docker inspect mysql-master | grep Image查看实际版本 - 容器间通信依赖 Docker 网络：主从容器必须在同一个自定义 bridge 网络中，不能只靠
localhost
从库启动后必须手动 START REPLICA，且状态要双 YES
START REPLICA 不会自动执行，也不会在容器重启后自动恢复；REPLICA_IO_RUNNING 和 REPLICA_SQL_RUNNING 都必须为 Yes 才算真正同步。
- 检查命令：
SHOW REPLICA STATUS\G（MySQL 8.0.23+）或SHOW SLAVE STATUS\G（旧版） - 常见卡点：
Seconds_Behind_Master: NULL表示 IO 线程未连上；SQL_Remaining_Delay: NULL可能是 relay log 损坏 - 若出错，先停：
STOP REPLICA;，再查错日志：docker logs mysql-slave 2>&1 | tail -20 - 不要依赖
replica_parallel_workers > 0加速，它在单库小数据量下反而易引发冲突
主库 server-id 和从库 server-id 冲突、binlog 未启用、CHANGE REPLICATION SOURCE TO 语法写错、容器不在同网段——这四点覆盖了 90% 的初始化失败场景。其他问题基本都源于这四个环节的验证缺失。
