# 在 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 数据库实例的数据库参数组](USER_WorkingWithDBInstanceParamGroups.md)。
1. 在参数组中配置 `recovery_min_apply_delay` 参数：
+ 将该值设置为所需的延迟（以毫秒为单位）。例如，3600000 表示延迟 1 小时。
+ 允许的范围：0 到 86400000 毫秒（0 到 24 小时）
+ 默认：0
1. 将参数组应用于要为延迟复制配置的只读副本实例。
1. 要使更改生效，请重启只读副本实例。
**注意**
`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\$1superuser 角色](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)。
访问其他函数（如 `pg_is_wal_replay_paused()`），`pg_get_wal_replay_pause_state()` 不需要 `rds_superuser` 角色。
您可以使用以下恢复目标参数精确控制延迟副本恢复到的时间点。这些参数是静态的，需要重新启动数据库才能应用更改：
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**重要**
一次只能指定一个恢复目标参数。在配置文件中配置多个恢复目标参数会导致错误。
## 规划注意事项
在规划 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 只读副本文档](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)和 [RDS for PostgreSQL 灾难恢复文档](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html)。
## 理解限制
Amazon RDS for PostgreSQL 的延迟复制功能有以下限制：
+ 配置延迟复制时，蓝绿部署具有以下限制：
+ **绿源实例** — 即使在参数组中进行了配置，也会忽略 `recovery_min_apply_delay parameter`。绿源实例上的任何延迟设置都不会生效。
+ **绿副本实例** — 完全支持 `recovery_min_apply_delay parameter` 并将其应用于 PostgreSQL 配置文件。在切换工作流程中，延迟设置可以按预期运行。
+ 主要版本升级的 RDS 蓝绿部署
+ 在主版本升级期间，所有延迟只读副本都将自动终止，以允许源实例继续升级过程，从而最大限度地减少停机时间。源实例完成升级后，您必须手动重新创建延迟副本。
+ 延迟复制与以下功能不兼容。
+ RDS for PostgreSQL 逻辑复制
+ RDS for PostgreSQL 多可用区集群（包括入站和出站复制）
+ Aurora PostgreSQL