故障分析 | MySQL 备份文件静默损坏一例分析

最新推荐文章于 2024-09-24 17:25:23 发布

原创

最新推荐文章于 2024-09-24 17:25:23 发布 · 478 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#备份失败 #定时任务

文章描述了一次在升级MySQL到8.0时遇到的备份文件解压失败的问题。作者发现由于crond服务意外启动了两次备份脚本，导致两个进程并发写入同一压缩文件，从而破坏了备份。解决方案包括使用flock添加互斥锁、定期进行备份恢复演练以及监控crond进程确保其正常运行。

作者：付祥

现居珠海，主要负责 Oracle、MySQL、mongoDB 和 Redis 维护工作。

本文来源：原创投稿

*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

背景

线上一套 MySQL 计划升级到 8.0 ，通过备份还原搭建一个测试环境，用于升级测试。数据库采用 xtrabackup 每天进行全备，压缩备份文件约 300G ，解压到一半就报错了：

gzip: stdin: invalid compressed data--format violated
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

刚开始以为只是这个备份文件不完整，又找了前一天备份文件，解压过程中也报了同样的错误，备份文件比较大，无疑增加了排障时间。

故障分析

备份脚本通过 crontab 每天凌晨执行，线上都是同一套备份脚本，不同项目时常做备份数据还原，还是头一次遇到备份文件解压失败现象，查看了脚本，每个关键阶段都做了状态码判断是否成功，若失败就告警，同时对 xtrabackup 备份日志最后一行是否包含 completed OK 关键词也做了判断，关键备份脚本如下：

xtrabackup xxx --stream=tar  --no-timestamp $bkdir 2> xxx.log | gzip - > xxx.tar.gz

近期也没收到失败告警，说明备份脚本是执行成功了的，感觉太奇怪了，查看定时任务日志，发现同一任务同一时间点竟然启了2次：

最低0.47元/天解锁文章