上周三凌晨两点十七分，我被一通电话从梦里拽出来。电话那头是运维同事小张，声音发颤：“订单库主库挂了，从库延迟已经四十分钟，还在涨。”我一边套外套一边问：“备份呢？”“上周日的全备，加上binlog，但是……我们没做过恢复演练。”那一刻我站在玄关，鞋带系了一半，脑子嗡嗡的。这不是我第一次处理数据库故障，但每次听到“没演练过”这四个字，心都凉半截。数据库故障恢复这件事，平时看着像保险条款，真出事的时候，它就是你和公司之间唯一的救命绳。
先说备份策略。很多团队把备份当成例行公事，每天凌晨跑个mysqldump或者xtrabackup，日志看一眼“completed”就归档了。但备份不是用来“有”的，是用来“用”的。我见过最典型的坑：备份文件在，但恢复的时候发现binlog从上周日之后就没同步到异地，或者备份机磁盘满了，三天的备份全是0字节文件。更隐蔽的问题是备份校验——你恢复过这个备份吗？恢复到哪一天？数据一致性怎么验证？这些不演练，全白搭。我现在的习惯是，每周至少做一次全量恢复演练，不是恢复到临时库看一眼行数，而是让业务部门拿测试流量跑一遍核心查询，确认索引、存储过程、定时任务都正常。只有恢复过、验证过、业务确认过的备份，才算有效备份。
接下来是故障分级。不是所有故障都值得大动干戈，但也不是所有故障都能等上班再说。我习惯把故障分成三级：一级是核心库宕机、数据丢失、主从全挂，这种必须立即启动应急预案，哪怕凌晨三点也要把人叫起来；二级是慢查询堆积、连接数打满、从库延迟超过阈值，这种可以观察十五分钟，同时准备切换预案；三级是监控告警但业务无感知，比如某个非核心表的碎片率超标，这种排期处理就行。分级的意义在于，避免过度响应消耗团队精力，也避免延误战机。有一次我们某个从库延迟三十分钟，按二级处理，结果查出来是有人跑了个全表UPDATE忘加WHERE，直接顶到一级——那哥们儿后来被请去喝茶了。
再说说恢复手段的选型。很多人一提到恢复就想到“从备份恢复”，但备份恢复是底牌，不是第一选择。现在的数据库生态里，高可用架构本身就是第一道防线：主从切换、半同步复制、MGR或者Paxos组复制，都是为了让你在故障发生时，先尝试让从库顶上，而不是立刻去翻备份。我见过一个团队，主库宕机后直接启动备份恢复，花了三个小时，业务停摆三个小时，结果事后复盘发现，从库其实只差了十几秒的数据，切换一下两分钟搞定。他们为什么没切？因为怕从库数据不完整，怕切换后丢数据。但你要知道，切换丢数据是有上限的——半同步复制最多丢一个事务，而备份恢复丢的是从上次备份到故障点所有数据。两害相权取其轻，这个账要算清楚。
实战里最考验人的不是技术，是判断。有一次我们遇到主库磁盘满，不是硬件故障，是日志文件把盘撑爆了。当时两个选择：一是清理日志，继续用主库；二是直接切从库。清理日志看似风险小，但万一清理过程中IO飙升，主库直接hang住，连从库都来不及切。我们选了先切从库，再慢慢清理主库日志。这个决策当时有争议，有人觉得小题大做，但事后证明是对的——切完之后主库盘的IOPS确实飙到极限，如果当时在它上面做清理，大概率会把整个集群拖垮。所以故障恢复的核心，不是“把数据弄回来”，而是“在可控范围内把影响降到最低”。宁可多切一次，不要赌一把大的。
还有一个经常被忽略的点：故障恢复之后，业务验证比技术验证更重要。数据库恢复成功了，不等于业务恢复了。你得让业务方去跑一遍核心链路：下单、支付、登录、查询，每个环节都要确认。有一次我们恢复了订单库，技术指标全部正常，但业务反馈首页推荐全空了——因为推荐缓存依赖的某个Redis key没预热，而那个key是从故障前的数据库状态生成的。所以恢复流程里一定要包含“业务冒烟测试”这一步，别急着宣布“恢复完成”，先让业务部门点几个页面再说。
再聊一个反直觉的细节：故障恢复时，日志记录比操作本身更重要。很多人一紧张就手忙脚乱，恢复完了才发现不知道谁执行了什么命令、在哪个时间点做的切换、有没有跳过某个步骤。事后复盘的时候，大家各说各话，根本拼不出完整时间线。我现在的习惯是，故障发生时指定一个人专门记日志，每五分钟记录一次当前状态、执行的操作、影响范围。这个人不参与具体操作，只负责记录和同步信息。听起来浪费一个人力，但事实证明，这些记录在复盘和追责的时候价值连城——它能帮你定位是备份策略失效、是操作失误、还是架构设计缺陷。
说回那个凌晨的电话。后来我们花了六个小时，从备份恢复到凌晨两点的数据，业务影响控制在十分钟以内——因为我们在备份策略里加了binlog实时同步到异地，而且做过三次完整的恢复演练。那次之后，我把“恢复演练”写进了季度OKR，每个季度必须做一次全链路故障模拟，包括主库宕机、从库延迟、备份失效、网络分区，四种场景随机抽。有人说我太较真，但我想说的是：数据库故障恢复，不是靠临场发挥的，是靠日常积累的肌肉记忆。你每一次演练多流的一滴汗，都是故障发生时少流的十滴泪。备份是底线，切换是手段，演练是护身符——这三样齐了，才算真正把数据库故障恢复这件事，从口号变成了能力。
