它们没有被删，只是被dRop tAbLE命令从数据库里抹掉了表结构，数据本身还以二进制日志的形式存在于服务器磁盘上。

他开始写恢复脚本。

脚本的逻辑分三步：先根据全量备份加上增量备份恢复到下午两点整的完整状态，再从binlog里提取两点到两点五十八分之间的所有增量数据，最后把这两段数据拼在一起，写入一张临时重建的user表。

写脚本的时候手指在键盘上敲得飞快，老周在旁边看着他写，递了杯热水过来，他接过来喝了一口，眼睛没离开屏幕。

脚本写完之后先在测试环境跑了一遍。

全量恢复耗时四十分钟，跟预估的完全一致。

增量数据回灌跑得很快，六十万条记录在binlog解析后批量写入，不到十分钟就跑完了。

他检查了一遍数据完整性——四万三千个新用户基本全部恢复，密码修改记录一条不少，手机绑定更新的时间戳全部连续，没有断点。

测试环境通过。

下午四点二十三分，生产环境开始正式恢复。

全量备份从凌晨三点的时间点开始回滚，屏幕上进度条一格一格地往前走，每前进一格代表一个数据文件的恢复完成。

老周站在他旁边，两个人都没怎么说话。

机房里只有硬盘读写指示灯在疯狂闪烁，闪成一片琥珀色的光海。

四点五十三分，全量恢复完成。

五点零二分，两点之前的增量备份回灌完成。

他深吸一口气，把下午两点到两点五十八分之间的增量数据恢复脚本推上了生产环境。

屏幕上开始滚动写入日志——INSERt语句一条接一条地刷过去，速度快得看不清具体内容。

五点十二分，六十万条增量数据全部回灌完成。

他打开user表的记录数校验查询，对比了凌晨三点加上全量备份恢复后的记录数，加上两点之前增量恢复的记录数，再加上下午两点到两点五十八分的binlog提取记录数。

三个数字加起来，跟dRop tAbLE之前最后一秒的记录总数完全一致。

五点十五分他给老周和主任各发了一条消息：数据全部恢复，零丢失。

然后靠在椅背上，感觉后背的衬衫被冷汗浸湿了一片，贴在皮肤上又凉又黏。

老周长长地出了一口气，说这次能恢复得这么快，binlog完整是关键。

林泠点了点头，脑子里还在回想刚才恢复过程中的每一个步骤。

全量备份加增量备份加binlog恢复，这个链路他之前在设计数据迁移方案的时候就反复推演过，但真正在生产环境上跑一次全流程紧急恢复，还是第一次。

他想起自己在大暑那天在白马河做窗口期复盘直播时说过的话——数据库排查逻辑和鱼情分析逻辑本质上是同一套思维模型：划定时间窗口，定位异常变量，追踪因果链路。

今天这次删库恢复，本质上也是一次窗口期内的紧急排查——划出数据丢失的时间窗口，定位dRop tAbLE的精确时间点，追踪从全量备份到增量备份到binlog的完整恢复链路。

逻辑完全一样，只是压力不一样。

他站起来活动了一下僵硬的脖子，走到机房外面。

走廊里的温度比机房里高了至少十度，暖暖的空气裹住他冰凉的胳膊，反而让他打了个哆嗦。
本章未完，请翻下一页继续阅读.........