必须将备份逻辑嵌入主Pod内部，由mysql-0自行触发校验上传；禁用CronJob，改用前台守护脚本执行xtrabackup --no-lock --safe-slave-backup，并强制命名含cluster-pod-timestamp-binlog位点及.meta元数据文件，失败须告警。
备份必须绑定 Pod 生命周期，不能只靠 CronJob
直接在集群里起个 CronJob 定期执行 mysqldump 或 xtrabackup 是常见误区——它无法感知 StatefulSet 中哪个 Pod 是主节点，更没法保证备份时主库处于可读一致状态。StatefulSet 的 MySQL 集群里，只有 mysql-0（或你定义的首个 Pod）是写入点，其余从节点可能延迟、不可用，甚至正在重建。盲目备份任意 Pod 的数据，大概率得到不一致快照。
正确做法是：把备份逻辑下沉到主节点容器内部，由主 Pod 自己触发、自己校验、自己上传。
- 用
initContainers或主容器启动脚本检测自身是否为主（例如通过hostname匹配mysql-0） - 仅当确认是主节点时，才启动定时备份循环（如用
while true; do ...; sleep 3600; done） - 避免使用
crontab，因其在容器中常因 PID 1 问题失效；改用前台运行的守护进程式脚本
xtrabackup 比 mysqldump 更适合 StatefulSet 场景
mysqldump 是逻辑备份，锁表时间长、恢复慢、不支持增量，且无法处理大库（>50GB）的在线备份需求。而 xtrabackup 是物理备份，能热备 InnoDB 数据，配合 --stream=xbstream 可直接压缩并推送到对象存储（如 S3 兼容接口），不落地本地磁盘，规避 PVC 空间不足风险。
实操要点：
- 备份命令必须加
--no-lock --safe-slave-backup，防止从库 SQL 线程被意外中断 - 主节点备份时要记录 binlog 位点：
xtrabackup --binlog-info输出到/backup/binlog_info，这是后续恢复到指定时间点的关键 - 备份目录需挂载独立 PVC（如
backup-pvc），与数据 PVC 分离，避免 IO 干扰和空间争抢 - 不要用
rsync同步整个/var/lib/mysql目录——InnoDB 文件未刷盘时直接拷贝会损坏
备份文件必须带明确标识，否则恢复时无法定位
StatefulSet 的每个 Pod 有稳定网络名（mysql-0.mysql），但备份文件若只叫 backup.tar.gz，在多集群或多环境共用一个存储桶时极易混淆。恢复时你根本分不清这个备份来自哪个集群、哪个主节点、哪天生成。
强制规范命名格式：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 文件名包含：
cluster-name+pod-name+timestamp+binlog-file-pos - 示例：
prod-mysql-mysql-0-20260930T084500Z-mysql-bin.000042-198733.xbstream - 同时写入一个
.meta文件，记录server_id、gtid_executed、k8s-namespace等上下文，方便自动化恢复脚本解析
别省这一步——线上恢复故障时，没人愿意花 20 分钟手动查日志确认备份有效性。
备份失败必须触发告警，且不能静默跳过
很多备份脚本用 set -e 但没处理非零退出的兜底逻辑，一旦 xtrabackup 因磁盘满、权限错、MySQL 连接超时失败，容器就直接退出，StatefulSet 会自动重启它，形成“失败→重启→再失败”的死循环，而你完全不知情。
必须加入可观测性闭环：
- 每次备份后，用
mysql -e "SELECT @@server_id, @@read_only"校验主库状态，防止误在从库上执行 - 备份完成后立即做一次
xbstream -x解压校验（哪怕只解 header），确认文件未损坏 - 将成功/失败状态写入 Prometheus 指标（如
mysql_backup_status{pod="mysql-0", result="success"}），并配置 AlertManager 告警 - 失败时向 Slack 或企业微信发简短通知，包含 Pod 名、错误行号、最近 5 行日志片段
最危险的不是备份失败，而是你以为它成功了。
