Lakebase Postgres branch-based restores for fast recovery at scale

Lakebase Postgres 基于分支的恢复实现大规模快速恢复 | Databricks 博客

跳至主要内容

Lakebase

2026年10月1日

Lakebase Postgres 基于分支的恢复实现大规模快速恢复

Lakebase Postgres 如何通过基于分支的恢复替代传统缓慢的数据库恢复方式，实现秒级恢复100 TB数据。

作者：Cassie Murray 和 Carlota Soto

摘要

• 传统数据库恢复过程非常缓慢，且随着数据规模的增大扩展性较差，通常需要数小时的停机时间来部署新计算资源、下载大型快照并重放日志文件。

• Lakebase Postgres 引入基于分支的恢复，这是一种元数据操作，通过指向解耦存储中的不可变历史记录来实现数据库的即时恢复，而非复制数据。

• 恢复100 TB数据库仅需数秒，使恢复几乎瞬间完成，并使AI代理能够无缝处理分支和撤销工作流。

展开

在托管OLTP系统中，恢复操作一直非常缓慢，且规模越大越慢。这通常意味着停机成本最高的大型生产数据库需要等待最长时间才能恢复。

常见的变通方法复杂、昂贵且风险高。它们涉及额外的副本、额外的环境，甚至需要数据库管理员参与恢复，但并不能完全保证保护。故障转移到健康副本可以在机器宕机时提供帮助，但当坏写入已经存在于备用节点时，这种方法就无能为力。这仍然意味着需要恢复，而恢复可能意味着数小时的停机时间。

这种痛苦源于传统托管OLTP系统的架构。计算和存储捆绑在一起作为单一机器，恢复操作需要先部署新实例（你已经等待了）；快照存储在对象存储中，而Postgres运行在该卷上，因此快照仍需拉取到磁盘（更多等待）；然后WAL重放需要填补从快照时间到精确恢复时间戳之间的差距（甚至更多等待）。随着数据库增长，这一过程会变得越来越慢且成本越来越高。

Lakebase Postgres 架构打破了这种单体结构并改变了恢复机制。在Lakebase中，计算和存储是解耦的，数据库历史记录以可即时引用的方式存储在对象存储中。在这种架构下，恢复操作不会将数据复制到新磁盘，而是通过在特定时间戳创建分支来实现，这只是一个简单的元数据操作，而非耗时数小时的复制和重放任务。

实际上，即使数据库达到100 TB规模，恢复时间也缩短至数秒。而且，这一过程如此简单，以至于代理可以自动完成。

传统OLTP恢复路径（及其失效点）

传统Postgres的基于时间点的恢复（PITR）由两个要素构建：文件的基础备份和该备份之后所有归档的WAL日志。在托管Postgres环境（如Amazon RDS）中，这种备份通常是一个存储在对象存储中的快照。

“从备份恢复”到特定时间点T实际上是一个包含三个步骤的过程：

• 部署新实例

• 恢复T之前最新的可用快照

• 从该快照重放WAL日志到时间点T

1. 部署新实例

这需要运输至少与主实例相同规模的计算和存储卷（耦合式）。小型实例可能几分钟内就能启动，但带有大型EBS卷的大型实例通常需要更长时间，导致在恢复过程开始前就需要等待更久。

2. 从快照恢复

RDS 快照存储在 S3 中，因此“恢复”意味着将快照从对象存储中取出并写入 Postgres 的磁盘。

这个过程在数据量较大时会很慢，因此 RDS 不会等待恢复过程完成才使实例可用。对于大容量数据，实例在大多数表和索引页面仍存储在 S3 时就已经可用。但“可用”并不表示工作集已经加载到 Postgres 的磁盘上。如果查询访问了尚未本地化的数据块，磁盘会从 S3 实时获取该数据块，而其他数据则在后台继续从 S3 恢复。

这类查询的延迟对于内部检查可以接受，但不适合生产环境。只有当实际需要的数据已经存在于磁盘上时，恢复过程才算完成，而对大型数据库来说，这个过程耗时较长。数据库越大，所需时间（以小时为单位）越多。

3. 重放 WAL 到时间点 T

快照仅保证在快照时间点的一致性。要达到时间点 T，Postgres 仍需重放快照之后归档的事务日志。重放所需时间取决于快照与 T 之间发生的数据量。一小时前的快照重放速度远快于昨晚的快照。此外，如果当天写入操作密集，需要重放的 WAL 数据量会非常庞大。这再次意味着需要等待较长时间（叠加在实例仍从 S3 恢复的背景过程中）。

显著的停机时间窗口

除非数据库规模很小，否则 PITR 几乎总是需要数小时才能完成。你需要先部署单体实例，从 S3 拉取快照，重放 WAL，并等待足够多的数据本地化后才能接受流量。

在整个窗口期间，你可能会经历停机。如果主数据库故障且高可用（HA）副本仍拥有良好数据，健康的 HA 副本可以挽救你。但 PITR 可能无法挽救你，因为副本可能已经包含了被删除的表或错误写入的数据。

慢速数据库恢复令人痛苦

在一项调查中，50 名运行 1TB+ 生产级 Postgres 的开发人员被询问了他们的恢复体验：

• 59% 的人过去 12 个月经历过关键生产故障
• 30% 的人停机时间超过 3 小时，部分甚至超过半天
• 仅有 21% 的人能在 60 分钟内恢复

这造成了潜在的业务负面影响：

• 40% 的人报告了重大业务中断
• 52% 的人因事件遭遇负面客户反馈
• 72% 的人表示“仅有些信心”能在故障再次发生时快速恢复

基于分支的恢复引入了新路径

在 Lakebase Postgres 中，现代架构为恢复提供了不同的路径。

计算与存储分离

计算层与持久化存储分离，通过 WAL 进行连接。计算层运行 Postgres，即执行 SQL、查询规划、应用 MVCC、管理锁以及生成 WAL（所有常规 Postgres 任务）。但它不拥有你的数据持久化副本。

存储层负责数据的持久性和历史记录，其工作被划分为三个部分，由三个独立组件执行：

• Safekeepers 接收来自计算层的 WAL。当多数 Safekeeper 确认接收 WAL 记录时，事务才被视为持久化
• Pageserver 将 WAL 转换为 Postgres 可读取的页面。它可以为给定键在特定 LSN 重建任意页面
• 对象存储保留不可变的长期历史记录。计算层从不直接读取它；pageserver 位于两者之间

当写入发生时：

• Postgres 在内存中修改行并生成 WAL
• 计算层将该 WAL 流式传输到 Safekeepers

• 法定人数确认后，事务变得持久

• 之后，页面服务器将这些 WAL 转换为页面版本

• 这些版本以不可变的历史形式存储在对象存储中

历史以可寻址的时间线形式存储

在此设计中，写入路径呈现出有趣的特性。上述架构将事务提交与页面生成过程分离，简单来说意味着：旧页面版本永远不会被覆盖。您的数据库历史会堆积成一条您可以定位的时间线，而不是一个您需要修改的单一副本。

Lakebase 中的恢复是时间线上的一个分支

在传统路径中，恢复通常意味着将过去状态重建到一个独立实例中。但 Lakebase 提供了可引用的存储历史，因此这一步变得多余，取而代之的是一个不同的原语：分支。

传统恢复需要创建新实例并复制数据，而 Lakebase 中的恢复是时间线上的一个分支。这个新分支拥有独立的计算资源、自己的连接字符串，并且可以完全独立于生产环境进行查询。它不是原始实例的副本，但使用起来却感觉完全一样。

使用这个原语进行恢复的方法如下：

• 当主分支出现故障时，您选择一个过去的时刻（在执行恢复之前，您甚至可以检查这个时刻，例如通过运行查询）

• 一旦验证通过，控制平面会将该时间戳映射到存储历史中的确切位置（正确的 LSN），创建该分支并附加计算资源

• "恢复后的数据库"就是这个新分支，您只需点击"部署"，它几乎立即可用，与底层数据库存储的数据量无关

由于这是关键概念，让我们再次强调：

分支不会复制数据库

这种恢复方法完全消除了数据复制。恢复后的分支不需要复制数据，它只需指向到该时间点为止已经存在的镜像层和增量层。

• 在复制和重放系统中，恢复是一个数据移动任务。数据库直到复制和 WAL 重放完成才会"存在"

• 在 Lakebase 中，"数据库"已经存在。恢复只是元数据：指向历史中某一点的指针。剩下的只是将该点暴露为一个带有独立计算的分支

结果：恢复 100TB 数据的速度与恢复 10GB 一样快

这种设计的优势在于，扩展性不再带来操作上的恐惧。如果恢复只是元数据操作，那么恢复所需时间不会随着数据量增长而增加，机制始终保持一致。

无论数据库大小如何：

• 达到一个可寻址的过去状态几乎是即时的

• 验证该状态所需时间仅取决于检查和您选择读取的数据量

即使在巨大的 Postgres 数据库上，人类或代理在发生事故后也能立即访问一个可查询的过去状态。

代理可以基于恢复构建功能

Lakebase 中的恢复是一个简单的操作：在某个时间戳创建一个分支。这个过程足够简短，代理可以将其视为普通工具调用，而不仅仅是用于解决事故。

这就是 Replit 或 v0 等代理平台实际产品化的部分，用于构建版本控制或撤销功能。一个典型的循环如下：

• 代理修改应用，这会改变数据库

• 平台将主分支保存为一个快照，并将检查点 ID 存储在代码版本旁边

• 用户点击撤销，或在用户界面中选择一个较旧的版本

• 平台查找该检查点并将其恢复到主分支

• 模式和数据会立即回退到与“旧代码”匹配的数据库版本

传统 PITR 速度太慢且资源消耗太大，无法支持实时工作流程，但基于时间戳的分支速度快且成本低到可以作为产品的一部分。

Lakebase 的架构改变了恢复的面貌

传统恢复方式随着数据库增长会变得越来越慢且资源消耗更大，而基于分支的恢复方式则不受影响。历史数据已经独立于计算资源存在，因此过去的某个时间点可以作为一个分支打开，而不是需要重新构建的内容。无论您拥有 10 GB 还是 100 TB 数据，恢复操作看起来都是一样的。选择一个时间戳，创建分支并附加计算资源。大规模故障不再令人望而生畏。

亲自体验一下：创建一个 Lakebase Postgres 数据库，加载大量数据，执行一次恢复操作，然后惊叹于自己竟然这么久没有这个功能。

订阅以获取最新文章

订阅我们的博客，将最新文章直接发送到您的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"