# 监控和调整复制过程
我们强烈建议您定期监控 RDS for PostgreSQL 数据库实例和只读副本。您需要确保只读副本与源数据库实例上的更改同步。当复制过程中断时，Amazon RDS 可以透明地恢复您的只读副本。但是，最好避免出现需要恢复的情况。使用复制槽进行恢复比使用 Amazon S3 归档快，但是任何恢复过程都可能会影响读取性能。
要确定只读副本与源数据库实例的同步程度，您可以执行以下操作：
+ **检查源数据库实例和副本之间的 `ReplicaLag` 数量。***副本滞后*是只读副本滞后于其源数据库实例的时间量（以秒为单位）。此指标将报告以下查询的结果。
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
副本滞后可指示只读副本与源数据库实例的同步程度。这是源数据库实例和特定只读实例之间的延迟量。副本滞后值较高可能表示源数据库实例使用的数据库实例类或存储类型（或两者）与其只读副本之间不匹配。数据库源实例和所有只读副本的数据库实例类和存储类型应相同。
副本滞后也可能是间歇性连接问题导致的。您可以通过查看 Amazon RDS `ReplicaLag` 指标，在 Amazon CloudWatch 中监控复制滞后。若要了解有关 `ReplicaLag` 和 Amazon RDS 的其他指标的更多信息，请参阅 [Amazon RDS 的 Amazon CloudWatch 指标](rds-metrics.md)。
+ **查看 PostgreSQL 日志了解可用于调整设置的信息。**在每个检查点中，PostgreSQL 日志都会捕获回收事务日志文件的数量，如以下示例所示。
```
2014-11-07 19:59:35 UTC::@:[26820]:LOG: checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s
```
您可以使用此信息来确定在给定时间段内回收了多少事务文件，然后可以根据需要更改 `wal_keep_segments` 设置。例如，假设 `checkpoint complete` 时的 PostgreSQL 日志每隔 5 分钟显示 `35 recycled`。在本例中，`wal_keep_segments` 默认值 32 不足以跟上流式传输活动的节奏，因此应增加此参数的值。
+ **使用 Amazon CloudWatch 监控可以预测复制问题的指标。**您可以使用 Amazon CloudWatch 检查已收集的指标，而不是直接分析 PostgreSQL 日志。例如，您可以检查 `TransactionLogsGeneration` 指标的值，以查看源数据库实例生成了多少 WAL 数据。某些情况下，数据库实例上的工作负载可能会生成大量 WAL 数据。如果是这样，您可能需要更改源数据库实例和只读副本的数据库实例类。使用具有高（10Gbps）网络性能的实例类可以减少副本滞后。
## 监控 RDS for PostgreSQL 数据库实例的复制槽
所有 RDS for PostgreSQL 版本都将复制槽用于跨区域只读副本。RDS for PostgreSQL 14.1 及更高版本将复制槽用于区域内只读副本。区域内只读副本还使用 Amazon S3 来归档 WAL 数据。换句话说，如果您的数据库实例和只读副本运行 PostgreSQL 14.1 或更高版本，则复制槽和 Amazon S3 归档都可用于恢复只读副本。使用复制槽恢复只读副本比从 Amazon S3 归档中恢复快。因此，我们建议您监控复制槽和相关指标。
您可以通过查询 `pg_replication_slots` 视图来查看 RDS for PostgreSQL 数据库实例上的复制槽，如下所示。
```
postgres=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f
(1 row)
```
`reserved` 值 `wal_status` 表示插槽持有的 WAL 数据量在 `max_wal_size` 参数的范围内。换句话说，复制槽的大小正确。其他可能的状态值如下所示：
+ `extended` – 插槽超过了`max_wal_size`设置，但 WAL 数据会被保留。
+ `unreserved` – 插槽不再拥有所有必需的 WAL 数据。其中一些将在下一个检查点移除。
+ `lost` – 一些必需的 WAL 数据已删除。插槽不再可用。
`wal_status` 的 `unreserved` 和 `lost` 状态只有在 `max_slot_wal_keep_size` 为非负数时才会显示。
`pg_replication_slots` 视图显示了复制插槽的当前状态。要评估复制插槽的性能，您可以使用 Amazon CloudWatch 并监控以下指标：
+ **`OldestReplicationSlotLag`**：显示源上尚未被滞后程度最高的副本占用的预写日志（WAL）数据量。
+ **`TransactionLogsDiskUsage`**：显示 WAL 数据使用了多少存储空间。如果只读副本出现明显滞后，此指标的值可能会大幅增加。
若要了解将 Amazon CloudWatch 及其指标用于 RDS for PostgreSQL 的更多信息，请参阅 [使用 Amazon CloudWatch 监控 Amazon RDS 指标](monitoring-cloudwatch.md)。有关监控 RDS for PostgreSQL 数据库实例上的流复制的更多信息，请参阅 *AWS数据库博客*上的 [Amazon RDS PostgreSQL 复制的最佳实践](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/)。