凌晨三点，手机屏幕亮起来，是运维同事发来的消息：“数据库挂了，网站全瘫了。”那语气里透着一种熟悉的绝望。数据库崩溃这事儿，做过几年后台的人基本都撞上过，区别只在于你是提前做了功课，还是事后抓瞎。很多人一听到“崩溃”两个字，脑子里就只剩“恢复备份”这一个选项，但备份恢复往往是无奈之举，时间成本和数据丢失量都让人肉疼。今天咱们就掰开揉碎了聊，真碰上数据库崩了，手头到底有哪些能用的恢复方法，别等火烧眉毛了才想起来翻文档。
先说最基础也最容易被忽略的一招：日志文件分析。绝大多数数据库系统，比如MySQL的binlog、PostgreSQL的WAL，还有Oracle的redo log，平时都在默默记录每一次数据变更。数据库崩溃后，这些日志文件往往还完好无损地躺在磁盘上。你可能会问，日志能干嘛？答案是，它能帮你重建出崩溃前那一刻的数据状态。具体操作上，你得先确认日志文件没有损坏，然后利用数据库自带的工具把日志解析出来，找到崩溃前一条正常事务的位置，然后从这个点往后重放。这招的好处是能把数据损失压缩到几乎为零，缺点是要求你对数据库的事务机制和日志格式相当熟，否则容易在解析过程中把自己绕晕。
第二招，也是实战中最常用的：利用备份文件做时间点恢复。很多公司都有定时备份的习惯，但备份策略各有不同，有全量备份，有增量备份，还有差异备份。如果你手头有最近一次的全量备份，再加上之后所有的增量备份，那你就能把数据库恢复到备份时间点之后、崩溃之前的任意一个时刻。操作流程大致是：先把全量备份恢复到一个干净的实例上，然后按时间顺序依次应用增量备份，把日志里截止到崩溃前的部分也应用进去。这里头有个坑：如果你只恢复了全量备份，而忽略了增量，那数据会回退到上次全量备份的时间点，中间这几天的数据就全没了，等于白忙活一场。
第三个方法，可能很多人没意识到：从从库或灾备节点抢数据。如果你搭了主从复制架构，或者有跨机房的灾备节点，那主库崩溃时，从库上其实还存着一份近乎实时的数据副本。这时候你可以直接将从库提升为主库，业务就能立刻恢复。但有时候从库也会因为复制延迟而缺一部分最新数据，这时候你可以检查从库的relay log，把还没应用完的日志手动补上去。这招的关键在于，你得在平时就确认从库的数据一致性，别等到崩溃了才发现从库早就不同步了。另外，如果你用的是云数据库，很多云厂商默认开启了多副本机制，这种情况下你甚至不需要自己动手，直接触发主备切换就能恢复服务。
第四招，听起来有点“土”，但关键时刻真能救命：扫描磁盘上的临时文件和数据页碎片。数据库在运行时会往磁盘写一些临时文件，比如排序用的临时表空间、undo段里的旧版本数据，还有那些还没来得及清理的已删除行。当数据库崩溃后，这些碎片可能还残留在磁盘上。用专业的恢复工具，比如针对MySQL的Percona Data Recovery Tool，或者针对Oracle的ODU，可以扫描这些散落的文件，把还能读出来的数据页拼接起来。这一招的成功率取决于磁盘有没有被后续写入覆盖，所以一旦发现数据库崩了，第一件事就是停止一切写入操作，把磁盘挂载成只读，然后才敢做扫描。这个方法耗时可能比较长，但当你发现备份也坏了的时候，它就是最后的救命稻草。
第五招，得靠平时的积累了：利用数据库自身的闪回或快照功能。现在不少数据库都内置了闪回查询或者快照隔离的机制，比如Oracle的Flashback Database，PostgreSQL的pg_rewind，还有MySQL的闪回工具。这些功能本质上是在数据库内部保留了一份历史状态的视图，你可以在崩溃后直接查询到过去某个时间点的数据。使用这招的前提是，你得在崩溃前就开启了这个功能，并且设置了合理的保留窗口。如果你平时没开，那这招就无效了。所以，建议你在搭建数据库环境的时候，就把这些功能默认打开，别为了省那点存储空间，真出事的时候才悔不当初。
说到底，数据库崩溃后的恢复方法，本质上是围绕“日志、备份、副本、碎片、快照”这五个关键词展开的。你会发现，每一种方法都不是孤立的，它们之间可以互相配合。比如，你既有备份又有日志，那恢复的完整性就高很多；你既有从库又有快照，那恢复的速度就快很多。最怕的是平时什么都不做，光靠一句“我们有备份”来安慰自己，结果真崩了，才发现备份文件损坏了、日志被清掉了、从库早就断开了。所以，真正的恢复能力，不是等崩溃来了才开始想，而是平时就把这几条路都铺好，每条路都定期演练一遍。数据库崩溃不可怕，可怕的是你连手里的牌都没摸清楚。下次再遇到凌晨三点的电话，你至少能心里有数，先查日志，再看备份，实在不行还有从库和碎片兜底，慌什么。
