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中必须用不同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'，从库根本连不上。
典型报错是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
主从同步本身不难，难的是让Docker Compose里的两个容器在无干预下稳定建立连接、正确识别binlog起点、且每次重启都不丢状态。关键点不在yaml写得多漂亮，而在my.cnf隔离、repl账号授权范围、以及从库初始化脚本是否真能动态获取主库当前位点。
