使用 Kuberntes 卷快照进行 CloudNativePG 灾备

云原生 PostgreSQL 管理迎来了新时代。CloudNativePG 的 1.21 版引入了对 Kubernetes 卷快照标准 API 的声明式支持，实现了备份和恢复操作中的增量和差异复制功能，从而优化了恢复点目标（RPO）和恢复时间目标（RTO）。

在本文展示的 EKS 基准测试中，与现在的对象存储方案相比，备份及恢复时间大幅缩短，尤其是对于超大型数据库（VLDB），恢复时间甚至缩短了几个数量级。例如，仅用两分钟就从卷快照中完整恢复了一个 4.5TB 的 Postgres 数据库。这仅仅是一个开始，未来正计划在存储层面原生支持 Kubernetes 提供的更多功能。

2020 年 12 月，Kubernetes 1.20 引入了卷快照功能，通过丰富 API，增加了 VolumeSnapshot、VolumeSnapshotContent 和 VolumeSnapshotClass 自定义资源定义。现在，卷快照已融入所有受支持的 Kubernetes 版本，为以下操作提供了通用且标准的接口：

• 从 PVC 创建新卷快照

• 从卷快照创建新卷

• 删除现有快照

实际的实现则委托给底层的 CSI 驱动程序，并且存储类可根据存储特性提供多种功能：如增量块级复制、差异块级复制、在另一区域或多个其他区域的复制等。

其主要优势在于，该接口从应用程序（如 Postgres 工作负载）中抽象出复杂性和存储管理。从数据库的角度来看，卷快照带来的增量和差异备份恢复是最理想的功能。

所有主要云服务提供商都提供了支持卷快照的 CSI 驱动程序和存储类（详细信息请参阅 GKE、EKS 或 AKS）。在本地环境中，您可以使用 Red Hat 的 Openshift 数据基础（ODF）和 LVM、Rancher 的 Longhorn 以及Portworx的 Pure Storage 等。Kubernetes 容器存储接口（CSI）项目的官方文档中列出了可用的驱动程序。

在 1.21 版之前，CloudNativePG 仅支持对象存储的备份和恢复。

在许多场景下，尤其是云环境以及小型/中型数据库（ 500GB 以下）中，对象存储非常便捷。但仍需考虑多个因素。其中之一是备份数据库并存储到对象存储所需的时间。但最重要的是从对象存储中安全恢复备份所需的时间：这一指标代表了特定数据库业务连续性计划中的 RTO。

建议在决策前先测量这两个指标。根据测试和经验，对于一个 45GB 的数据库，备份时间可能在 60 到 100 分钟之间，而恢复时间可能在 30 到 60 分钟之间（实际时间会因底层对象存储技术而有所不同）。随着数据库大小的增加，时间呈线性增长，且在没有增量和/或差异复制的情况下，对于 VLDB 用例来说显然不够。

正因如此，在 CloudNativePG 1.20 中通过 kubectl 的 cnpg 插件引入基于命令式的备份恢复卷快照支持。这能够快速构建该功能的原型，然后进一步丰富其声明式 API。

CloudNativePG 允许对Postgres 集群同时使用对象存储和卷快照策略。尽管包含事务日志的 WAL 归档仍需存储在对象存储中，但物理基本备份（PostgreSQL 数据文件的副本）现在可以作为 tarball 存储在对象存储中，或作为卷快照存储。

WAL 归档对于在线备份和基于时间点的恢复（PITR）是必需的。

CloudNativePG 卷快照的首次实现有一个值得提及的限制：它仅支持冷（物理）备份，即在 DBMS 关闭时获取的数据文件副本。尽管这个限制听起来可能不太理想，但也不必担心；生产集群中通常至少有一个副本，当前的冷备份实现会从备用实例获取完整备份且不影响主操作。这一限制将在 1.22 版中得到解除，开始支持 PostgreSQL 的热物理基础备份低级 API 。

无论如何，冷备份是整个数据库集群在某个时间点的静态一致的物理表示（数据库快照，不要与卷快照混淆），因此足以恢复 Postgres 集群。

例如，如果 RPO 是满足过去一小时的数据需求，那么可以通过每小时进行一次卷快照备份来实现，保留过去七天的数据。

在继续之前，请确保您已知存储类及其相关的卷快照类的名称。由于它们因环境而异，本文将采用通用模式： 

重要提示：本文不会介绍任何特定的存储类或环境。然而，只要确保使用正确的存储类和卷快照类，您就可以将本文中的示例应用于任何环境。

您只需在 PostgreSQL 集群资源的备份部分添加 volumeSnapshot 条目，即可为物理基础备份启用卷快照功能。

假设您要创建一个名为 hendrix、具有两个副本的 Postgres 集群，为 PGDATA 和 WAL 文件分别预留一个 10GB 的卷。假设您已在对象存储上设置了的备份，以归档 WAL 文件（即 barmanObjectStore 部分，在本文中留空，因为它不相关）。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: hendrix
spec:
  instances: 3
  storage:
    storageClass: <MY_STORAGE_CLASS>
    size: 10Gi
  walStorage:
    storageClass: <MY_STORAGE_CLASS>
    size: 10Gi
  backup:
    # 卷快照备份
    volumeSnapshot:
      className: <MY_VOLUMESNAPSHOT_CLASS>
    # 对于 WAL 归档和对象存储备份
    barmanObjectStore: …

您可以直接创建备份资源，但这里建议是：

• 使用 ScheduledBackup 对象来组织 Postgres 集群的卷快照备份，按日或按小时进行，或

• 使用 kubectl 的 cnpg 插件的 backup -m volumeSnapshot 命令来为您创建按需的备份资源。

在此，我们使用了插件：

kubectl cnpg backup -m volumeSnapshot hendrix

插件将按照 hendrix- 的命名模式创建备份资源，其中 YYYYMMDDHHMMSS 是请求备份的时间。

然后，operator会发起冷备份过程：

• 关闭选定副本的 Postgres 服务器（隔离fencing）

• 为集群定义的每个卷创建 VolumeSnapshot 资源，在本例中：

• hendrix-YYYYMMDDHHMMSS 用于 PGDATA

• hendrix-YYYYMMDDHHMMSS-wal 用于 WAL 文件

• 等待 CSI 外部快照程序为每个 VolumeSnapshot 创建相应的 VolumeSnapshotContent 资源

• 在冷备份操作完成后，解除选定副本的隔离（fence）

运行以下命令列出 hendrix 集群的可用备份：

kubectl get backup --selector=cnpg.io/cluster=hendrix

NAME                 AGE    CLUSTER   METHOD             PHASE    ERROR
hendrix-20231017150434   81s    hendrix   volumeSnapshot   completed
hendrix-20231017125847   7m8s    hendrix   barmanObjectStore   completed

kubectl get volumesnapshot --selector=cnpg.io/cluster=hendrix

备份和卷快照都包含重要的注释和标签，允许您浏览这些对象并根据执行月份或日期等进行删除。请务必花时间通过 kubectl 的 describe 命令进行探索。

然后，可以创建一个ScheduledBackup 对象来每天早上 5 点安排备份：

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: hendrix-vs
spec:
  schedule: '0 0 5 * * *'
  cluster:
    name: hendrix
  backupOwnerReference: self
  method: volumeSnapshot

恢复是备份发挥作用的关键所在。因此，在生产环境中采用恢复流程之前，定期进行测试至关重要。恢复过程应实现自动化，这在数据仓库和沙盒环境用于报告分析等领域开辟了许多有趣的途径。

从卷快照恢复的过程与 CloudNativePG 从对象存储恢复的过程相同 —— 通过引导新集群来实现。唯一的区别在于，除了指向对象存储外，您还可以请求从一组一致且相关的卷快照（PGDATA、WAL 和即将支持的表空间）创建新的 PVC。

您只需创建一个新的集群资源（例如 hendrix-recovery），其设置与 hendrix 相同，但引导部分除外。以下是摘录：

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: hendrix-recovery
spec:
  # <snip>
  bootstrap:
    recovery:
      volumeSnapshots:
        storage:
          name: hendrix-YYYYMMDDHHMMSS
          kind: VolumeSnapshot
          apiGroup: snapshot.storage.k8s.io
        walStorage:
          name: hendrix-YYYYMMDDHHMMSS-wal
          kind: VolumeSnapshot
          apiGroup: snapshot.storage.k8s.io

当您创建此资源时，恢复作业将从 .spec.bootstrap.recovery.volumeSnapshots 中指定的快照开始预置底层 PVC。完成后，PostgreSQL 将启动。

在上述示例中，我们没有定义任何 WAL 归档，因为上述快照是使用冷备份策略获取的，这是目前 CloudNativePG 中唯一可用的策略。如前所述，这些是一致的数据库快照，足以恢复到特定时间点 —— 即备份时间。

然而，如果您希望通过卷快照结合PITR实现更低的 RPO ，或者通过在不同区域的副本集群实现更好的全局 RTO（前提是底层存储类支持跨多个 Kubernetes 集群传递卷快照），则需要通过定义外部集群来指定 WAL 归档的位置。例如，可以在 hendrix-recovery 集群中添加以下内容：

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: hendrix-recovery
spec:
  # <snip>
  bootstrap:
    recovery:
      source:
        hendrix
      volumeSnapshots:
        # <snip>
      replica:
        enabled: true
        source: hendrix
      externalClusters:
        - name: hendrix
          barmanObjectStore: # <snip>

上述示意请求创建一个名为 hendrix-recovery 的新 Postgres 集群，该集群使用给定的卷快照进行引导，然后通过从 hendrix 对象存储获取 WAL 文件并以只读模式启动，置于持续复制状态。

这只是几个示例。不要被 Postgres 和operator在架构方面所提供的灵活性、自由度和创造力所吓倒。更多关于在 Kubernetes 中实现 PostgreSQL 的建议架构，请阅读 CNCF 博客上的相关文章《Recommended architectures for PostgreSQL in Kubernetes》（https://www.cncf.io/blog/2023/09/29/recommended-architectures-for-postgresql-in-kubernetes/）。

这些数据库是通过运行不同比例因子的 pgbench 初始化进程创建的，范围从最小的 300（耗时刚刚超过一分钟）到最大的 300,000（大约需要 33 小时完成，生成一个 4.4TB 的数据库）。上表还显示了测试中使用的 PGDATA 和 WAL 卷的大小。

实验包括首先在卷快照上进行首次备份，然后在运行 pgbench 一小时后再进行第二次备份。需要指出的是，首次备份需要存储整个卷内容，而后续备份仅存储与前一次快照的差异。每个集群在销毁后都会从最后一个快照重新创建。

我们决定不回放任何 WAL 文件，以防止污染测试结果并引入变异性，所以测量了从快照恢复到 Postgres 开始接受连接（或在 Kubernetes 术语中，直到readiness probe成功且 Pod 准备就绪）所需的裸恢复操作时长。

下表显示了每个集群的备份和恢复结果。

所有数据库都在两分钟内重启，包括大约 4.4TB 的最大实例。这是一个乐观的估计，因为实际时间取决于多个因素，特别是 CSI 外部快照程序存储差异的方式，在大多数情况下，恢复时间应短于首次完整备份所需时间。

由于每个组织环境（不仅包括技术，还包括人员！）都是不一样的，所以这里只是我们的一个测试。

如本文前面所述，这也只是 CloudNativePG 中卷快照支持的初步实现。

我们会在 1.22 版中着手添加热备份支持，通过遵循 pg_start_backup() 和 pg_stop_backup() 接口来避免关闭实例。这需要存在 WAL 归档，目前仅在对象存储中可用。

快照是 PVC 克隆的基础，即使用现有 PVC 作为源创建新的 PVC。因此，我们可以克服现有局限，当前的扩展和副本克隆仅通过 pg_basebackup 实现。

如果有一个非常大的数据库，这可能意味着需要花费数小时甚至数天才能完成该过程（尽管有时不是关键，但通常不受欢迎）。PVC 克隆将使这一过程更快。

PVC 克隆还将增强 PostgreSQL 的原地升级（例如，从 13 版升级到 16 版）。我们尚未在 CloudNativePG 中引入 pg_upgrade 支持，原因很简单 —— 这一关键操作需要 15 个以上步骤，目前没有方法可以自动回滚。

同时，使用对象存储中的备份进行回滚可能并非总是好的策略（对于 VLDB 肯定不是）。我们的想法是利用 PVC 克隆创建新的 PVC 以运行 pg_upgrade，并在一切按计划进行的情况下用新 PVC 替换旧 PVC。

如果出现故障，可以中止升级并恢复现有集群（使用未受影响的 PVC）。

另外，当我们在 1.22 版中引入对 PostgreSQL 的另一个全局对象 —— 表空间的支持时，快照将变得更加有趣。表空间使您能够将索引或数据分区放置在单独的 I/O 卷中，以实现更好的性能和垂直扩展性。表空间的优势之一是，将数据分布在多个卷中可能会减少备份和恢复的时间，因为可以并行进行快照。

我们也在密切关注 Kubernetes 卷组快照（VolumeGroupSnapshot）功能的进展，目前该功能处于 alpha 阶段，以实现 Postgres in Kubernetes 的不同卷（PGDATA、WAL 和表空间）之间的原子快照。

对 Kubernetes 卷快照 API 的声明式支持是 CloudNativePG 作为在云原生环境中以开放和标准方式运行 PostgreSQL 的又一重要里程碑。

尽管 1.22 及后续版本将更加明显地体现这一点，但当前版本已经将 Kubernetes 中的 PostgreSQL VLDB 体验提升到了一个新水平，无论您是在公有云、本地环境、虚拟机还是裸金属上运行。

在人工智能驱动的世界里，卷快照改变了您使用 Postgres 构建数据仓库以及创建沙盒环境以进行分析和数据探索的方式。

在业务连续性方面，卷快照支持将为您带来诸多益处：

• 通过卷快照实现更快的灾难恢复，从而改善 RTO

• 通过采用仅冷备份解决方案或基于对象存储（具有不同调度）的混合备份策略，实现更灵活的 RPO 控制

• 依靠存储类在不同的 Kubernetes 集群或区域中克隆数据，从而更精细地控制卷快照完成后的数据传递位置

如果您希望在任何层面上帮助改进该项目，请立即加入 CloudNativePG 社区。

EDB 在 Community 360 计划下为 CloudNativePG 和 PostgreSQL 提供 24/7 支持（已支持 OpenShift）。如果您需要更长的支持周期、与 Kasten K10 的集成，以及运行带有 TDE 的 Postgres Extended 或 Postgres Advanced 以简化从 Oracle 的迁移，您还可以考虑 EDB Postgres for Kubernetes，这是基于 CloudNativePG 的 EDB 产品，提供于 EDB 标准和企业计划下服务支持。

加入 CloudNativePG 社区https://github.com/cloudnative-pg/cloudnative-pg/blob/main/CONTRIBUTING.md

感谢您关注新智锦绣科技（北京）有限公司！作为 Elastic 的 Elite 合作伙伴及 EnterpriseDB 在国内的唯一代理和服务合作伙伴，我们始终致力于技术创新和优质服务，帮助企业客户实现数据平台的高效构建与智能化管理。无论您是关注 Elastic 生态系统，还是需要 EnterpriseDB 的支持，我们都将为您提供专业的技术支持和量身定制的解决方案。

欢迎关注我们，获取更多技术资讯和数字化转型方案，共创美好未来！