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% 的初始化失败场景。其他问题基本都源于这四个环节的验证缺失。











