在 RDS for PostgreSQL 中配置延迟复制 - Amazon Relational Database Service
概述和优势启用和配置管理延迟复制恢复规划注意事项理解限制
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

在 RDS for PostgreSQL 中配置延迟复制

概述和优势

借助 RDS for PostgreSQL 中的延迟复制功能，您可以有意延迟将数据更改从主数据库复制到一个或多个备用（只读副本）服务器。这样可以有效防止数据损坏、意外数据丢失或错误事务，否则这些问题可能会立即传播到所有副本。

以下 RDS for PostgreSQL 版本支持延迟复制：

  • 14.19 及更高的 14 版本

  • 15.14 及更高的 15 版本

  • 16.10 及更高的 16 版本

  • 17.6 及更高的 17 版本

通过在复制过程中引入时间滞后，您可以获得一个时间窗口，在数据相关事件影响整个数据库集群之前进行检测和响应。延迟复制过程包括以下好处：

  • 允许您从意外删除、更新或其他逻辑错误中恢复。

  • 提供缓冲区，防止损坏的数据在数据库集群中扩散。

  • 提供额外的恢复点选项，以补充您的传统备份策略。

  • 允许您根据组织的特定需求和风险承受能力配置延迟时间。

启用和配置延迟复制

要在 RDS for PostgreSQL 只读副本上启用延迟复制，请执行以下步骤：

注意

对于级联只读副本，请使用下述相同的 recovery_min_apply_delay 参数和步骤。

启用延迟复制

  1. 创建新的自定义参数组或修改现有的自定义参数组。有关更多信息，请参阅 Amazon RDS 数据库实例的数据库参数组。

  2. 在参数组中配置 recovery_min_apply_delay 参数：

    • 将该值设置为所需的延迟（以毫秒为单位）。例如，3600000 表示延迟 1 小时。

    • 允许的范围：0 到 86400000 毫秒（0 到 24 小时）

    • 默认：0

  3. 将参数组应用于要为延迟复制配置的只读副本实例。

  4. 要使更改生效，请重启只读副本实例。

    注意

    recovery_min_apply_delay 参数是动态的。如果您修改已附加到实例的现有参数组，则更改无需重启即可立即生效。但是，将新参数组应用于实例时，必须重启才能使更改生效。

管理延迟复制恢复

在传统的时间点恢复方法可能不足或过于耗时的情况下，延迟复制特别有用。

在延迟复制期间，您可以使用以下 PostgreSQL 函数来管理恢复过程：

  • pg_wal_replay_pause()：请求暂停延迟副本的恢复过程。

  • pg_wal_replay_resume()：如果恢复过程之前已暂停，请重新启动该过程。

  • pg_is_wal_replay_paused()：检查恢复过程当前是否已暂停。

  • pg_get_wal_replay_pause_state()：获取恢复过程的当前状态（未暂停、未请求暂停或已暂停）。

具有 rds_superuser 角色的用户对 pg_wal_replay_pause() 和 pg_wal_replay_resume() 具有 EXECUTE 权限。如果其他数据库用户需要访问这些函数，则必须向他们授予 rds_superuser 角色。有关 rds_superuser 角色的更多信息，请参阅 了解 rds_superuser 角色。

访问其他函数（如 pg_is_wal_replay_paused()），pg_get_wal_replay_pause_state() 不需要 rds_superuser 角色。

您可以使用以下恢复目标参数精确控制延迟副本恢复到的时间点。这些参数是静态的，需要重新启动数据库才能应用更改：

  • recovery_target

  • recovery_target_lsn

  • recovery_target_name

  • recovery_target_time

  • recovery_target_xid

  • recovery_target_inclusive

重要

一次只能指定一个恢复目标参数。在配置文件中配置多个恢复目标参数会导致错误。

规划注意事项

在规划 RDS for PostgreSQL 延迟复制时，请考虑以下事项：

  • 在自动轮换 rdsrepladmin 凭证（每 90 天轮换一次）期间，延迟只读副本可能会暂时进入 REPLICATION_ERROR 状态。如果延迟副本有足够的 WAL 日志来维持配置的延迟，它可能会暂停 WAL 接收方进程，从而导致源端的 WAL 积累。您应监控副本的复制状态以及源端的存储使用情况，以避免存储空间不足。

  • 当延迟只读副本遇到系统事件（例如重启或重新启动）时，它们会进入 REPLICATION_ERROR 状态，即在配置的延迟期到期之前，WAL 接收方进程将一直保持非活动状态。此行为可能导致源实例上的 WAL 积累，从而可能导致存储空间耗尽。请考虑以下预防措施：

    • 配置 CloudWatch 警报以监控源实例的存储利用率。

    • 启用存储自动扩缩功能以处理意外的 WAL 增长。

    • 在源实例上设置 max_slot_wal_keep_size 参数以限制每个复制槽的 WAL 保留时间。

    • 定期监控复制滞后和插槽状态。

  • 较长的延迟会增加副本上的 WAL 日志，从而消耗更多的存储空间。使用 CloudWatch 警报监控存储空间，启用自动扩缩，或者在需要时追踪副本。

  • 提升延迟只读副本时，不支持 recovery_min_apply_delay 参数，并且会立即应用所有待处理的 WAL 记录。

  • recovery_min_apply_delay 参数独立于级联复制设置的每个级别。在副本上设置延迟不会增加任何级联副本的延迟。

有关更多信息，请参阅 RDS for PostgreSQL 只读副本文档和 RDS for PostgreSQL 灾难恢复文档。

理解限制

Amazon RDS for PostgreSQL 的延迟复制功能有以下限制：

  • 配置延迟复制时，蓝绿部署具有以下限制：

    • 绿源实例 — 即使在参数组中进行了配置，也会忽略 recovery_min_apply_delay parameter。绿源实例上的任何延迟设置都不会生效。

    • 绿副本实例 — 完全支持 recovery_min_apply_delay parameter 并将其应用于 PostgreSQL 配置文件。在切换工作流程中，延迟设置可以按预期运行。

    • 主要版本升级的 RDS 蓝绿部署

  • 在主版本升级期间，所有延迟只读副本都将自动终止，以允许源实例继续升级过程，从而最大限度地减少停机时间。源实例完成升级后，您必须手动重新创建延迟副本。

  • 延迟复制与以下功能不兼容。

    • RDS for PostgreSQL 逻辑复制

    • RDS for PostgreSQL 多可用区集群（包括入站和出站复制）

    • Aurora PostgreSQL