本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 監控和調校複寫程序
我們強烈建議您定期監控 RDS for PostgreSQL 資料庫執行個體和僅供讀取複本。您需要確保您的僅供讀取複本與來源資料庫執行個體上的變更保持一致。當複寫程序發生中斷時，Amazon RDS 會通透地復原您的僅供讀取複本。但，最好完全避免需要復原。使用複寫槽進行復原比使用 Amazon S3 封存更快，但任何復原程序皆會影響讀取效能。
如要確定僅供讀取複本與來源資料庫執行個體保持一致的程度，可執行下列作業：
+ **檢查來源資料庫執行個體和複本間的 `ReplicaLag` 數量。***複本延遲*指的是讀取複本落後於其來源資料庫執行個體的時間量 (以秒為單位)。此指標會報告下列查詢結果。
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
複本延遲可表示僅供讀取複本與來源資料庫執行個體保持一致的程度。這是來源資料庫執行個體與特定讀取執行個體之間的延遲量。複本延遲值較高可能表示來源資料庫執行個體與其僅供讀取複本所使用的資料庫執行個體類別或儲存體類型 (或兩者) 不相符。資料庫來源執行個體和所有僅供讀取複本的資料庫執行個體類別和儲存體類型應該相同。
複本延遲也可為儲存體類型連線問題的結果。您可以在 Amazon CloudWatch 中透過檢視 Amazon RDS `ReplicaLag` 指標來監控複寫延遲。如需進一步了解 `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` 的設定。例如，假設 PostgreSQL 日誌在 `checkpoint complete` 中顯示 `35 recycled`，間隔為 5 分鐘。於本案例中，`wal_keep_segments` 預設值 32 不足以跟上串流活動的進度，因此您應提高此參數的值。
+ **使用 Amazon CloudWatch 來監控可預測複寫問題的指標。**您可使用 Amazon CloudWatch 檢查已收集的指標，而非直接分析 PostgreSQL 日誌。例如，您可以檢查 `TransactionLogsGeneration` 指標值，來查看來源資料庫執行個體所產生的 WAL 資料量。在某些狀況下，資料庫執行個體上的工作負載可能會產生大量 WAL 資料。若是如此，您可能需要變更來源資料庫執行個體和僅供讀取複本的資料庫執行個體類別。使用具有高 (10 Gbps) 網路效能的執行個體類別可減少複本延遲。
## 監控 RDS for PostgreSQL 資料庫執行個體的複寫槽
RDS for PostgreSQL 的所有版本皆會對跨區域僅供讀取複本使用複寫槽。RDS for PostgreSQL 14.1 版和較新版本皆會對區域內僅供讀取複本使用複寫槽。區域內僅供讀取複本還會使用 Amazon S3 來封存 WAL 資料。換言之，若您的資料庫執行個體和僅供讀取複本執行 PostgreSQL 14.1 版或更新版本，則複寫槽和 Amazon S3 封存皆可用於復原僅供讀取複本。使用其複寫槽復原僅供讀取複本比從 Amazon S3 封存復原更快。因此，我們建議您監控複寫槽和及相關的指標。
您可檢視 RDS for PostgreSQL 資料庫執行個體上的複寫槽，方法是查詢 `pg_replication_slots` 檢視，如下所示。
```
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 資料已遭移除。該插槽不再可用。
只有在 `max_slot_wal_keep_size` 為非負值時，才會顯示 `wal_status` 的 `unreserved` 和 `lost` 狀態。
`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/)。