# Aurora PostgreSQL 論理レプリケーションの書き込みスルーキャッシュと論理スロットのモニタリング
<a name="AuroraPostgreSQL.Replication.Logical-monitoring"></a>

論理レプリケーションの書き込みスルーキャッシュをモニタリングし、論理スロットを管理して、Aurora PostgreSQL DB クラスターのパフォーマンスを向上させます。以下に、書き込みスルーキャッシュと論理スロットの詳細を示します。

**Topics**
+ [Aurora PostgreSQL 論理レプリケーション書き込みスルーキャッシュのモニタリング](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Aurora PostgreSQL の論理スロットの管理](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)

## Aurora PostgreSQL 論理レプリケーション書き込みスルーキャッシュのモニタリング
<a name="AuroraPostgreSQL.Replication.Logical-write-through-cache"></a>

デフォルトでは、Aurora PostgreSQL バージョン 14.5、13.8、12.12、11.17 以降は、ライトスルーキャッシュを使用して論理レプリケーションのパフォーマンスを向上させます。ライトスルーキャッシュがない場合、Aurora PostgreSQL はネイティブ PostgreSQL 論理レプリケーションプロセスの実装に Aurora ストレージレイヤーを使用します。そのためには、WAL データをストレージに書き込み、ストレージからデータを読み戻してデコードし、ターゲット (サブスクライバー) に送信 (複製) します。このため、Aurora PostgreSQL DB クラスターの論理レプリケーション中にボトルネックが発生する可能性があります。

書き込みスルーキャッシュは、Aurora ストレージレイヤーへの依存を最小限に抑えます。このレイヤーに対して書き込みと読み取りを一貫して行う代わりに、Aurora PostgreSQL はバッファを使用して論理 WAL ストリームをキャッシュしてレプリケーションプロセスで使用し、ディスクにアクセスする必要性を減らします。このバッファは、論理レプリケーションで使用する PostgreSQL ネイティブキャッシュであり、Aurora PostgreSQL DB クラスターのパラメータで `rds.logical_wal_cache` として識別されます。

Aurora PostgreSQL DB クラスターで論理レプリケーションを使用する場合 (ライトスルーキャッシュをサポートするバージョンの場合)、キャッシュヒット率をモニタリングして、ユースケースでの機能を確認できます。そのためには、次の例に示すように、`psql` を使用して Aurora PostgreSQL DB クラスターの書き込みインスタンスに接続し、次に Aurora 関数 `aurora_stat_logical_wal_cache` を使用します。

```
SELECT * FROM aurora_stat_logical_wal_cache();
```

関数は、次のような出力を返します。

```
name       | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183      | 24        | 0          | 24        | 100.00%  | 2022-08-05 17:39...
test_slot2 |            | 1         | 0          |  1        | 100.00%  | 2022-08-05 17:34...
(2 rows)
```

`last_reset_timestamp` 値は読みやすいように短くされています。この関数の詳細については、「[aurora\_stat\_logical\_wal\_cache](aurora_stat_logical_wal_cache.md)」を参照してください。

Aurora PostgreSQL には、ライトスルーキャッシュをモニタリングするための次の 2 つの関数が用意されています。
+ `aurora_stat_logical_wal_cache` 関数 - リファレンスドキュメントについては、「[aurora\_stat\_logical\_wal\_cache](aurora_stat_logical_wal_cache.md)」を参照してください。
+ `aurora_stat_reset_wal_cache` 関数 - リファレンスドキュメントについては、「[aurora\_stat\_reset\_wal\_cache](aurora_stat_reset_wal_cache.md)」を参照してください。

自動調整された WAL キャッシュサイズがワークロードに十分でないと判明した場合は、`rds.logical_wal_cache` の値を手動で変更できます。以下の点を考慮してください。
+ `rds.logical_replication` パラメータが無効になっている場合、`rds.logical_wal_cache` はゼロ (0) に設定されます。
+ `rds.logical_replication` パラメータが有効になっている場合、`rds.logical_wal_cache` のデフォルト値は 16 MB です。
+ `rds.logical_wal_cache` パラメータは静的であるため、変更を有効にするには、データベースインスタンスを再起動する必要があります。このパラメータは、8 Kb ブロック単位で定義されます。32 Kb 未満の正の値は 32 Kb として扱われることに注意してください。`wal_buffers` の詳細については、PostgreSQL ドキュメントの「[Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS)」を参照してください。

## Aurora PostgreSQL の論理スロットの管理
<a name="AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots"></a>

ストリーミングアクティビティは、`pg_replication_origin_status` ビューにキャプチャされます。このビューの内容を確認するには、次に示す `pg_show_replication_origin_status()` 関数が使用できます。

```
SELECT * FROM pg_show_replication_origin_status();
```

次の SQL クエリを使用すると、論理スロットのリストを取得できます。

```
SELECT * FROM pg_replication_slots;
```

論理スロットを削除するには、次のコマンドに示すように、スロットの名前を指定して `pg_drop_replication_slot` を使用します。

```
SELECT pg_drop_replication_slot('test_slot');
```