# Amazon Aurora PostgreSQL でのレプリケーション
以下では Amazon Aurora PostgreSQL でのレプリケーションと、論理レプリケーションのモニタリングと使用方法について説明します。
**Topics**
+ [Aurora レプリカの使用](#AuroraPostgreSQL.Replication.Replicas)
+ [Aurora レプリカの読み取り可用性の向上](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [Aurora PostgreSQL レプリケーションのモニタリング](#AuroraPostgreSQL.Replication.Monitoring)
+ [Aurora での PostgreSQL 論理レプリケーションの概要](AuroraPostgreSQL.Replication.Logical.md)
+ [Aurora PostgreSQL DB クラスターの論理レプリケーションの設定](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [論理レプリケーションをオフにする](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [Aurora PostgreSQL 論理レプリケーションの書き込みスルーキャッシュと論理スロットのモニタリング](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [例: Aurora PostgreSQL DB クラスターにおける論理レプリケーションの使用](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [例: Aurora PostgreSQL と AWS Database Migration Service を使用した論理レプリケーション](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [論理レプリケーション接続の IAM 認証の設定](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## Aurora レプリカの使用
*Aurora レプリカ*は Aurora DB クラスター内の独立したエンドポイントで、読み取りオペレーションのスケーリングと可用性向上に最適です。Aurora DB クラスターには、Aurora DB クラスターがある AWS リージョンのアベイラビリティーゾーン全体に配置された、最大 15 の Aurora レプリカを含めることができます。
DB クラスターボリュームは、DB クラスターのデータの複数のコピーから構成されます。ただし、クラスターボリューム内のデータは、DB クラスターのプライマリ書き込み DB インスタンスおよび Aurora レプリカに対して単一の論理的なボリュームとして表されます。Aurora レプリカの詳細については、「[Aurora レプリカ](Aurora.Replication.md#Aurora.Replication.Replicas)」を参照してください。
Aurora レプリカは、クラスターボリュームに対する読み取りオペレーション専用であるため、読み取りのスケーリングに適しています。書き込み DB インスタンスは、書き込みオペレーションを管理します。クラスターボリュームは、Aurora PostgreSQL DB クラスター内のすべてのインスタンス間で共有されます。したがって、各 Aurora レプリカでデータのコピーをレプリケートする追加作業は必要ありません。
Aurora PostgreSQL では、Aurora レプリカが削除されるとそのインスタンスエンドポイントは直ちに削除され、Aurora レプリカもリーダーエンドポイントから削除されます。削除中の Aurora レプリカで実行されているステートメントがある場合は、削除までに 3 分の猶予期間があります。既存のステートメントは、猶予期間中に適切に終了する場合があります。猶予期間が終了すると、Aurora レプリカはシャットダウンし、削除されます。
Aurora PostgreSQL DB クラスターでは、Aurora グローバルデータベースを使用し、異なる AWS リージョンの Aurora レプリカがサポートしています。詳細については、「[Amazon Aurora Global Database の使用](aurora-global-database.md)」を参照してください。
**注記**
読み取り可用性機能を備えた DB クラスターの Aurora レプリカを再起動するには、手動で実行する必要があります。この機能の前に作成された DB クラスターでは、ライター DB インスタンスを再起動すると、Aurora レプリカが自動的に再起動されます。自動再起動で再確立されるエントリポイントにより、DB クラスター全体での読み取り/書き込みの一貫性が保証されます。
## Aurora レプリカの読み取り可用性の向上
Aurora PostgreSQL は、ライター DB インスタンスが再起動したときや Aurora レプリカが書き込みトラフィックに追いつけなくなったときに読み取りリクエストを継続的に処理することで、DB クラスターの読み取り可用性を向上させます。
読み取り可用性機能は、Aurora PostgreSQL の次のバージョンでデフォルトで使用できます。
+ 16.1 以降のすべてのバージョン
+ バージョン 15 の 15.2 以降
+ バージョン 14 の 14.7 以降
+ バージョン 13 の 13.10 以降
+ バージョン 12 の 12.14 以降
読み取り可用性機能は、以下のバージョンの Aurora グローバルデータベースでサポートされています。
+ 16.1 以降のすべてのバージョン
+ 15.4 以降の 15 バージョン
+ 14.9 以降の 14 バージョン
+ 13.12 以降の 13 バージョン
+ 12.16 以降の 12 バージョン
この起動前にこれらのいずれかのバージョンで作成された DB クラスターの読み取り可用性機能を使用するには、DB クラスターのライターインスタンスを再起動します。
Aurora PostgreSQL DB クラスターの静的パラメーターを変更する場合、パラメーターの変更を有効にするにはライターインスタンスを再起動する必要があります。たとえば、`shared_buffers` の値を設定するときは、ライターインスタンスを再起動する必要があります。Aurora レプリカの読み取り可用性機能により、DB クラスターは可用性が向上し、ライターインスタンスの再起動時の影響が軽減されます。リーダーインスタンスは再起動せず、読み取りリクエストに応答し続けます。静的パラメーターの変更を適用するには、個々のリーダーインスタンスを再起動します。
Aurora PostgreSQL DB クラスターの Aurora レプリカは、ライターと再接続した後すぐにインメモリデータベースの状態に回復することで、ライターの再起動、フェイルオーバー、低速レプリケーション、ネットワークの問題などのレプリケーションエラーから回復できます。このアプローチにより、Aurora レプリカインスタンスは、クライアントデータベースを引き続き使用しながら、最新のストレージアップデートとの整合性を保つことができます。
レプリケーション復旧と競合する進行中のトランザクションはエラーを受け取る可能性がありますが、リーダーがライターに追いついたら、クライアントはこれらのトランザクションを再試行できます。
### Aurora レプリカのモニタリング
ライターの接続解除からのリカバリ時に Aurora レプリカをモニタリングできます。以下のメトリクスを使用して、リーダーインスタンスに関する最新情報を確認したり、処理中の読み取り専用トランザクションを追跡したりできます。
+ `aurora_replica_status` 関数は、リーダーインスタンスがまだ接続状態で最新の情報を返すように更新されています。クエリが実行された DB インスタンスに対応する行に対しては、`aurora_replica_status` の最終更新タイムスタンプは常に空となります。これは、リーダーインスタンスに最新のデータがあることを示します。
+ Aurora レプリカがライターインスタンスとの接続を切断して再接続すると、次のデータベースイベントが発生します。
`Read replica has been disconnected from the writer instance and reconnected.`
+ リカバリの競合が原因で読み取り専用クエリがキャンセルされると、データベースエラーログに以下の 1 つ以上のエラーメッセージが表示されることがあります。
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### 制限事項
読み取り可用性機能を備えた Aurora レプリカには、次の制限が適用されます。
+ レプリケーションの復旧中にライターインスタンスからデータをストリーミングできない場合、セカンダリ DB クラスターの Aurora レプリカが再起動できます。
+ Aurora レプリカは、オンラインレプリケーションリカバリが既に進行中の状態で再起動される場合は、オンラインレプリケーションリカバリをサポートしません。
+ Aurora レプリカは、DB インスタンスがトランザクション ID のラップアラウンドに近づくと再起動します。トランザクション ID 循環の詳細については、「[トランザクション ID 循環失敗の防止](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND )」を参照してください。
+ Aurora レプリカは、特定の状況でレプリケーションプロセスがブロックされたときに再起動できます。
## Aurora PostgreSQL レプリケーションのモニタリング
読み取りのスケーリングと高可用性は最短遅延時間に左右されます。Amazon CloudWatch `ReplicaLag` メトリクスをモニタリングすることにより、Aurora レプリカが Aurora PostgreSQL DB クラスターの書き込み DB インスタンスからどれくらい遅延しているかをモニタリングできます。Aurora レプリカは、書き込み DB インスタンスと同じクラスターボリュームから読み取るため、`ReplicaLag` メトリクスの意味は Aurora PostgreSQL DB クラスターの場合とは異なります。Aurora レプリカの `ReplicaLag` メトリクスは、書き込み DB インスタンスのページキャッシュと比較した場合の Aurora レプリカのページキャッシュの遅延を示します。
RDS インスタンスと CloudWatch メトリックスのモニタリングの詳細については、「[Amazon Aurora クラスターでのメトリクスのモニタリング](MonitoringAurora.md)」を参照してください。
# Aurora での PostgreSQL 論理レプリケーションの概要
Aurora PostgreSQL DB クラスターで PostgreSQL の論理レプリケーション機能を使用することで、データベースインスタンス全体ではなく、個々のテーブルをレプリケートおよび同期できます。論理レプリケーションでは、パブリケーションおよびサブスクリプションモデルを使用して、ソースからの変更を 1 人または複数の受信者にレプリケートします。これは、PostgreSQL のログ先行書き込み (WAL) の変更レコードを使用することで動作します。送信元 (*パブリッシャー*) は、指定されたテーブルの WAL データを 1 人または複数の受信者 (*サブスクライバー*) に送信します。これによって変更がレプリケートされ、サブスクライバーのテーブルとパブリッシャーのテーブルの同期を維持できます。パブリッシャーによる一連の変更は、*パブリケーション*を使用して識別します。サブスクライバーは、パブリッシャーのデータベースとそのパブリケーションへの接続を定義する*サブスクリプション*を作成することによって変更を取得できます。*レプリケーション*スロットは、この方式によってサブスクリプションの進行状況を追跡するために使用されるメカニズムです。
Aurora PostgreSQL DB クラスターでは、WAL レコードは Aurora ストレージに保存されます。論理レプリケーションシナリオでパブリッシャーとして機能する Aurora PostgreSQL DB クラスターは、Aurora ストレージから WAL データを読み込み、デコードしてサブスクライバーに送信し、そのインスタンスのテーブルに変更を適用できるようにします。パブリッシャーでは、*論理デコーダー*を使用してデータをデコードすることでサブスクライバーが使用できるようにします。デフォルトでは、Aurora PostgreSQL DB クラスターはデータを送信する際にネイティブ PostgreSQL `pgoutput` プラグインを使用します。他の論理デコーダーも使用できます。例えば、Aurora PostgreSQL は WAL データを JSON に変換する `[wal2json](https://github.com/eulerto/wal2json)` プラグインもサポートしています。
Aurora PostgreSQL バージョン 14.5、13.8、12.12、11.17 以降、Aurora PostgreSQL は PostgreSQL の論理レプリケーションプロセスを*ライトスルーキャッシュ*で強化してパフォーマンスを向上させています。WAL トランザクションログは、ディスク I/O の量、つまり論理デコード中に Aurora ストレージから読み取る量を減らすために、ローカルでバッファにキャッシュされます。Aurora PostgreSQL DB クラスターの論理レプリケーションを使用する場合は常に、ライトスルーキャッシュがデフォルトで使用されます。Aurora には、キャッシュの管理に使用できる機能がいくつか用意されています。詳細については、「[Aurora PostgreSQL 論理レプリケーション書き込みスルーキャッシュのモニタリング](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache)」を参照してください。
論理レプリケーションは、現在の Aurora PostgreSQL のすべてのバージョンでサポートされています。詳細については、「*Aurora PostgreSQL リリースノート*」の「[Amazon Aurora PostgreSQL の更新](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html)」を参照してください。
論理レプリケーションは、Babelfish for Aurora PostgreSQL で以下のバージョンからサポートされています。
+ 15.7 以降のバージョン
+ 16.3 以降のバージョン
**注記**
PostgreSQL 10 で導入されたネイティブの PostgreSQL 論理レプリケーション機能に加えて、Aurora PostgreSQL は `pglogical` エクステンションもサポートしています。詳細については、「[pglogical を使用してインスタンス間でデータを同期する](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)」を参照してください。
PostgreSQL 論理レプリケーションの詳細については、PostgreSQL ドキュメントの「[論理レプリケーション](https://www.postgresql.org/docs/current/logical-replication.html)」と「[論理デコーディングのコンセプト](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html)」を参照してください。
**注記**
PostgreSQL 16 では、リードレプリカからの論理デコードのサポートが追加されました。この機能は Aurora PostgreSQL ではサポートされていません。
# Aurora PostgreSQL DB クラスターの論理レプリケーションの設定
論理レプリケーションの設定には `rds_superuser` 権限が必要です。以下で説明する手順のように、Aurora PostgreSQL DB クラスターは、必要なパラメータを設定できるように、カスタム DB クラスターパラメータグループを使用するように設定する必要があります。詳細については、「[Amazon Aurora DB クラスターの DB クラスターパラメータグループ](USER_WorkingWithDBClusterParamGroups.md)」を参照してください。
**Aurora PostgreSQL DB クラスターに PostgreSQL 論理レプリケーションを設定するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[Aurora PostgreSQL DB cluster] (Aurora PostgreSQL DB クラスター) を選択します。
1. **[Configuration]** (設定) タブを開きます。インスタンスの詳細の中から、**タイプの** **DB クラスターパラメーターグループ**との**パラメーターグループ**のリンクを見つけます。
1. リンクを選択して、Aurora PostgreSQL DB クラスターに関連するカスタムパラメータを開きます。
1. **[Parameters]** (パラメータ) 検索フィールドに `rds` と入力し、`rds.logical_replication` パラメータを検索します。このパラメータのデフォルト値は `0` です。つまり、デフォルトではオフになっています。
1. **[Edit parameters]** (パラメータの編集) を選択してプロパティ値にアクセスし、次にセレクタから `1` を選択して機能をオンにします。予想される使用状況に応じて、次のパラメータ設定の変更が必要になる場合があります。ただし、多くの場合はデフォルト値で十分です。
+ `max_replication_slots` — このパラメータには、最低でも論理レプリケーションのパブリケーションとサブスクリプションの合計予定数以上の値を設定します。AWS DMS を使用している場合、このパラメータには、クラスターからの変更データ取得タスクの予定数に、論理レプリケーションのパブリケーションとサブスクリプションを加えたものと最低でも同じ値を設定する必要があります。
+ `max_wal_senders` および `max_logical_replication_workers` - これらのパラメータには、アクティブにする予定の論理レプリケーションスロットの最小数、または変更データ取得用のアクティブな AWS DMS タスクの数以上の値を設定します。論理レプリケーションスロットを非アクティブにしておくと、バキュームによってテーブルから古いタプルを削除できないため、レプリケーションスロットをモニタリングして、必要に応じて非アクティブなスロットを削除することをお勧めします。
+ `max_worker_processes` – このパラメータには、最低でも `max_logical_replication_workers`、`autovacuum_max_workers`、`max_parallel_workers` の合計と同じ値を設定してください。小規模な DB インスタンスクラスでは、バックグラウンドのワーカープロセスがアプリケーションのワークロードに影響を与える可能性があるため、`max_worker_processes` をデフォルト値よりも高い値を設定する場合はデータベースのパフォーマンスをモニタリングしてください。(デフォルト値は `GREATEST(${DBInstanceVCPU*2},8}` の結果であり、つまり、デフォルトでは 8 または DB インスタンスクラスの CPU 相当量の 2 倍のどちらか大きい方になります)。
**注記**
ユーザー定義の DB パラメータグループのパラメータ値は変更できますが、デフォルトの DB パラメータグループのパラメータ値を変更することはできません。
1. **[Save changes]** (変更の保存) をクリックします。
1. Aurora PostgreSQL DB クラスターのライターインスタンスを再起動して、変更を有効にします。Amazon RDS コンソールで、クラスターのプライマリ DB インスタンスを選択し、**[Actions]** (アクション) メニューから **[Reboot]** (再起動) を選択します。
1. インスタンスが使用可能になると、次のように論理レプリケーションがオンになっていること確認できます。
1. `psql` を使用して、Aurora PostgreSQL DB クラスターのライターインスタンスに接続します。
```
psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. 次のコマンドを使用して、論理レプリケーションが有効になっていることを確認します。
```
labdb=> SHOW rds.logical_replication;
rds.logical_replication
-------------------------
on
(1 row)
```
1. `wal_level` が `logical` に設定されていることを確認してください。
```
labdb=> SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
論理レプリケーションを使用して、ソースの Aurora PostgreSQL DB クラスターからの変更とデータベーステーブルの同期を維持させる例については、「[例: Aurora PostgreSQL DB クラスターにおける論理レプリケーションの使用](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)」を参照してください。
# 論理レプリケーションをオフにする
レプリケーションタスクが完了したら、レプリケーションプロセスを停止し、レプリケーションスロットを削除して論理レプリケーションをオフにする必要があります。スロットを削除する前に、そのスロットが不要になったことを確認します。アクティブなレプリケーションスロットは削除できません。
**論理レプリケーションをオフにするには**
1. すべてのレプリケーションスロットを削除します。
すべてのレプリケーションスロットを削除するには、パブリッシャーに接続して以下の SQL コマンドを実行します。
```
SELECT pg_drop_replication_slot(slot_name)
FROM pg_replication_slots
WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);
```
そのコマンドを実行する際、レプリケーションスロットをアクティブにすることはできません。
1. 「[Aurora PostgreSQL DB クラスターの論理レプリケーションの設定](AuroraPostgreSQL.Replication.Logical.Configure.md)」で説明したように、パブリッシャーに関連するカスタム DB クラスターのパラメータグループを変更し、`rds.logical_replication` パラメータを 0 に設定します。
カスタムパラメータグループの詳細については、「[Amazon Aurora での DB クラスターパラメータグループのパラメータの変更](USER_WorkingWithParamGroups.ModifyingCluster.md)」を参照してください。
1. `rds.logical_replication` パラメータの変更を有効にするには、パブリッシャーの Aurora PostgreSQL DB クラスターを再起動します。
# Aurora PostgreSQL 論理レプリケーションの書き込みスルーキャッシュと論理スロットのモニタリング
論理レプリケーションの書き込みスルーキャッシュをモニタリングし、論理スロットを管理して、Aurora PostgreSQL DB クラスターのパフォーマンスを向上させます。以下に、書き込みスルーキャッシュと論理スロットの詳細を示します。
**Topics**
+ [Aurora PostgreSQL 論理レプリケーション書き込みスルーキャッシュのモニタリング](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Aurora PostgreSQL の論理スロットの管理](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Aurora PostgreSQL 論理レプリケーション書き込みスルーキャッシュのモニタリング
デフォルトでは、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\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md)」を参照してください。
Aurora PostgreSQL には、ライトスルーキャッシュをモニタリングするための次の 2 つの関数が用意されています。
+ `aurora_stat_logical_wal_cache` 関数 - リファレンスドキュメントについては、「[aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md)」を参照してください。
+ `aurora_stat_reset_wal_cache` 関数 - リファレンスドキュメントについては、「[aurora\$1stat\$1reset\$1wal\$1cache](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 の論理スロットの管理
ストリーミングアクティビティは、`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');
```
# 例: Aurora PostgreSQL DB クラスターにおける論理レプリケーションの使用
以下の手順では、2 つの Aurora PostgreSQL DB クラスター間で論理レプリケーションを開始する方法を示しています。「[Aurora PostgreSQL DB クラスターの論理レプリケーションの設定](AuroraPostgreSQL.Replication.Logical.Configure.md)」で説明したように、パブリッシャーとサブスクライバーの両方が、論理レプリケーション用に設定されている必要があります。
パブリッシャーとして指定されている Aurora PostgreSQL DB クラスターでも、レプリケーションスロットへのアクセスを許可する必要があります。そのためには、Amazon VPC サービスに基づいて Aurora PostgreSQL DB クラスターの仮想パブリッククラウド (VPC) に関連付けられているセキュリティグループを変更します。サブスクライバーの VPC に関連付けられているセキュリティグループをパブリッシャーのセキュリティグループに追加することで、インバウンドアクセスを許可します。詳細については、「*Amazon VPC ユーザーガイド*」の「[セキュリティグループを使用してリソースへのトラフィックを制御する](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。
これらの準備手順が完了したら、次の手順で説明されているように、パブリッシャーには PostgreSQL の `CREATE PUBLICATION` コマンドを、サブスクライバーには `CREATE SUBSCRIPTION` コマンドを使用できます。
**2 つの Aurora PostgreSQL DB クラスター間で論理レプリケーションを開始するには**
これらの手順では、Aurora PostgreSQL DB クラスターに、サンプルテーブルを作成するデータベースを含むライターインスタンスがあることを前提としています。
1. **パブリッシャーとしての Aurora PostgreSQL DB クラスター**
1. 次の SQL ステートメントを使用してテーブルを作成します。
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. 次の SQL ステートメントを使用して、パブリッシャーデータベース内にデータを挿入します。
```
INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
```
1. 次の SQL ステートメントを使用して、テーブルにデータが存在することを確認します。
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. 次のように、`CREATE PUBLICATION` ステートメントを使用してこのテーブルのパブリケーションを作成します。
```
CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
```
1. **サブスクライバーとしての Aurora PostgreSQL DB クラスター**
1. 次のように、パブリッシャーで作成したものと同じ `LogicalReplicationTest` テーブルをサブスクライバーに作成します。
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. このテーブルが空であることを確認します。
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. サブスクリプションを作成して、パブリッシャーから変更を取得します。パブリッシャーの Aurora PostgreSQL DB クラスターについて、次の詳細を使用する必要があります。
+ **host** (ホスト) - パブリッシャーである Aurora PostgreSQL DB クラスターのライター DB インスタンス。
+ **ポート** - 書き込み DB インスタンスがリッスンするポート。PostgreSQL のデフォルト値は 5432 です。
+ **dbname** (データベース名) – データベースの名前。
```
CREATE SUBSCRIPTION testsub CONNECTION
'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password'
PUBLICATION testpub;
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
サブスクリプションを作成すると、論理的なレプリケーションスロットがパブリッシャーで作成されます。
1. この例で、初期のデータがサブスクライバーにレプリケートされていることを確認するには、サブスクライバーデータベースで次の SQL ステートメントを使用します。
```
SELECT count(*) FROM LogicalReplicationTest;
```
パブリッシャーの以降のすべての変更がサブスクライバーにレプリケートされます。
論理レプリケーションはパフォーマンスに影響を与えます。レプリケーションタスクが完了したら、論理レプリケーションをオフにすることをお勧めします。
# 例: Aurora PostgreSQL と AWS Database Migration Service を使用した論理レプリケーション
AWS Database Migration Service 「AWS DMS」 を使用してデータベースまたはその一部をレプリケートできます。AWS DMS を使用して、Aurora PostgreSQL データベースから、別のオープンソースデータベースまたは商用データベースにデータを移行させます。AWS DMS の詳細については、『[AWS Database Migration Service ユーザーガイド](https://docs.aws.amazon.com/dms/latest/userguide/)』を参照してください。
次の例では、Aurora PostgreSQL データベースからの (パブリッシャーとしての) 論理的なレプリケーションを設定し、次に移行のために AWS DMS を使用する方法を示します。この例では、「[例: Aurora PostgreSQL DB クラスターにおける論理レプリケーションの使用](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)」で作成したのと同じパブリッシャーおよびサブスクライバーを使用しています。
AWS DMS で論理的なレプリケーションを設定するには、Amazon RDS のパブリッシャーとサブスクライバーに関する詳細が必要です。特に、パブリッシャーの書き込み DB インスタンスとサブスクライバーの DB インスタンスに関する詳細が必要です。
パブリッシャーの書き込み DB インスタンスについては以下の情報を取得します。
+ 仮想プライベートクラウド (VPC) の識別子
+ サブネットグループ
+ アベイラビリティーゾーン (AZ)
+ VPC セキュリティグループ
+ DB インスタンス ID
サブスクライバーの DB インスタンスについては以下の情報を取得します。
+ DB インスタンス ID
+ 出典エンジン
**Aurora PostgreSQL での論理的なレプリケーションに AWS DMS を使用するには**
1. AWS DMS を使用するようにパブリッシャーデータベースを準備します。
これを行うには、PostgreSQL 10.x 以降のデータベースで、AWS DMS ラッパー関数をパブリッシャーデータベースに適用する必要があります。このステップと以降のステップの詳細については、*AWS Database Migration Service ユーザーガイドの*「[AWS DMS のソースとして PostgreSQL バージョン 10.x 以降を使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10)」を参照してください。
1. AWS マネジメントコンソール にサインインして、AWS DMS で [https://console.aws.amazon.com/dms/v2](https://console.aws.amazon.com/dms/v2) コンソールを開きます。右上で、パブリッシャーとサブスクライバーがある同じ AWS リージョンを選択します。
1. AWS DMS レプリケーションインスタンスを作成します。
パブリッシャーの書き込み DB インスタンスと同じ値を選択します。これらには、以下の設定が含まれます。
+ 「**VPC**」 で、書き込み DB インスタンスと同じ VPC を選択します。
+ 「**Replication Subnet Group (レプリケーションのサブネットグループ)**」 で、書き込み DB インスタンスと同じ値のサブネットグループを選択します。必要に応じて新規に作成してください。
+ 「**アベイラビリティーゾーン**」 で、書き込み DB インスタンスと同じゾーンを選択します。
+ 「**VPC セキュリティグループ**」 で、書き込み DB インスタンスと同じグループを選択します。
1. 出典の AWS DMS エンドポイントを作成します。
次の設定を使用して、パブリッシャーを出典エンドポイントとして指定します。
+ 「**Endpoint type (エンドポイントタイプ)**」 で 「**Source endpoint (出典エンドポイント)**」を選択します。
+ 「**Select RDS DB Instance (RDS DB インスタンスの選択)**」 を選択します。
+ 「**RDS Instance (RDS インスタンス)**」で、パブリッシャーの書き込み DB インスタンスの DB 識別子を選択します。
+ 「**Source engine (出典エンジン)**」 で 「**postgres**」 を選択します。
1. ターゲットの AWS DMS エンドポイントを作成します。
次の設定を使用して、サブスクライバーをターゲットエンドポイントとして指定します。
+ 「**Endpoint type (エンドポイントタイプ)**」 で 「**Target endpoint (ターゲットエンドポイント)**」 を選択します。
+ [**Select RDS DB Instance (RDS DB インスタンスの選択)**] を選択します。
+ [**RDS Instance (RDS インスタンス)**] で、サブスクライバーの DB インスタンスの DB 識別子を選択します。
+ [**Source engine (出典エンジン)**] の値を選択します。例えば、サブスクライバーが RDS PostgreSQL データベースの場合は、[**postgres**] を選択します。サブスクライバーが Aurora PostgreSQL データベースである場合は、[**aurora-postgresql**] を選択します。
1. AWS DMS データベース移行タスクを作成します。
データベース移行タスクを使用して、移行するデータベーステーブルを指定し、ターゲットスキーマを使用してデータをマッピングして、ターゲットデータベースで新しいテーブルを作成します。少なくとも、[**Task configuration (タスクの設定)**] で以下の設定を使用します。
+ [**Replication instance (レプリケーションインスタンス)**] で、前のステップで作成したレプリケーションインスタンスを選択します。
+ [**Source database endpoint (出典データベースエンドポイント)**] で、前のステップで作成したパブリッシャー出典を選択します。
+ [**Target database endpoint (ターゲットデータベースエンドポイント)**] で、前のステップで作成したサブスクライバーターゲットを選択します。
タスクの残りの詳細は、移行プロジェクトに応じて異なります。DMS タスクのすべての詳細を指定する方法については、*AWS Database Migration Service ユーザーガイド*の「[AWS DMS タスクの使用](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html)」を参照してください。
AWS DMS は、タスクを作成した後で、パブリッシャーからサブスクライバーへのデータの移行を開始します。
# 論理レプリケーション接続の IAM 認証の設定
Aurora PostgreSQL バージョン 11 以降では、レプリケーション接続に AWS Identity and Access Management (IAM) 認証を使用できます。この機能は、パスワードの代わりに IAM ロールを使用してデータベースアクセスを管理できるようにすることで、セキュリティを強化します。クラスターレベルで動作し、標準の IAM 認証と同じセキュリティモデルに従います。
レプリケーション接続の IAM 認証はオプトイン機能です。有効にするには、DB クラスターパラメータグループの `rds.iam_auth_for_replication` パラメータを `1` に設定します。これは動的パラメータであるため、DB クラスターを再起動する必要がなく、ダウンタイムなしで既存のワークロードで IAM 認証を活用できます。この機能を有効にする前に、以下の [前提条件](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites) を満たす必要があります。
## 前提条件
レプリケーション接続に IAM 認証を使用するには、以下のすべての要件を満たす必要があります。
+ Aurora PostgreSQL DB クラスターはバージョン 11 以降である必要があります。
+ パブリッシャーとしての Aurora PostgreSQL DB クラスター
+ IAM データベース認証を有効にする。
詳細については、「[IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)」を参照してください。
+ `rds.logical_replication` パラメータを `1` に設定して、論理レプリケーションを有効にします。
詳細については、「[Aurora PostgreSQL DB クラスターの論理レプリケーションの設定](AuroraPostgreSQL.Replication.Logical.Configure.md)」を参照してください。
論理レプリケーションでは、パブリッシャーはサブスクライバークラスターにデータを送信するソース Aurora PostgreSQL DB クラスターです。詳細については、「[Aurora での PostgreSQL 論理レプリケーションの概要](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html)」を参照してください。
**注記**
パブリッシャー Aurora PostgreSQL DB クラスターで IAM 認証と論理レプリケーションの両方を有効にする必要があります。どちらかが有効になっていない場合、レプリケーション接続に IAM 認証を使用することはできません。
## レプリケーション接続の IAM 認証の有効化
レプリケーション接続の IAM 認証を有効にするには、次の手順を実行します。
1. Aurora PostgreSQL DB クラスターが、レプリケーション接続による IAM 認証のすべての前提条件を満たしていることを確認します。詳細については、「[前提条件](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites)」を参照してください。
1. DB クラスターパラメータグループを変更して、`rds.iam_auth_for_replication` パラメータを設定します。
+ `rds.iam_auth_for_replication` パラメータを `1` に設定します。これは再起動を必要としない動的パラメータです。
1. データベースに接続し、必要なロールをレプリケーションユーザーに付与します。
次の SQL コマンドは、レプリケーション接続の IAM 認証を有効にするために必要なロールを付与します。
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
これらのステップを完了した後、指定されたユーザーはレプリケーション接続に IAM 認証を使用する必要があります。
**重要**
この機能を有効にすると、`rds_iam` ロールと `rds_replication` ロールの両方を持つユーザーは、レプリケーション接続に IAM 認証を使用する必要があります。これは、ロールがユーザーに直接割り当てられているか、他のロールを通じて継承されているかにかかわらず適用されます。
## レプリケーション接続の IAM 認証の無効化
レプリケーション接続の IAM 認証を無効にするには、次のいずれかの方法を使用します。
+ DB クラスターパラメータグループの `rds.iam_auth_for_replication` パラメータを `0` に設定します。
+ または、Aurora PostgreSQL DB クラスターで次のいずれかの機能を無効にすることもできます。
+ `rds.logical_replication` パラメータを `0` に設定して論理レプリケーションを無効にする
+ IAM 認証の無効化
この機能を無効にすると、レプリケーション接続が設定されている場合、認証にデータベースパスワードを使用できます。
**注記**
`rds_iam` ロールを持たないユーザーのレプリケーション接続は、この機能が有効になっている場合でもパスワード認証を使用できます。
## 制約事項と考慮事項
レプリケーション接続に IAM 認証を使用する場合、以下の制限と考慮事項が適用されます。
+ レプリケーション接続の IAM 認証は、Aurora PostgreSQL バージョン 11 以降でのみ使用できます。
+ パブリッシャーは、レプリケーション接続の IAM 認証をサポートする必要があります。
+ IAM 認証トークンは、デフォルトで 15 分後に期限切れになります。トークンの有効期限が切れる前に、長時間実行されるレプリケーション接続を更新する必要がある場合があります。