server-id必须全局唯一、GTID模式主从必须一致、CHANGE MASTER TO的host必须用服务名而非IP；三者未对齐会导致主从同步卡在Connecting状态或报ERROR 1794，占线上故障80%。
server-id 必须全局唯一，否则主从同步会卡在 Connecting 状态 —— 这是 Docker 环境下最常踩的坑，不是密码错、不是网络通不通，而是两个容器用了同一个 server-id。
docker-compose 启动时必须隔离 network 和 volume
MySQL 主从通信依赖容器间 DNS 解析和稳定网络，不能靠 localhost 或宿主机 IP：
- docker network create mysql-net 是必需前置动作
- 主从容器必须共用该网络，且 services.master.networks 与 services.slave.networks 都指向它
- volumes 不能复用同一目录：主库 master-data 和从库 slave-data 必须分离，否则启动时会因数据文件冲突直接退出
- 不要用 -v /host/path:/var/lib/mysql 直接挂载，Docker 卷（named volume）更可靠，尤其在重启后权限和 inode 一致性上
my.cnf 配置里 gtid-mode=ON 要主从一致
MySQL 8.0 默认启用 GTID，但若主从配置不统一，START SLAVE 会报错 ERROR 1794 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has GTID_MODE = OFF：
- 主库 master.cnf 必须含：[mysqld]server-id = 1log-bin = mysql-bingtid-mode = ONenforce-gtid-consistency = ON
- 从库 slave.cnf 同样要写这两行，server-id 改为 2（或其它唯一值）
- 切勿只在主库开 GTID、从库留默认，MySQL 8.0 不允许这种混合模式
CHANGE MASTER TO 的 host 必须用服务名，不是 IP
在 docker-compose.yml 定义的服务名（如 mysql-master）才是容器内可解析的 hostname：
- 错误写法：MASTER_HOST='172.18.0.2'（宿主机或动态分配 IP，重启即变）
- 正确写法：MASTER_HOST='mysql-master'（Docker 内置 DNS 自动解析）
- 执行命令时，必须进从库容器执行：docker exec -it mysql-slave mysql -uroot -p$PASS -e "CHANGE MASTER TO ..."
- MASTER_LOG_FILE 和 MASTER_LOG_POS 来自 SHOW MASTER STATUS 输出，注意复制前主库不能有写入，否则位置偏移
server-id 冲突、GTID 模式不匹配、host 写死 IP —— 这三个点占了线上主从连不上问题的 80%。别急着查日志，先确认这三项是否干净对齐。
