sidecar 备份需挂载共享 pvc、统一用户权限、重试连接 mysql、显式指定带时间戳的备份路径并定期清理旧文件，上传需自行集成工具并校验。
mysqldump 本身不支持 Kubernetes 原生调度，直接在 MySQL Pod 里跑备份脚本会污染主容器、干扰健康检查，还容易因容器重启丢失临时备份文件。Sidecar 是更干净、可复用的解法——但不是所有 Sidecar 都适合备份。
Sidecar 备份必须挂载共享卷
MySQL 主容器和 Sidecar 容器必须能读写同一块持久化存储，否则 mysqldump 生成的 SQL 文件无法被持久保存或后续上传。
- 使用
emptyDir只适用于临时中转（比如 dump → 上传 → 删除），不能替代备份归档 - 推荐用
PersistentVolumeClaim挂载到两个容器的相同路径，例如/backup - MySQL 容器需额外挂载该 PVC 到
/backup（只写权限即可），Sidecar 挂载为读写 - 注意
securityContext：两个容器的runAsUser要一致，或确保 backup 目录对两者可写（如chmod 775 /backup）
Sidecar 容器不能依赖 MySQL 的 readinessProbe
Sidecar 启动后立即执行备份，但此时 MySQL 可能还没就绪——mysqldump 会报错 Can't connect to local MySQL server。
- 不要让 Sidecar 等待 MySQL 的
readinessProbe成功再启动（Kubernetes 不保证容器启动顺序） - 在 Sidecar 启动脚本里加连接重试逻辑，例如：
until mysqladmin ping -h 127.0.0.1 -u root -p"$MYSQL_ROOT_PASSWORD" --silent; do sleep 2; done - 避免用
hostNetwork: true或localhost访问 MySQL；Sidecar 和 MySQL 在同一 Pod，应直连127.0.0.1:3306，但需确认 MySQL 绑定地址是0.0.0.0（而非127.0.0.1）
备份脚本必须处理权限与清理
Sidecar 容器默认以 root 运行，但 MySQL 镜像（如官方 mysql:8.0）通常以非 root 用户（uid 999）启动 mysqld，mysqldump 输出文件可能因权限问题无法被上传或压缩。
- Sidecar 的
securityContext.runAsUser应设为和 MySQL 容器一致（查镜像文档或用kubectl exec -it mysql-0 -- id确认） - 备份命令建议显式指定输出路径并加时间戳：
mysqldump -h 127.0.0.1 -u root -p"$MYSQL_ROOT_PASSWORD" "$MYSQL_DATABASE" > /backup/mysql-$TIMESTAMP.sql - 定期清理旧备份：Sidecar 启动时执行
find /backup -name "mysql-*.sql" -mtime +7 -delete，避免 PVC 满 - 不要在脚本里用
sleep 3600长驻；备份完成后应退出（Kubernetes 会重启容器），或改用 CronJob 控制频率
Sidecar 不等于自动上传，上传逻辑要自己写
很多教程只做到 dump 出 SQL 文件，却没解决“如何传到远端存储”。Sidecar 本身不提供上传能力，必须集成对应工具。
- 若上传到 S3：Sidecar 镜像需预装
aws-cli，并挂载含AWS_ACCESS_KEY_ID的 Secret - 若上传到 NFS 或 MinIO：用
rsync或mc（MinIO Client），注意网络策略是否放行目标端口 - 上传失败不能静默忽略：脚本末尾加校验，例如
if [ ! -s "/backup/mysql-$TIMESTAMP.sql" ]; then exit 1; fi - 上传成功后建议生成校验码：
sha256sum /backup/mysql-$TIMESTAMP.sql > /backup/mysql-$TIMESTAMP.sql.sha256
备份不是“dump 一次就完事”，Sidecar 模式真正价值在于隔离职责、复用镜像、统一日志采集——但每一步都要亲手验证路径、权限、网络和退出逻辑。最容易被跳过的，是 mysqldump 与 MySQL 实例之间那几秒的竞态，以及 PVC 上残留的零字节文件。
