那个晚上，我们差点丢了所有数据

凌晨两点的电话

2024年10月28日凌晨2点17分，我被电话吵醒。是值班的同事打来的。

"明哥，数据库出问题了。主库磁盘满了，从库同步失败，备份也查不到。"

我瞬间清醒了。数据库主库磁盘满，这意味着什么？写操作会失败，应用会报错，用户会受影响。更严重的是，如果处理不当，可能会丢数据。

我立刻从床上爬起来，打开电脑，连上VPN，开始排查。

第一反应：清理空间

主库磁盘满了，第一反应是清理空间。我连上服务器，看了一下磁盘使用情况：98% 满了。

我赶紧找可以删除的文件：日志文件、临时文件、旧的备份文件。删了一些，但空间还是不够。

这时候，我意识到一个问题：数据库的 binlog 文件可能占了很多空间。我检查了一下，果然，binlog 文件有 200GB。

但是，binlog 文件不能随便删。如果删了，从库就无法同步了。而且，如果主库挂了，我们需要 binlog 来恢复数据。

我犹豫了一下，决定先不删 binlog，而是想办法扩容。但现在是凌晨，运维同事不在，扩容需要时间。

从库同步失败

更严重的问题是，从库同步失败了。我检查了一下从库的状态，发现从库的 relay log 也满了。

从库同步失败，意味着如果主库挂了，我们无法切换到从库。而且，从库的数据可能已经落后主库很多了。

我赶紧检查了一下从库的延迟：已经延迟了 3 个小时。这意味着从库的数据是 3 个小时前的。

如果主库现在挂了，我们会丢失 3 个小时的数据。这太严重了。

备份也出了问题

最让我担心的是，备份也出了问题。我检查了一下备份系统，发现最近的备份是 6 个小时前的。

而且，备份文件的大小不对。正常的备份文件应该有 50GB，但最近的备份文件只有 10GB。这说明备份可能失败了。

我检查了一下备份日志，发现备份脚本在 6 个小时前就报错了，但没有人注意到。

这时候，我开始慌了。主库磁盘满，从库同步失败，备份也失败了。如果主库现在挂了，我们可能会丢失所有数据。

紧急处理

我立刻联系了运维同事，让他帮忙扩容。同时，我开始清理 binlog 文件。

我知道删除 binlog 有风险，但现在已经没有其他办法了。我先删除了 7 天前的 binlog 文件，释放了 100GB 空间。

然后，我检查了一下从库的状态，发现从库的 relay log 也满了。我清理了一下 relay log，但同步还是失败了。

我重新启动了从库的同步进程，但同步还是失败。我检查了一下错误日志，发现从库无法连接到主库。

我检查了一下主库的状态，发现主库的 MySQL 进程还在运行，但响应很慢。我怀疑是磁盘 IO 满了。

最危险的时刻

凌晨 3 点 30 分，主库的 MySQL 进程突然挂了。我立刻检查了一下，发现 MySQL 进程因为磁盘空间不足而崩溃了。

这时候，我意识到问题的严重性。主库挂了，从库同步失败，备份也失败了。如果数据恢复不了，我们可能会丢失所有数据。

我立刻联系了 DBA 同事，让他帮忙恢复数据。同时，我开始检查是否有其他备份。

幸运的是，我发现了一个 12 个小时前的备份文件，这个备份文件是完整的。虽然数据是 12 个小时前的，但总比没有好。

我立刻开始恢复数据。但恢复数据需要时间，而且需要确保主库有足够的空间。

数据恢复

凌晨 4 点，运维同事帮忙扩容了主库的磁盘。我立刻开始恢复数据。

恢复数据的过程很慢，因为数据量很大。我一边恢复数据，一边检查从库的状态。

凌晨 5 点，数据恢复完成了。我检查了一下数据，发现数据是完整的。我松了一口气。

然后，我重新启动了从库的同步进程。同步开始了，但速度很慢。我检查了一下，发现从库的延迟还是很大。

我决定先不管从库，先把主库稳定下来。我检查了一下主库的状态，发现主库已经恢复正常了。

后续处理

早上 6 点，主库已经恢复正常了。我开始处理从库的问题。

从库的同步还是失败，我决定重新搭建从库。我备份了主库的数据，然后在从库上恢复。

这个过程花了 2 个小时。早上 8 点，从库也恢复正常了。

然后，我检查了一下备份系统，发现备份脚本有问题。我修复了备份脚本，并设置了告警。

复盘

这次事故，我们差点丢了所有数据。虽然最后数据恢复了，但这个过程让我意识到，我们的备份和监控系统还有很多问题。

问题总结：

• 磁盘空间监控不足：主库磁盘满了，但没有人提前发现
• 备份系统有问题：备份脚本报错了，但没有人注意到
• 从库同步监控不足：从库同步失败了，但没有人及时发现
• 应急处理流程不完善：出现问题后，处理流程不够清晰

改进措施：

• 加强监控：设置磁盘空间、备份状态、从库同步状态的告警
• 定期检查备份：每天检查备份文件，确保备份正常
• 完善应急处理流程：制定详细的应急处理流程，并定期演练
• 增加备份频率：从每天一次备份，改为每 6 小时一次备份

教训

这次事故让我明白了一个道理：数据是公司最重要的资产，备份和监控不能有任何疏忽。

不要等到出问题了才想起备份。备份应该是日常工作的重点，而不是可有可无的。

监控系统也不能只是摆设。告警要及时，处理要迅速。如果告警不及时，监控系统就没有意义了。

最后，应急处理流程要完善。出现问题后，要能快速定位问题，快速处理问题。如果处理流程不清晰，可能会浪费宝贵的时间。

那个晚上，我们差点丢了所有数据。但幸运的是，我们最后把数据救回来了。这次经历让我更加重视备份和监控，也让我更加谨慎地处理每一个问题。