能实现MySQL主从复制，但需手动配置binlog、server-id、GTID及复制用户等；docker-compose up不自动完成握手，必须通过挂载配置、entrypoint脚本和SOURCE_AUTO_POSITION=1协同实现。
能，但“一键”不等于“零配置”。docker-compose up 命令本身不会自动完成主从握手、GTID初始化或复制启动——这些必须靠配置文件、挂载脚本和显式SQL命令协同完成。漏掉任意一环，SHOW REPLICA STATUS 就会卡在 Slave_IO_Running: No。
主库必须启用 binlog 且配置唯一 server-id
MySQL 容器默认不开启二进制日志，主库没 log-bin，从库连上去也拿不到任何事件。同时，server-id 是复制拓扑的唯一标识，主从若相同（比如都为 1），从库启动时会直接报错 ERROR 3005 (HY000): Server ID collision。
-
master/my.cnf至少包含：[mysqld] server-id = 1 log-bin = mysql-bin binlog-format = ROW gtid_mode = ON enforce_gtid_consistency = ON
- 必须挂载到容器内
/etc/mysql/conf.d/下，不能只靠环境变量；MYSQL_ROOT_PASSWORD只控制 root 密码，不影响复制能力 - MySQL 8.0.31+ 默认禁用
log-bin，即使镜像带默认配置，也必须显式覆盖
从库需动态获取主库 GTID 位点，不能硬编码 FILE/POS
很多示例里把 SOURCE_LOG_FILE='mysql-bin.000001' 和 SOURCE_LOG_POS=157 写死在 command 里，这在容器重建后必然失败：主库每次重启，binlog 文件名和初始 position 都可能变，尤其启用了 GTID 后，真正该用的是 SOURCE_AUTO_POSITION = 1。
- 从库
my.cnf必须设server-id = 2（或其它唯一值）、gtid_mode = ON、enforce_gtid_consistency = ON，否则CHANGE REPLICATION SOURCE TO会拒绝执行 - 推荐用自定义
entrypoint.sh而非command：先等待主库就绪（mysqladmin ping -h mysql-master --silent），再执行mysql -h mysql-master -u repl -preplpass -e "SET GLOBAL gtid_purged='...'; CHANGE REPLICATION SOURCE TO SOURCE_HOST='mysql-master', SOURCE_USER='repl', SOURCE_PASSWORD='replpass', SOURCE_AUTO_POSITION = 1; START REPLICA;" -
SOURCE_AUTO_POSITION = 1是 GTID 模式下唯一可靠的方式；手动解析SHOW MASTER STATUS并拼 SQL 属于兜底方案，仅用于调试
复制用户权限与网络连通性必须提前验证
从库容器连不上主库，90% 是因为授权问题或网络隔离。Docker Compose 默认桥接网络中，服务名即 DNS 名（如 mysql-master），但 MySQL 默认绑定 127.0.0.1，导致其他容器无法访问。
- 主库初始化 SQL 中必须创建复制用户，且
HOST不能是localhost，得用'repl'@'%'或'repl'@'mysql-slave1'（后者更安全） - 主库
my.cnf中要注释掉或删除bind-address = 127.0.0.1，否则监听仅限本地，从库mysql -h mysql-master会连接超时 - 用
docker exec -it mysql-slave1 ping mysql-master和telnet mysql-master 3306先确认基础连通性，再查权限：mysql -h mysql-master -u repl -preplpass -e "SELECT 1"
最易被忽略的是 GTID purged 状态：主库首次启动后若未显式设置 gtid_purged（例如通过 mysqldump --set-gtid-purged=ON 导入数据），从库在 START REPLICA 时可能报 Cannot replicate because the master purged required binary logs。这个值必须在从库执行 CHANGE 前同步过去，不是可选步骤。
