数据库磁盘满后自愈了：但数据对不对要验证

发布时间:2026-08-03 12:15

## 症状现象 数据库所在磁盘被写满，写入报错，业务部分失败。运维清理日志与临时文件后空间释放，数据库恢复正常写入，监控曲线回归，一切看似自愈。真正的问题从这里才开始：写满期间被拒绝的那些写入，去哪儿了，业务数据是否完整，不验证就宣布恢复等于埋雷。 ## 定位过程 第一步圈定故障窗口：从监控曲线与错误日志确定磁盘满的起止时间，精确到分钟。第二步盘点窗口内的失败写入：数据库的错误日志记录每条失败的语句与事务；应用侧的任务日志记录哪些业务操作失败，两者时间对齐。第三步区分事务语义：数据库事务要么整体回滚要么未提交，库内一致性由引擎保证；但应用层把库写入与外部动作组合的流程，失败重试到哪一步，只有应用日志能回答。 ``` grep -c "disk full\|no space" /var/log/db/error.log df -h /data ``` ## 解决方法 补数优先：窗口内失败的任务按幂等方式重放，导入导出类操作核对断点，重放完成后再对账。对账的依据是业务侧的计数与状态表：窗口前后各取一次快照，比对差额与重放量是否吻合。对不上的差额逐条追，宁可慢不可漏。 数据库自身的完整性检查也跑一遍：重要表做一致性校验，索引状态确认正常。全部通过后，这次事件才算真正关闭。 ## 预防建议 磁盘水位告警设在八成而非九成五，给处置留时间。日志与临时目录配独立的空间上限，不让它们挤压数据目录。顺云云服务器的磁盘监控告警配合自动通知，写满类事故多数可以提前一个维护窗口拦下。 善后的最后一项是把这次事件的完整记录归档：故障窗口、受影响操作、重放清单、对账结论四段齐全。这份记录在下次容量评审时是现成证据，也是新人培训的最佳案例。磁盘水位告警的阈值与通知渠道，借这次事件复核一遍，往往还有优化空间。