mysqldump 在容器中执行失败主因是镜像未预装、权限配置错误及网络连接陷阱；需确认存在性、正确挂载卷、使用 socket 连接、限定 backup 用户权限、原子写入备份文件，并在脚本中强制指定 GTID 和字符集。
mysqldump 在容器里直接执行会失败？
容器里没装 mysqldump，或者挂载了宿主机的 /etc/mysql 但权限不对，是第一个拦路虎。官方 MySQL 镜像默认不带 mysqldump（只含 server），而 Alpine 版本更干脆——连 mysql-client 包都没预装。
- 用
docker exec调mysqldump前，先确认容器内是否存在：docker exec mysql-container which mysqldump - 如果不存在，要么换用
mysql:8.0（非 Alpine）镜像，要么进容器手动安装：apt-get update && apt-get install -y mysql-client - 别把
/etc/mysql/conf.d/直接挂载进来——容器启动时会覆盖配置，导致mysqldump连不上本地 socket；改用--defaults-extra-file=/tmp/my.cnf指定凭据文件
备份时连不上 localhost？
在容器里执行 mysqldump -h localhost 会走 TCP，但 MySQL 默认禁用 skip-networking 且 root 不允许从 127.0.0.1 登录——这是最常被忽略的权限陷阱。
- 用
-h 127.0.0.1强制走 TCP 时，必须确保用户有对应 host 权限：CREATE USER 'backup'@'127.0.0.1' IDENTIFIED BY '...'; GRANT SELECT, LOCK TABLES ON *.* TO 'backup'@'127.0.0.1'; - 更稳妥的做法是走 socket：
-h localhost -S /var/run/mysqld/mysqld.sock，前提是容器内 socket 路径和 MySQL 实际监听路径一致（官方镜像是/var/run/mysqld/mysqld.sock） - 避免用
root执行备份脚本——权限过大，出错容易误删；单独建backup用户并限制权限范围
如何让备份文件自动落盘到宿主机？
容器一停，里面生成的 .sql 文件就没了。不能靠 docker cp 事后捞，得在 dump 过程中直接写到挂载卷。
- 启动容器时必须挂载宿主机目录：
-v /backup:/backup:rw，然后在docker exec中指定输出路径为/backup/$(date +\%F_\%H-\%M).sql - 别用重定向
> /backup/file.sql——如果命令中途失败（比如连接超时），会留下空文件，后续校验难识别；改用mysqldump ... -r /backup/file.sql（-r是原子写入，失败不产生文件） - 注意挂载目录权限：MySQL 容器默认以
mysql用户（uid 999）运行，宿主机目录需允许该 uid 写入，否则报Permission denied
crontab + docker exec 自动备份为什么总失效？
宿主机 crontab 调 docker exec 看似简单，但环境变量、路径、shell 解析顺序全都会翻车。
-
PATH在 cron 里极短，找不到docker命令——必须写全路径：/usr/bin/docker exec ... - 日期变量如
$(date +%F)在 crontab 行里会被 shell 提前展开（变成固定字符串），应写成\$\(date +\%F_\%H-\%M\)或改用 shell 脚本封装 - 备份大库时可能超时，
docker exec默认 30 秒信号超时，加-t 0关闭 TTY 限制，或用timeout 3600 docker exec ...控制整体耗时 - 别省略错误检查：dump 后立刻
test -s /backup/*.sql，空文件直接exit 1触发告警，而不是静默覆盖上一次有效备份
真正麻烦的是跨容器网络、字符集导出不一致、GTID 位置记录遗漏这些点——它们不出错则已，一出就是恢复失败。备份脚本里加 --set-gtid-purged=OFF 和 --default-character-set=utf8mb4 不是可选项，是必填项。
