mysql如何在Docker Compose中编排主从集群_编写yaml脚本自动化-mysql教程-PHP中文网

MySQL主从集群在Docker Compose中需用不同service定义并显式配置：主库启用log-bin和唯一server-id，从库配置独立server-id、read_only，并通过CHANGE REPLICATION SOURCE TO动态获取主库binlog位点；须挂载分离的配置与数据卷，repl用户授权'%'且禁用bind-address=127.0.0.1，初始化逻辑应封装于entrypoint脚本而非硬编码。

mysql如何在docker compose中编排主从集群_编写yaml脚本自动化

MySQL主从集群在Docker Compose中必须用不同`service`定义，不能靠单个镜像启动多个容器自动组从

主从不是MySQL自己“发现并连接”的，得靠显式配置：主库开log-bin、从库配CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或CHANGE MASTER TO（旧版）。Docker Compose只是起容器，不替你执行SQL命令。

常见错误是只写两个mysql服务但没初始化脚本，结果容器起来后主没开binlog、从没执行change命令——状态永远是Slave_IO_Running: No。

主库容器必须挂载my.cnf，启用server-id=1和log-bin=mysql-bin
从库容器同样要挂载独立my.cnf，设server-id=2（不能和主重复），且read_only=ON（可选但推荐）
从库首次启动前，必须拿到主库的SHOW MASTER STATUS输出（File + Position），再用它执行CHANGE REPLICATION SOURCE TO
这个SQL不能手敲——要用command或健康检查后自动执行，否则每次docker-compose up都得人工连进去配

用`command`覆盖默认启动命令，在从库容器里自动完成CHANGE和START REPLICA

Docker Compose的command字段能替换MySQL镜像默认的mysqld启动方式。利用这点，可以让从库容器先等主库就绪，再连上去取binlog位置，最后执行复制配置。

但注意：command里不能直接写多行SQL；得包装成shell脚本或用mysql客户端串行调用。更稳的方式是把初始化逻辑放进entrypoint脚本里，挂载进容器。

主库不需要特殊command，只要确保mysqld正常启动并加载了含log-bin的配置
从库的command建议设为["sh", "-c", "sleep 10 && mysql -h mysql-master -u root -prootpass -e \"CHANGE REPLICATION SOURCE TO SOURCE_HOST='mysql-master', SOURCE_USER='repl', SOURCE_PASSWORD='replpass', SOURCE_LOG_FILE='mysql-bin.000001', SOURCE_LOG_POS=157; START REPLICA;\""]
上面硬编码了SOURCE_LOG_FILE和SOURCE_LOG_POS——实际不可靠。正确做法是让从库先查主库的SHOW MASTER STATUS，再拼出CHANGE语句，这必须用自定义entrypoint.sh
MySQL 8.0.31+支持replica_parallel_workers > 0，但Docker环境下若网络延迟高，反而容易出现Retrieval failed错误，建议初试保持默认0

主从用户权限和网络连通性最容易被忽略：`repl`账号必须允许从从库IP登录

Docker Compose默认为每个service分配独立IP，但它们同属一个用户定义bridge网络，互相可用服务名通信。问题在于：主库的repl账号如果只授权'repl'@'localhost'，从库根本连不上。

docker-container-rerun-all

顺序检查并可选更新所有已在长期记忆中记录了固定重建命令的 docker run 容器。使用场景：用户...

下载

典型报错是ERROR 2003 (HY000): Can't connect to MySQL server on 'mysql-master' (111) 或更隐蔽的 ERROR 1045 (28000): Access denied for user 'repl'@'172.20.0.3'（IP是Docker分配的从库地址）。

主库初始化SQL中必须创建CREATE USER 'repl'@'%' IDENTIFIED BY 'replpass';，再GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
确认主库my.cnf里没有bind-address = 127.0.0.1——这会拒绝所有外部连接，包括同网络的从库
用docker-compose exec mysql-slave ping mysql-master验证DNS解析和基础连通性，再试mysql -h mysql-master -u repl -preplpass -e "SELECT 1"
从库的CHANGE REPLICATION SOURCE TO里SOURCE_HOST必须填主库服务名（如mysql-master），不是localhost或127.0.0.1

数据卷和配置挂载路径必须区分主从，否则重启后binlog位置丢失或配置覆盖

两个MySQL容器如果共用同一份volume或挂载同一目录，会导致主库的mysql-bin.000001被从库读写冲突，或者从库误用主库的auto.cnf（含server-uuid），引发复制中断。

更隐蔽的问题是：Docker Compose的restart: always策略下，若没做持久化，容器重建后主库binlog重置、从库relay-log丢失，SHOW REPLICA STATUS显示Seconds_Behind_Master: NULL且IO线程停止。

主库volumes应映射到宿主机./mysql-master/data:/var/lib/mysql，从库对应./mysql-slave/data:/var/lib/mysql
配置文件也需分开：./mysql-master/my.cnf:/etc/mysql/my.cnf:ro 和 ./mysql-slave/my.cnf:/etc/mysql/my.cnf:ro
my.cnf里务必包含server-id、log-bin（主）、relay-log（从）、read_only（从）等关键项，不要依赖镜像默认值
第一次启动后，立刻进主库执行SHOW MASTER STATUS记下初始Position，写进从库初始化脚本——别指望每次都是157