首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >[MYSQL] 备份失败,但是啥日志信息都没有

[MYSQL] 备份失败,但是啥日志信息都没有

原创
作者头像
大大刺猬
发布2025-07-15 14:26:48
发布2025-07-15 14:26:48
1050
举报
文章被收录于专栏:大大刺猬大大刺猬

导读

一次mysqldump备份失败的分析思路分享, 虽然没能完全确认原因(一点日志都没得....), 但思路还是值得分享的.

备份逻辑为(已脱敏):

代码语言:txt
复制
# 判断mysqld进程是否存在
if [ `ps -ef mysqld | wc -l` -ne 3 ];then
	echo "mysqld not exists"
	exit 1
fi

# 清理历史备份
find xxx -mtime +1 -name "*.sql.tar.gz" --exec rm -rf {} \;

# 发起备份
mysqldump --log-error=xxxx.log -A ... > xxx.sql

# 判断备份是否成功
if [ "$(tail -1 xxx.sql | awk '{print $1$2$3}')" == "--Dumpcompleted" ];then
	echo "bakcup success"
else
	echo "backup faild"
fi

分析过程.

某天收到告警提示备份失败. 故先看看日志

查看报错日志

我们备份的时候有指定备份日志路径, 所以一般遇到备份报错直接看日志就行, 之前遇到的慢sql/表结构变化等信息都是通过--log-error指定的日志查看的.

但是, 这次该日志的时间戳还是停留在几个月前, 所以有2种可能:

  1. 备份成功
  2. 未到备份这一步

都已经收到备份告警了, 而且确实未发现当天的备份, 故排除1.

那么就是未到备份这一步了, 这个原因大方向也有2种, 1. 未发起备份 2. 前面检查步骤失败了就退出了

查看备份调度情况

我们先看看备份调度情况, 首先得证明OS已经发起备份调度的.

代码语言:shell
复制
grep mysql /var/log/cron

我们发现了当天的备份调度情况, 说明备份任务是发起了的. 那么就是脚本中某个步骤执行报错然后退出了.

系统邮件

我们配置crontab的时候没有重定向之类的, 所以输出信息是直接发给用户邮件. 可以通过如下信息找到相关输出

代码语言:shell
复制
tail -100 /var/spool/mail/USERNAME

比如:

很遗憾, 实际情况并没有配置邮件. 所有用户的邮件文件都是空的!

这下路几乎就走死了. 脚本未生成任何信息, 输出的任何信息都未记录. 几乎就是个黑匣子了.

缩小备份脚本失败范围

我们还可以分析脚本本身的逻辑. 比如查看下当前还有几份文件, 这样能确认是否在清理逻辑之前就报错了.

比较遗憾的是, 备份失败的并不是今天, 这样保留的备份数量就说明不了啥了. 比较幸运的是, nbu每天都在备份, 这样我们就可以看到历史的备份情况了. 查看备份失败那一天的文件数量, 发现清理逻辑(find xxx -mtime +1 -name "*.sql.tar.gz" --exec rm -rf {} \;)并没有执行. 这说明是前面检查步骤失败了. 更好的消息是前面检查逻辑只有一个变数: mysqld进程数量的判断较为草率!

这里还查看了当天的慢日志信息, 发现慢日志里面不存在相关备份SQL; 而其它备份成功的天,均有备份的慢SQL存在; 这个信息也可以辅助判断 mysqldump 未执行, 但不能作为决定性条件.

由于是通过ps -ef | grep mysqld | wc -l这种方式判断的, 如果当时存在一个 vim mysqldata_import.sh之类的进程都会影响这个逻辑判断, 虽然这是小概率事件, 但本次备份失败就是小概率事件.

虽然影响 mysqld数量判断的命令非常多, 但是备份时间点是凌晨, 人为的可能性就很小, 更大的可能是自动任务,比如监控触发的.

查看zabbix监控进程数量

恰好之前更新了zabbix监控, 增加了mysqld进程数量的监控. 这个监控逻辑有可能就和备份逻辑中检查mysqld数量冲突了.

查看监控发现, 当天备份时间点附近监控的mysqld进程数量数据丢失了; 其它时间点mysqld的进程数量都是1. 这不就巧了吗. (生产环境就是如此巧合)

询问了负责zabbix的同事, 发现zabbix判断进程的逻辑是agent自行处理/proc/pid/comm信息, 也就是不会在os上存在包含mysqld关键字的进程信息; 那么就不会和我们的备份起冲突. 线索就又断了 -_-

总结

本次mysql备份失败是小概率事件, 而且一点日志都没有, 全靠猜. 基本上没有证据证明是谁导致的, 也就没法处理了. 规避的方式很多, 比如备份脚本输出内容到日志, 而不是stdout; 或者配置定时任务的时候加个重定向; 甚至配个邮件都行; 当然判断mysqld进程的方式使用pidof更方便; 直接验证能否登录数据库更好一点. 但遗憾的是都没有,也没法改.

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 导读
  • 分析过程.
    • 查看报错日志
    • 查看备份调度情况
    • 系统邮件
    • 缩小备份脚本失败范围
    • 查看zabbix监控进程数量
  • 总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档