第108章 工作往事（1/2）

请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。

林泠是在周三下午三点零七分接到电话的。

他记得这个时间，因为当时他正盯着屏幕上一个SQL查询的执行计划，想优化掉一个全表扫描。手机在桌上震起来，屏幕上是运维组老周的号码。他接起来，老周的声音语速飞快，说生产环境被人执行了一条删库命令，er表没了。

林泠拿着手机站起来，椅子往后滑出去撞在文件柜上发出一声闷响，旁边的同事小赵抬头看了他一眼。他问什么时候的事。老周说十分钟前，一个离职运维的账号没来得及注销，被人从外部登录进来，只执行了一条命令：DROP TABLE er。干脆利落，没有拖泥带水。林泠已经走出了办公区，边走边问备份呢。老周说最近一次全量备份是凌晨三点，增量备份每小时一次，最近一次是下午两点。

下午三点零七分接到电话，备份在两点。也就是说，从下午两点到三点十分之间写入er表的所有数据——新增注册用户、密码修改、手机绑定、头像更新——全部没了。不是被删了，是随着那张表一起从这个数据库里彻底消失了，像从未存在过一样。

从办公区到机房要经过两段走廊和一个楼梯间。他走过第一段走廊的时候脑子里在快速算两件事：第一，两点到三点十分之间的增量数据量大概有多少；第二，这些数据有没有其他途径能捞回来。走过第二段走廊的时候他大概有了判断：er表平时每小时写入量不大，但今天是周三下午，公司App的推送刚在两点半发了一波促销活动，注册量比平时高了两到三倍。他推开机房的门，冷气从地板续的低频嗡鸣。老周已经蹲在一台服务器前面了，屏幕上的日志窗口还在往下滚。

林泠拉了把椅子坐下来，先确认了三件事。第一，那条DROP TABLE命令的执行时间精确到秒——下午两点五十八分四十三秒，跟他接到电话的时间只差了不到十分钟。第二，全量备份确认完整可用，凌晨三点的备份文件校验和没有损坏。第三，增量备份的日志文件确认到了下午两点整，两点之后的blog还在，没有被删除。

他说先别急着从备份恢复。全量恢复至少需要四十分钟，这四十分钟内所有依赖er表的业务模块都会挂掉。他让老周先把从凌晨三点到下午两点五十八分的全量备份加上增量备份串成一条完整的恢复链路，在测试环境里开始并行跑恢复流程。自己则打开数据库的blog解析工具，把下午两点到两点五十八分之间的所有写入操作提取出来。

六十万条。这是他需要手动恢复的数据量。六十万条写入记录，包括四万三千个新注册用户、一万两千条密码修改记录、八万多条手机号绑定更新、四十多万条头像和昵称的修改。这些数据在blog里都有完整的记录——I、UPDATE、DELETE，每一条都有时间戳，每一条都有完整的字段值。它们没有被删，只是被DROP TABLE命令从数据库里抹掉了表结构，数据本身还以二进制日志的形式存在于服务器磁盘上。

他开始写恢复脚本。脚本的逻辑分三步：先根据全量备份加上增量备份恢复到下午两点整的完整状态，再从blog里提取两点到两点五十八分之间的所有增量数据，最后把这两段数据拼在一起，写入一张临时重建的er表。写脚本的时候手指在键盘上敲得飞快，老周在旁边看着他写，递了杯热水过来，他接过来喝了一口，眼睛没离开屏幕。

脚本写完之后先在测试环境跑了一遍。全量恢复耗时四十分钟，跟预估的完全一致。增量数据回灌跑得很快，六十万条记录在blog解析后批量写入，不到十分钟就跑完了。他检查了一遍数据完整性——四万三千个新用户基本全部恢复，密码修改记录一条不少，手机绑定更新的时间戳全部连续，没有断点。测试环境通过。

本章未完，点击下一页继续阅读。