数据库出事后能不能快速救回来，取决于恢复体系建在哪一层。这一讲拆解数据恢复的三代演进：备份恢复、日志重放、副本切换，以及千万 QPS 下分片级自动重建的工程设计。
凌晨两点，一家电商公司的 DBA 被告警吵醒：订单库主节点宕机。更糟的是，值班同学在切换流程里发现，最近一次全量备份的校验和不对，这个备份集大概率是坏的。团队只能退而求其次，用两天前的全量备份加上 binlog 重放追数据，整个过程花了一个半小时。复盘时有人算了笔账：这一个半小时里，每分钟的直接交易损失是平时晚高峰的三倍。
故事还有另一个版本。同样是主节点宕机，另一家公司的系统在三十秒内完成了副本接管，业务几乎无感。这两家公司的差距不在运气，而在数据恢复架构走到了哪一步。前者还停留在「定期备份，出事再恢复」的阶段，后者已经把恢复做成了系统运行时的一部分。
这一讲要讨论的就是这条演进路径：数据恢复是怎么从「翻备份」一步步走到「实时」的，每一代方案解决了什么问题，又付出了什么代价。
数据恢复到底在恢复什么
先理清两个绕不开的概念：RPO 和 RTO。
RPO（Recovery Point Objective，恢复点目标）回答的是「最多丢多少数据」，用时间衡量。如果 RPO 是一小时，意味着最坏情况下会丢最近一小时写入的数据。RTO（Recovery Time Objective，恢复时间目标）回答的是「业务要中断多久」，从故障发生到服务重新可用。
RPO 描述数据的完整度，RTO 描述服务的可用性，两者互相独立：恢复得快不代表丢得少，丢得少也不代表恢复得快。
一个常见的误区是把两者混为一谈。全量备份每天一次，出事时先恢复备份再重放日志，这个方案 RPO 可以做到接近零（只要日志都在），但 RTO 可能是小时级，因为恢复数据本身要很久。反过来，主从切换 RTO 是秒级，但如果主从之间有复制延迟，切换瞬间就可能丢掉还没同步的写入，RPO 不为零。
用一组具体数字感受一下：一次误删表事故，如果只有每天凌晨的全量备份，RPO 是最多 24 小时的数据，RTO 取决于恢复速度，可能是 4 到 12 小时。如果备份加日志归档齐全，RPO 能压到分钟级，但 RTO 还是被恢复速度卡住。如果有实时副本，RTO 是秒级，RPO 取决于复制延迟。每往下走一层，付出的架构成本都是真金白银，所以选型的前提是先定目标，而不是盲目追高。
不同业务对这两个数字的容忍度完全不同。内部报表系统可以接受天级 RPO、小时级 RTO；支付核心链路则要求 RPO 为零、RTO 分钟级甚至秒级。架构师要做的第一件事，就是给每类数据定出明确的 RPO/RTO 目标，然后再去选方案。没有目标的恢复方案，要么过度设计，要么形同虚设。
规模会直接改变这两个数字的代价。百万 QPS 的系统，一秒钟大约是一百万次读写；千万 QPS 的系统，RTO 每多一秒，受影响的请求就多一千万次，而且其中相当一部分是已经排队、无法重放的用户请求。所以在千万 QPS 的语境下，恢复不再是故障处理的收尾动作，而是决定故障等级的核心变量。
备份恢复：经典，但慢
最直接的数据恢复方式是从备份恢复。最常见的组合是全量备份加增量备份：每天或每周做一次全量，中间做增量，出事后先恢复最近的全量，再叠加增量，最后重放日志追到故障点。
这套方案的问题在于恢复速度。全量备份的恢复本质上是一个大数据量的顺序写入过程，瓶颈在存储 IO。一个经验数字：普通 SSD 上，数据库恢复速度大约在每小时几百 GB 的量级，而且越接近恢复完成，建索引、校验数据完整性的开销越明显。一个 10TB 的实例，单纯把数据灌回去就可能要一天以上。
这个流程每一步都是串行的，因为每一步都依赖上一步的结果。串行意味着耗时不可压缩，这就是备份恢复 RTO 偏高的根本原因。
除了慢，备份方案还有一个更隐蔽的风险：备份集本身可能不可用。备份文件损坏、备份时数据本身就有一致性问题、备份存储和主存储同机房同灾域，这些情况在真实事故里反复出现。所以业界有一条朴素的规矩：没有验证过可恢复的备份，等于没有备份。 备份集必须定期做真实恢复演练，并且备份本身要跨可用区甚至跨地域存多份。
那为什么大家还离不开备份？因为备份解决的是副本机制解决不了的问题：逻辑错误。有人误删了一张表，这个删除操作会被忠实地复制到所有副本上，副本越多传播越快。这时候唯一能救命的是某个时间点之前的数据快照，也就是备份。这是备份体系在实时复制时代依然存在的原因。
日志重放：恢复到任意一秒
纯备份恢复的粒度太粗，全量备份之间的数据靠什么补？靠日志。
数据库的每一次写入都会先落日志（redo log、binlog、WAL，各家叫法不同）。日志有两个关键性质：追加写入，写入快；包含数据变更的完整信息，可以重放。把这两个性质组合起来，就得到了 PITR（Point-in-Time Recovery，按时间点恢复）：用一个较早的全量备份做基底，把从备份时刻到目标时刻之间的所有日志重放一遍，数据就恢复到了目标时刻。
PITR 把 RPO 从「备份间隔」缩小到「日志延迟」。只要日志是连续、完整、已落盘的，理论上可以恢复到故障前的任意一秒。这也是为什么成熟数据库都把「日志实时归档」当成基础设施级别的要求：日志流断了，PITR 就断了。
但 PITR 没有解决 RTO 问题。重放日志的速度取决于写入吞吐，一天产生的日志可能要重放几个小时。所以 PITR 的标准用法不是用来救主链路，而是两类场景：一是恢复出故障前某一时刻的数据做比对和抢救（比如把误删的表从历史时间点捞出来）；二是在有备库顶替服务的架构里，在备库上慢慢重放，把主链路的中断时间压到只取决于「备库能不能顶上」。
日志方案还有一个工程细节值得注意：日志链必须完整。中间任何一段日志丢失，重放就会卡住，恢复目标会从「任意时刻」退化成「丢失点之前」。所以日志归档本身也要有多副本和完整性校验，它的可靠性要求其实和数据本身一样高。
副本切换：把恢复挪到平时
PITR 证明了「数据可以随时重建」，但重建速度仍然是分钟到小时级。要把 RTO 压到秒级，思路得换：不要等故障发生后再恢复，而是让一份「几乎实时」的数据副本一直存在。这就是副本（replica）机制。
主节点把写入日志实时发给从节点，从节点持续应用。理想状态下，从节点的数据和主节点只落后毫秒级的日志量。主节点故障时，把流量切到从节点，RTO 就是探测故障加切换的时间，通常在秒级。
这个方案看起来把恢复问题彻底解决了，但它有两个必须讲清楚的边界。
第一，复制延迟就是 RPO。从节点永远落后主节点一点日志，主节点整机损毁时，这一段没同步的写入就是丢失量。要做到 RPO 为零，需要主节点在确认写入前等待至少一个从节点确认收到日志（半同步或多主共识），代价是每一次写入都多一次网络往返，延迟和吞吐都会受影响。千万 QPS 的系统通常不会全量开启强同步，而是在核心链路的少数关键数据上开，其余数据接受毫秒级丢失的可能性。
第二，副本防不了逻辑错误。副本机制复制的是「变更」，误删表、错误的批量更新，这些变更同样会被复制。所以健康的架构里，副本和备份各管一半：副本保可用性，备份加 PITR 保数据正确性。
还有一个更贴近千万 QPS 现实的问题：副本切换只解决了「单个节点故障」。集群有几千个分片，每个分片都要有副本，都要能自动切换，恢复就从一次性的应急操作变成了持续运行的系统能力。下一节讨论的就是这个能力的工程形态。
千万 QPS 的重建：从单机操作到分布式系统能力
先说清楚场景。千万 QPS 的数据层通常是几千个分片、每分片多副本的形态。单分片故障（一台机器挂了、一块盘坏了）是常态事件，平均每天都会有。这时候需要的不是人来执行恢复流程，而是系统自动把缺失的副本补回来，并且补的过程不能影响在线流量。这就是副本重建（rebuild）。
重建的标准流程一般包含五个环节：检测副本缺失、克隆快照基线、追增量日志、数据校验、注册为新副本。
先从健康副本（或存储快照）克隆一份基线数据，然后接入日志流追赶增量，追平后做数据校验，最后注册进副本组开始对外服务。这个流程和 PITR 的「基线加日志」是同构的，区别在于它是分布式的、自动的、持续发生的。
千万 QPS 下，重建有三个单机时代不存在的新问题。
重建风暴。 一台宿主机上往往跑着几十个分片副本，它挂掉意味着几十个分片同时要重建。如果几十个重建任务同时从健康副本拉全量数据，源节点的带宽和 IO 会被打爆，在线请求一起被拖垮。所以重建必须有限流和调度：按分片优先级排队，限制单机重建并发数，把重建流量和业务流量隔离（独立网卡、独立 IO 队列，或直接在存储层走快照克隆而不是网络拷贝）。
重建速度赶不上故障速度。 如果补齐一个副本需要六小时，而这六小时里另一个副本又挂了，数据就有真实的丢失风险。所以重建速度是一个硬指标，工程上的做法包括：用存储层快照代替全量网络拷贝（秒级克隆一个 TB 级基线）、只传输有差异的数据块、重建过程多线程并行。目标通常是把单分片重建时间压到分钟级，让「重建未完成时第二故障」变成一个低概率事件。
重建期间的正确性。 新副本追日志的过程中，数据是半成品，绝不能对外提供读服务。只有校验通过、追平到实时日志点之后，才能加入服务。校验手段包括：逐分片的 checksum 比对、行数比对、抽样逐行比对。checksum 一致是加入副本组的硬性门槛。
把这三点合起来看，千万 QPS 系统里的数据恢复，本质是把恢复做成一个有调度、有限流、有校验的后台分布式任务。故障发生时，已经没有人在跑应急脚本了。
恢复的验证：别信「恢复成功」四个字
恢复流程跑完，日志显示成功，不代表数据真的可用。真实的事故里有不少这样的案例：备份恢复完成、校验也通过了，切流量过去才发现某个二级索引是空的，或者某张表的数据停在了一个意想不到的时间点。
恢复验证至少要做三层。
第一层是完整性校验：行数、各分片 checksum、关键表的边界值（最大 ID、最后更新时间）。这一层可以在恢复流程内部自动完成，成本很低，能拦住大部分「恢复了一半」的问题。
第二层是业务一致性校验：用业务视角的查询抽查关键数据，比如最近十分钟的订单是否能查到、状态流转是否正常。这一层需要和业务方一起定义检查项，通常是恢复演练的一部分。
第三层是流量验证：先切一小部分只读流量过去，观察错误率和延迟，再逐步放量。这一步的前提是架构支持灰度切换，对数据层来说就是读写分离加影子流量。
验证的常态化形态是演练。成熟的团队会把恢复演练当变更管理的一部分：每季度至少一次真实备份的恢复演练，每月一次副本切换演练，每次演练记录实际的 RPO/RTO 数字，和设定目标对比。恢复能力是靠演练长出来的，没有演练数据支撑的 RTO 目标，只是期望值。
备份设计为恢复服务
最后把视角拉回备份这一侧。恢复方案演进到今天，备份的定位也变了：它不再是「每天跑个任务存一份」，而是恢复体系里的一个组件，要按恢复的需求来设计。
几个具体的设计点：
备份频率跟着 RPO 走。核心链路要求分钟级 RPO，那日志归档必须是实时的，全量备份的作用退化成「提供重放基线」，频率可以放宽到每周，因为中间都靠日志补。
备份格式要为恢复速度优化。支持按需恢复单个分片或单张表，而不是每次必须全量恢复；支持并行恢复，把数据切成可独立恢复的块。备份集的物理布局直接决定了恢复时的并行度。
备份集自身要有容灾能力。多副本、跨可用区、定期验证可恢复。备份存储的故障不应该和数据中心的故障同时发生，否则备份形同虚设。
把十万 QPS 到百万 QPS 再到千万 QPS 三个阶段放在一起看，数据恢复的演进路线是清晰的：
这张表的重点是变化方向：恢复的执行主体从人变成系统，恢复的粒度从整个数据库收缩到分片，恢复的时机从故障后前移到故障前，副本和快照时刻在位。从备份到实时，备份并没有被抛弃，只是恢复从一个低频的应急动作，变成了系统每时每刻都在运行的常规机制。
把恢复时间写进设计参数
回到开头那个凌晨两点的故事。两家公司技术栈差不多，数据量也接近，结局不同的原因只有一个：一家把数据恢复当成故障发生后才开始的流程，另一家把恢复做成了架构的一部分。
对千万 QPS 的系统来说，这个差别会被规模放大到无法忽视。RTO 多一分钟，损失的不是一分钟的吞吐，而是排队效应下被放大的用户体验和资损。所以数据层架构评审里，RPO/RTO 应该作为和设计评审里的延迟、吞吐同级的硬指标，并且有对应的演练数据支撑。
如果你们的系统现在还处于「有备份，但没演练过恢复」的阶段，不用急着上多活架构。第一步很简单：挑一个真实备份，完整恢复一次，测出真实的 RTO。这个数字往往会改变团队对恢复优先级的判断。你们的数据层，上一次真实恢复演练是什么时候？也欢迎来 云栈社区 分享你们的恢复演练数据。
发表于 1 小时前
|
查看: 5|
回复: 0
