能配，但必须分清主从角色、网络连通性和配置文件生效顺序——主库需挂载my.cnf显式启用log-bin、唯一server-id及row格式；从库须设不同server-id、relay-log、read_only=1，并用服务名而非ip连接主库；change master to参数须严格匹配show master status实时输出，且主从容器必须在同自定义网络。
能配，但必须分清主从角色、网络连通性和配置文件生效顺序——直接照搬docker-compose.yml模板大概率失败。
主库容器必须显式启用 binlog 且 server-id 唯一
MySQL 8.0 默认不开启 binlog，仅靠环境变量无法激活主从能力。必须通过挂载自定义 my.cnf 并在 [mysqld] 段落中明确设置：
-
server-id必须是正整数（如1），同一集群内不可重复 -
log-bin要指定文件名前缀（如mysql-bin），不能只写路径 -
binlog_format强烈建议设为ROW，避免函数/临时表等导致的从库执行失败 - 若同步特定库，用
binlog_do_db = chatdb；若排除系统库，用binlog_ignore_db = mysql,information_schema
从库容器需禁写 + 显式 relay-log + 正确指向主库服务名
从库不是“只读”就够了，Docker 网络下必须用服务名而非 localhost 或 IP：
-
server-id必须与主库不同（如2、3） -
relay-log要设为具体文件名（如mysql-relay-bin），否则启动报错 -
read_only = 1是基础，但更关键的是确保super_read_only = 1（MySQL 8.0+ 默认启用） -
CHANGE MASTER TO MASTER_HOST='mysql-master'中的mysql-master必须和docker-compose.yml中主服务的service名完全一致
初始化复制时最容易卡在权限、日志位点、网络三处
常见失败现象：SHOW SLAVE STATUS\G 中 Seconds_Behind_Master 为 NULL，或 IO_Running/SQL_Running 为 No：
- 主库创建用户时，
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%'的 host 不能写'localhost'—— 从容器访问主容器走的是 Docker 网络，host 是容器名或 IP -
MASTER_LOG_FILE和MASTER_LOG_POS必须来自SHOW MASTER STATUS的**实时输出**，不能抄旧值；且执行CHANGE MASTER TO前主库不能再有写入 - 检查
docker network inspect确认主从容器在同一个自定义网络（如mysql-network），默认bridge网络下容器名解析可能失败
docker-compose.yml 中 command 参数优先级高于配置文件
如果在 command 里写了 --server-id=1，它会覆盖挂载的 my.cnf 中同名配置——但其他参数如 --log-bin 不生效，必须进 my.cnf 写。所以最稳做法是：
- 所有 MySQL 启动参数统一收口到
my.cnf，command留空或仅用于调试（如加--skip-grant-tables） - 挂载配置时确认路径正确：
./master.cnf:/etc/mysql/conf.d/master.cnf，注意 MySQL 8.0 读取/etc/mysql/conf.d/下所有.cnf文件 - 首次启动后，进容器执行
mysql --help | grep "Default options"验证配置是否被加载
真正麻烦的不是写配置，而是每次改完都要删 volume、清数据目录、重启整个 compose 组——server-id 错、log-bin 名字拼错、MASTER_LOG_POS 过期，都会让从库卡死在初始化阶段，且错误日志藏在 SHOW SLAVE STATUS 的 Last_IO_Error 字段里，不主动查就一直黑盒。
