Docker Compose部署MySQL主从时Slave_IO_Running: No的主因是认证插件不一致、网络不可达、server-id/GTID配置错误或初始化时机不当；需统一mysql_native_password插件、确保同网段服务名互通、主从server-id不同且GTID全启用、从库延迟执行START REPLICA。
docker compose up 能跑起来主从，但默认配置下 99% 会卡在 Slave_IO_Running: No 或 Slave_SQL_Running: No —— 根本原因不是命令没执行，而是 GTID、用户权限、网络连通性或初始化时机没对齐。
确认 MySQL 8 默认认证插件是否一致
MySQL 8 默认用 caching_sha2_password，但主从同步脚本（尤其是 CHANGE MASTER TO）常依赖 mysql_native_password 认证方式。不统一会导致从库连不上主库，报错类似：ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded。
- 必须在
docker-compose.yml的command中显式指定：--default-authentication-plugin=mysql_native_password - 主库和从库都要加，不能只加一边
- 如果已启动过容器，改完需先
docker compose down -v清数据卷再重试，否则旧用户仍用旧插件
server-id 和 GTID 配置必须严格区分主从
server-id 是主从识别的唯一依据，GTID 模式下还要求 gtid_mode=ON 和 enforce-gtid-consistency=ON 同时开启 —— 少一个就无法建立复制通道。
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 主库
server-id必须是整数且 ≠ 从库（如主设100，从设101） - 主库配置中必须含：
log-bin=ON、log-slave-updates=ON（从库也要写入 binlog 才能级联） - 从库配置里不能漏掉
read_only=ON（防误写），否则后续业务写入会破坏一致性 - GTID 模式下，
CHANGE MASTER TO必须带MASTER_AUTO_POSITION = 1，不能手动填MASTER_LOG_FILE和MASTER_LOG_POS
初始化脚本执行时机与权限问题
主库的 master.sh 和从库的 slave.sh 都放在 /docker-entrypoint-initdb.d/ 下，但它们的执行顺序和上下文不同：主库脚本在首次初始化时运行；从库脚本虽然也执行，但此时 MySQL 还没连上主库，START SLAVE 会失败。
- 主库脚本只需创建复制用户（
REPLICATION SLAVE权限）和业务用户，例如：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'repl123'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
START SLAVE，应改用健康检查 + 延迟执行（如用 wait-for-it.sh 等待主库就绪后再运行 CHANGE MASTER TO + START SLAVE）chmod +x master.sh slave.sh，否则 Docker 启动时静默跳过docker-compose.yml 中 volume 和 network 的常见陷阱
主从容器必须在同一个自定义网络才能通过服务名互通（如主库容器名 mysql_master，从库才能用 mysql_master:3306 连接），但 volume 映射路径若重复或权限不对，会导致 MySQL 启动失败或数据丢失。
- 主从
volumes的数据目录必须分开（如./master/data:/var/lib/mysqlvs./slave/data:/var/lib/mysql），共用会覆盖 - 配置文件映射推荐用完整路径（如
./master/conf.d:/etc/mysql/conf.d），避免my.cnf被镜像内置配置覆盖 - network 必须显式定义为
driver: bridge并声明ipam（尤其在多网卡环境），否则 DNS 解析可能不稳定 - 别用
localhost或127.0.0.1在从库脚本里连主库——容器内这是它自己，不是主库
GTID 模式下，SHOW SLAVE STATUS\G 里 Retrieved_Gtid_Set 和 Executed_Gtid_Set 不一致，或者 Seconds_Behind_Master 持续增长，往往不是配置遗漏，而是从库初始化时没清空 GTID_EXECUTED（比如复用旧数据卷）。每次调试前，先确认 docker compose down -v 是不是真删掉了 volume。
