备份文件为空需检查权限、连接参数及数据库状态；加--verbose和--log-error捕获真实错误；验证用户权限、直连有效性；混合引擎库慎用--single-transaction；可用性须校验解析、还原与数据一致。
备份脚本执行成功但文件为空怎么办
常见现象是 mysqldump 命令返回 0，日志显示“completed”，但生成的 .sql 文件只有几 KB，甚至为空。根本原因通常是权限、连接参数或数据库状态异常，而非脚本逻辑问题。
- 检查
mysqldump是否被静默中断：在命令末尾加--verbose --log-error=/tmp/mysqldump.err，捕获真实报错 - 确认用户权限：执行
SHOW GRANTS FOR 'backup_user'@'localhost';，必须含SELECT、LOCK TABLES、RELOAD（若用--single-transaction可省LOCK TABLES） - 验证连接有效性：用相同账号密码直连
mysql -u backup_user -p -h 127.0.0.1 -P 3306 -e "SELECT 1;"，排除 socket vs TCP 混用导致的认证失败 - 注意
--single-transaction在非 InnoDB 表上不生效，混合引擎库需搭配--lock-all-tables，否则可能漏数据
如何判断一次备份是否真正可用
只校验文件大小或时间戳毫无意义。真正可用 = 能解析 + 能还原 + 数据一致。自动化中必须做轻量级验证。
- 用
head -n 50 backup_20240501.sql | grep -q "CREATE TABLE"粗筛结构头是否完整 - 抽样还原关键表：创建临时库
mysql -e "CREATE DATABASE tmp_restore;"，再导入单张小表mysql tmp_restore - 对比行数：备份前执行
SELECT COUNT(*) FROM orders;记下值，还原后查临时库同表，误差超过 1% 就触发告警 - 避免全量
mysqlcheck --check，太重；改用zcat backup.sql.gz | grep -m 1 "INSERT INTO" | wc -l确认有实际数据块
监控脚本该检查哪些关键指标
监控不是只看“有没有跑”，而是盯住质量衰减信号。以下 4 项必须写进检查逻辑：
-
find /backup/mysql/ -name "*.sql.gz" -mmin -120—— 确认最近 2 小时内有新文件（根据你的调度周期调整） -
gzip -t /backup/mysql/backup_$(date +%Y%m%d).sql.gz &>/dev/null && echo ok || echo broken—— 强制解压校验压缩完整性 -
stat -c "%s" /backup/mysql/backup_$(date +%Y%m%d).sql.gz对比过去 7 天均值，下降超 30% 则预警（可能表被 truncate 或导出参数漏库） - 检查
mysql -e "SHOW SLAVE STATUS\G" | grep -E "(Seconds_Behind_Master|Slave_IO_Running|Slave_SQL_Running)"—— 主从延迟过大时，备份可能跨事务不一致，此时应跳过或标记为“非一致性备份”
用什么方式发告警最可靠
邮件容易进垃圾箱，企业微信/钉钉机器人又依赖网络和 token 有效期。生产环境建议分层通知：
- 一级（立刻响应）：写入本地告警文件
/var/log/mysql-backup-alert.log，配合logrotate和inotifywait实时触发脚本，避免通知通道故障导致失联 - 二级（人工确认）：用
curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx推送，但必须包裹timeout 10并检查 HTTP 状态码，失败则 fallback 到短信网关（如阿里云 SMS API） - 三级（兜底）：在备份脚本末尾加
echo "$(date): OK" >> /backup/mysql/last_success.log，监控程序每 5 分钟读这个文件时间戳，超 3 小时未更新就强制告警
最容易被忽略的是备份锁等待时间——如果 mysqldump --lock-tables 卡在 Waiting for table flush 状态超过 30 秒，说明业务有长事务，此时备份已不可靠，但默认不会报错。得在脚本里用 mysqladmin debug 抓 processlist 做前置检测。
