# Amazon RDS for PostgreSQL でサポートされている PostgreSQL の機能を使用する Amazon RDS for PostgreSQL は、PostgreSQL の代表的な機能の多くをサポートしています。例えば、PostgreSQL には、データベースの定期的なメンテナンスを実行する自動バキューム機能があります。autovacuum 機能は、デフォルトでアクティブになっています。この機能をオフにすることはできますが、オンにしておくことを強くお勧めします。この機能を理解し、それを正しく動作させるために何ができるかを把握することは、どの DBA にとっても基本的なタスクです。自動バキュームの詳細については、「[Amazon RDS for PostgreSQL での PostgreSQL 自動バキュームの使用](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)」を参照してください。その他の一般的な DBA タスクの詳細については、「[Amazon RDS for PostgreSQL の一般的な DBA タスク](Appendix.PostgreSQL.CommonDBATasks.md)」を参照してください。 RDS for PostgreSQL では、DB インスタンスに重要な機能性を追加する拡張機能もサポートされています。例えば、PostGIS 拡張機能を使用して空間データを操作したり、pg\$1cron 拡張機能を使用してインスタンス内からメンテナンスをスケジュールしたりできます。PostgreSQL 拡張機能の詳細については、「[Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用する](Appendix.PostgreSQL.CommonDBATasks.Extensions.md)」を参照してください。 外部データラッパーは、RDS for PostgreSQL DB インスタンスが他の商用データベースまたはデータ型と連携できるように設計された特定のタイプの拡張機能です。RDS for PostgreSQL でサポートされている外部データラッパーの詳細については、「[Amazon RDS for PostgreSQL でサポートされている外部データラッパーを使用する](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md)」を参照してください。 RDS for PostgreSQL でサポートされているその他の機能については、次で説明します。 **Topics** + [RDS for PostgreSQL でのカスタムデータ型および列挙型](PostgreSQL.Concepts.General.FeatureSupport.AlterEnum.md) + [RDS for PostgreSQL のイベントトリガー](PostgreSQL.Concepts.General.FeatureSupport.EventTriggers.md) + [RDS for PostgreSQL の ヒュージページ](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md) + [Amazon RDS for PostgreSQL の論理レプリケーションの実行](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md) + [論理レプリケーション接続の IAM 認証の設定](PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.md) + [stats\$1temp\$1directory の RAM ディスク](PostgreSQL.Concepts.General.FeatureSupport.RamDisk.md) + [RDS for PostgreSQL のテーブルスペース](PostgreSQL.Concepts.General.FeatureSupport.Tablespaces.md) + [EBCDIC やその他のメインフレーム移行のための RDS for PostgreSQL 照合順序](PostgreSQL.Collations.mainframe.migration.md) + [RDS for PostgreSQL の論理スロット同期の管理](Appendix.PostgreSQL.CommonDBATasks.pglogical.slot.synchronization.md) # RDS for PostgreSQL でのカスタムデータ型および列挙型 PostgreSQL では、カスタムデータ型の作成と列挙型の操作がサポートされています。列挙型とその他のデータ型の作成および操作の詳細については、「PostgreSQL のドキュメント」の「[列挙型](https://www.postgresql.org/docs/14/datatype-enum.html)」を参照してください。 次は、列挙型として型を作成し、テーブルに値を挿入する例です。 ``` CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple'); CREATE TYPE CREATE TABLE t1 (colors rainbow); CREATE TABLE INSERT INTO t1 VALUES ('red'), ( 'orange'); INSERT 0 2 SELECT * from t1; colors -------- red orange (2 rows) postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson'; ALTER TYPE postgres=> SELECT * from t1; colors --------- crimson orange (2 rows) ``` # RDS for PostgreSQL のイベントトリガー 現在すべての PostgreSQL バージョンでイベントトリガーをサポートしているため、RDS for PostgreSQL のすべての利用可能なバージョンも、同様にイベントトリガーをサポートしています。メインユーザーアカウント (デフォルトでは `postgres`) を使用して、イベントトリガーを作成、変更、名前変更、および削除できます。イベントトリガーは DB インスタンスレベルであるため、インスタンスのすべてのデータベースに適用できます。 例えば、次のコードは、各データ定義言語 (DDL) コマンドの最後に現在のユーザーを表示するイベントトリガーを作成します。 ``` CREATE OR REPLACE FUNCTION raise_notice_func() RETURNS event_trigger LANGUAGE plpgsql AS $$ BEGIN RAISE NOTICE 'In trigger function: %', current_user; END; $$; CREATE EVENT TRIGGER event_trigger_1 ON ddl_command_end EXECUTE PROCEDURE raise_notice_func(); ``` PostgreSQL イベントトリガーの詳細については、PostgreSQL ドキュメントの「[Event Triggers](https://www.postgresql.org/docs/current/static/event-triggers.html)」を参照してください。 Amazon RDS で PostgreSQL イベントトリガーを使用する場合、いくつかの制限があります。これには以下が含まれます。 + リードレプリカでイベントトリガーを作成することはできません。ただし、イベントトリガーはリードレプリカソースで作成できます。作成したイベントトリガーは、リードレプリカにコピーされます。リードレプリカのイベントトリガーは、ソースから変更がプッシュされたときにリードレプリカでは起動しません。ただし、リードレプリカが昇格されると、データベースオペレーションが発生したときに既存のイベントトリガーが起動します。 + イベントトリガーを使用する PostgreSQL DB インスタンスへのメジャーバージョンアップグレードを実行する場合は、インスタンスのアップグレード前に必ずイベントトリガーを削除してください。 # RDS for PostgreSQL の ヒュージページ *Huge pages* はメモリ管理機能です。DB インスタンスが、共有バッファで使用されるような、大きく連続したメモリチャンクで動作しているときのオーバーヘッドを軽減します。この PostgreSQL の機能は、現在の PostgreSQL バージョンで利用可能なすべての RDS でサポートされています。`mmap`または`SYSV`共有メモリへの呼び出しを使用して、アプリケーションに巨大なページを割り当てます。RDS for PostgreSQL では、4 KB と 2 MB の両方のページサイズがサポートされています。 `huge_pages` パラメータの値を変更することで、Huge pages のオンとオフを切り替えることができます。この機能は、micro、small、medium 以外のすべての DB インスタンスクラスで、デフォルトでオンになっています。 RDS for PostgreSQL では、利用可能な共有メモリに基づき、ヒュージページを使用します。共有メモリの制約のために DB インスタンスが巨大なページを使用できない場合、Amazon RDS は DB インスタンスの起動を防ぎます。この場合、Amazon RDS により、DB インスタンスのステータスが互換性のないパラメータ状態に設定されます。これが起こると、`huge_pages`パラメータを`off`に設定して Amazon RDS で DB インスタンスの起動を許可します。 `shared_buffers` パラメータは huge ページを使用するために必要な共有メモリプールの設定に重要です。`shared_buffers`パラメータのデフォルト値は、データベースパラメータマクロを使用します。このマクロは、DB インスタンスのメモリで使用できる 8 KBのページの合計のパーセント割合を設定します。巨大なページを使用する場合、それらのページは巨大なページと一緒に配置されます。共有メモリパラメータで DB インスタンスの 90 パーセントを超えるメモリを使用するように設定すると、Amazon RDS は DB インスタンスを互換性のないパラメータ状態に設定します。 PostgreSQL のメモリ管理については、PostgreSQL のドキュメントの「[Resource Consumption](https://www.postgresql.org/docs/current/static/runtime-config-resource.html)」(資源の消費) を参照してください。 # Amazon RDS for PostgreSQL の論理レプリケーションの実行 バージョン 10.4 以降、RDS for PostgreSQL は、PostgreSQL 10 で導入されたパブリケーションおよびサブスクリプション SQL 構文をサポートしています。詳細については、「PostgreSQL のドキュメント」の「[論理レプリケーション](https://www.postgresql.org/docs/current/logical-replication.html)」を参照してください。 **注記** PostgreSQL 10 で導入されたネイティブの PostgreSQL 論理レプリケーション機能に加えて、PostgreSQL 用 RDS は `pglogical` 拡張機能もサポートしています。詳細については、「[pglogical を使用してインスタンス間でデータを同期する](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)」を参照してください。 RDS for PostgreSQL DB インスタンスに対する論理レプリケーションの設定については、次で説明します。 **Topics** + [論理レプリケーションと論理デコードについて](#PostgreSQL.Concepts.General.FeatureSupport.LogicalDecoding) + [論理的なレプリケーションスロットの使用](#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots) + [論理レプリケーションを使用したテーブルレベルのデータのレプリケーション](#PostgreSQL.Concepts.LogicalReplication.Tables) ## 論理レプリケーションと論理デコードについて RDS for PostgreSQL は、PostgreSQL の論理レプリケーションスロットを使用した、ログ先行書き込み (WAL) 変更のストリーミングをサポートしています。また、ロジカルデコーディングの使用もサポートしています。インスタンスで論理的なレプリケーションスロットをセットアップし、それらのスロットを通じてデータベースの変更を `pg_recvlogical` などのクライアントにストリーミングできます。データベースレベルで論理レプリケーションスロットを作成すると、1 つのデータベースへのレプリケーション接続がサポートされます。 PostgreSQL 論理レプリケーション用の最も一般的なクライアントは、AWS Database Migration Service、または Amazon EC2 インスタンスのカスタム管理ホストです。論理レプリケーションスロットには、ストリームの受信者に関する情報が含まれていません。また、ターゲットをレプリカデータベースとする必要はありません。論理的なレプリケーションスロットをセットアップし、スロットから読み取りを行わない場合、データが書き込まれて、DB インスタンスのストレージがすぐにいっぱいになる可能性があります。 パラメータ、レプリケーション接続タイプ、およびセキュリティロールを使用して、Amazon RDS の PostgreSQL 論理レプリケーションおよび論理デコードをオンにします。論理デコード用のクライアントは、PostgreSQL DB インスタンスのデータベースにレプリケーション接続を確立できる任意のクライアントとすることができます。 **RDS for PostgreSQL DB インスタンスに対して論理デコードをオンにするには** 1. 使用しているユーザーアカウントに次のロールがあることを確認します。 + 論理レプリケーションをオンにできるようにする `rds_superuser` ロール + 論理スロットを管理し、論理スロットを使用してデータをストリーミングするためのアクセス許可を付与する `rds_replication` ロール 1. `rds.logical_replication` 静的パラメータを 1 に設定します。このパラメータを適用する一環として、`wal_level`、`max_wal_senders`、`max_replication_slots`、`max_connections` の各パラメータも設定します。これらのパラメータの変更により、生成される WAL が増えることがあるため、論理スロットを使用する場合にのみ、`rds.logical_replication` パラメータを設定してください。 1. 静的 `rds.logical_replication` パラメータの DB インスタンスを再起動して有効にします。 1. 次のセクションの説明に従って論理的なレプリケーションスロットを作成します。このプロセスでは、デコードプラグインを指定する必要があります。現在、RDS for PostgreSQL は、PostgreSQL に付属する出力プラグイン test\$1decoding および wal2json をサポートしています。 PostgreSQL 論理的なデコードの使用の詳細については、[PostgreSQL のドキュメント](https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html)を参照してください。 ## 論理的なレプリケーションスロットの使用 SQL コマンドを使用して、論理的なスロットを操作できます。例えば、次のコマンドは、デフォルトの PostgreSQL 出力プラグイン `test_slot` を使用して、`test_decoding` という論理的なスロットを作成します。 ``` SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding'); slot_name | xlog_position -----------------+--------------- regression_slot | 0/16B1970 (1 row) ``` 論理的なスロットを一覧表示するには、次のコマンドを使用します。 ``` SELECT * FROM pg_replication_slots; ``` 論理的なスロットを削除するには、次のコマンドを使用します。 ``` SELECT pg_drop_replication_slot('test_slot'); pg_drop_replication_slot ----------------------- (1 row) ``` 論理的なレプリケーションスロットのその他の使用例については、PostgreSQL ドキュメントの「[Logical Decoding Examples](https://www.postgresql.org/docs/9.5/static/logicaldecoding-example.html)」を参照してください。 論理的なレプリケーションスロットを作成すると、ストリーミングをスタートできます。次の例は、ストリーミングレプリケーションプロトコルで論理的なデコードがどのように制御されるかを示しています。この例では、PostgreSQL ディストリビューションに含まれているプログラム pg\$1recvlogical を使用しています。これを行うには、レプリケーション接続を許可するようにクライアント認証が設定されている必要があります。 ``` pg_recvlogical -d postgres --slot test_slot -U postgres --host -instance-name.111122223333.aws-region.rds.amazonaws.com -f - --start ``` `pg_replication_origin_status`ビューの内容を表示するには、`pg_show_replication_origin_status` 関数を照会します。 ``` SELECT * FROM pg_show_replication_origin_status(); local_id | external_id | remote_lsn | local_lsn ----------+-------------+------------+----------- (0 rows) ``` ## 論理レプリケーションを使用したテーブルレベルのデータのレプリケーション 論理レプリケーションを使用して、RDS for PostgreSQL のソーステーブルからターゲットテーブルにデータをレプリケートできます。論理レプリケーションは、まずソーステーブルから既存のデータの初期ロードを実行し、引き続いて以降の変更をレプリケートします。 1. **ソーステーブルを作成する** RDS for PostgreSQL DB インスタンスのソースデータベースに接続します。 ``` source=> CREATE TABLE testtab (slno int primary key); CREATE TABLE ``` 1. **ソーステーブルにデータを挿入する** ``` source=> INSERT INTO testtab VALUES (generate_series(1,1000)); INSERT 0 1000 ``` 1. **ソーステーブルのパブリケーションを作成する** + ソーステーブルのパブリケーションを作成します。 ``` source=> CREATE PUBLICATION testpub FOR TABLE testtab; CREATE PUBLICATION ``` + SELECT クエリを使用して、作成したパブリケーションの詳細を確認します。 ``` source=> SELECT * FROM pg_publication; oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot --------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------ 115069 | testpub | 16395 | f | t | t | t | t | f (1 row) ``` + ソーステーブルがパブリケーションに追加されていることを確認します。 ``` source=> SELECT * FROM pg_publication_tables; pubname | schemaname | tablename ---------+------------+----------- testpub | public | testtab (1 rows) ``` + データベース内のすべてのテーブルをレプリケートするには、以下を使用します。 ``` CREATE PUBLICATION testpub FOR ALL TABLES; ``` + パブリケーションが個々のテーブル用に既に作成されており、新しいテーブルを追加する必要がある場合は、以下のクエリを実行して、既存のパブリケーションに新しいテーブルを追加できます。 ``` ALTER PUBLICATION add table ; ``` 1. **ターゲットデータベースに接続し、ターゲットテーブルを作成する** + ターゲット DB インスタンスのターゲットデータベースに接続します。ソーステーブルと同じ名前でターゲットテーブルを作成します。 ``` target=> CREATE TABLE testtab (slno int primary key); CREATE TABLE ``` + ターゲットテーブルに対して SELECT クエリを実行し、ターゲットテーブルにデータが存在しないことを確認します。 ``` target=> SELECT count(*) FROM testtab; count ------- 0 (1 row) ``` 1. **ターゲットデータベースでサブスクリプションを作成および検証する** + ターゲットデータベースにサブスクリプションを作成します。 ``` target=> CREATE SUBSCRIPTION testsub CONNECTION 'host= port=5432 dbname= user= password=' PUBLICATION testpub; NOTICE: Created replication slot "testsub" on publisher CREATE SUBSCRIPTION ``` + SELECT クエリを使用して、サブスクリプションが有効になっていることを確認します。 ``` target=> SELECT oid, subname, subenabled, subslotname, subpublications FROM pg_subscription; oid | subname | subenabled | subslotname | subpublications -------+---------+------------+-------------+----------------- 16434 | testsub | t | testsub | {testpub} (1 row) ``` + サブスクリプションが作成されると、ソーステーブルからターゲットテーブルにすべてのデータがロードされます。ターゲットテーブルに対して SELECT クエリを実行し、初期データがロードされていることを確認します。 ``` target=> SELECT count(*) FROM testtab; count ------- 1000 (1 row) ``` 1. **ソースデータベースのレプリケーションスロットを確認する** ターゲットデータベースにサブスクリプションを作成すると、ソースデータベースにレプリケーションスロットが作成されます。ソースデータベースに対して次の SELECT クエリを実行して、レプリケーションスロットの詳細を確認します。 ``` source=> 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 ----------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+--------------- testsub | pgoutput | logical | 115048 | source | f | t | 846 | | 6945 | 58/B4000568 | 58/B40005A0 | reserved | (1 row) ``` 1. **レプリケーションのテスト** + ソーステーブルに行を挿入して、ソーステーブルのデータ変更がターゲットテーブルにレプリケートされているかどうかをテストします。 ``` source=> INSERT INTO testtab VALUES(generate_series(1001,2000)); INSERT 0 1000 source=> SELECT count(*) FROM testtab; count ------- 2000 (1 row) ``` + ターゲットテーブル内の行数を確認して、新しい挿入がレプリケートされていることを確認します。 ``` target=> SELECT count(*) FROM testtab; count ------- 2000 (1 row) ``` 1. **テーブルを追加した後のサブスクリプションの更新** + 既存のパブリケーションに新しいテーブルを追加する場合、変更を有効にするにはサブスクリプションを更新する必要があります。 ``` ALTER SUBSCRIPTION REFRESH PUBLICATION; ``` + このコマンドは、パブリッシャーから欠落しているテーブル情報を取得し、サブスクリプションの作成または最終更新以降にサブスクライブ先のパブリケーションに追加されたテーブルのレプリケーションを開始します。 # 論理レプリケーション接続の IAM 認証の設定 RDS for PostgreSQL バージョン 11 以降では、レプリケーション接続に AWS Identity and Access Management (IAM) 認証を使用できます。この機能は、パスワードの代わりに IAM ロールを使用してデータベースアクセスを管理できるようにすることで、セキュリティを強化します。クラスターとインスタンスの両方の粒度で動作し、標準の IAM 認証と同じセキュリティモデルに従います。 レプリケーション接続の IAM 認証はオプトイン機能です。有効にするには、DB クラスターまたは DB パラメータグループの `rds.iam_auth_for_replication` パラメータを 1 に設定します。これは動的パラメータであるため、DB クラスターまたはインスタンスを再起動する必要がなく、ダウンタイムなしで既存のワークロードで IAM 認証を活用できます。この機能を有効にする前に、以下の前提条件を満たす必要があります。 **Topics** + [前提条件](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites) + [レプリケーション接続の IAM 認証の有効化](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Enabling) + [レプリケーション接続の IAM 認証の無効化](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Disabling) + [制約事項と考慮事項](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Limitations) ## 前提条件 レプリケーション接続に IAM 認証を使用するには、以下のすべての要件を満たす必要があります。 + RDS for PostgreSQL DB インスタンスはバージョン 11 以降である必要があります。 + パブリッシャー RDS for PostgreSQL DB インスタンスの場合: + IAM データベース認証を有効にする。詳細については、「[IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)」を参照してください。 + `rds.logical_replication` パラメータを 1 に設定して、論理レプリケーションを有効にします。 論理レプリケーションでは、パブリッシャーはサブスクライバーデータベースにデータを送信するソース RDS for PostgreSQL データベースです。詳細については、「[Amazon RDS for PostgreSQL の論理レプリケーションの実行](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md)」を参照してください。 **注記** パブリッシャー RDS for PostgreSQL DB インスタンスで IAM 認証と論理レプリケーションの両方を有効にする必要があります。どちらかが有効になっていない場合、レプリケーション接続に IAM 認証を使用することはできません。 ## レプリケーション接続の IAM 認証の有効化 レプリケーション接続の IAM 認証を有効にするには、次の手順を実行します。 **レプリケーション接続の IAM 認証を有効にするには** 1. RDS for PostgreSQL DB クラスターまたはインスタンスが、レプリケーション接続による IAM 認証のすべての前提条件を満たしていることを確認します。詳細については、「[前提条件](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites)」を参照してください。 1. RDS for PostgreSQL の設定に基づいて `rds.iam_auth_for_replication` パラメータを設定します。 + RDS for PostgreSQL DB インスタンスの場合: DB パラメータグループを変更します。 + マルチ AZ クラスターの場合: DB クラスターパラメータグループを変更します。 `rds.iam_auth_for_replication` を 1 に設定します。これは、再起動を必要とせずにすぐに有効になる動的パラメータです。 **注記** マルチ AZ クラスターは、DB クラスターパラメータグループのみを使用します。マルチ AZ クラスターでは、個々のインスタンスパラメータグループを変更することはできません。 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 インスタンスの DB パラメータグループまたはマルチ AZ クラスターの DB クラスターパラメータグループで、`rds.iam_auth_for_replication` パラメータを 0 に設定します。 + または、RDS for PostgreSQL DB クラスターまたはインスタンスで次のいずれかの機能を無効にすることもできます。 + `rds.logical_replication` パラメータを 0 に設定して論理レプリケーションを無効にする + IAM 認証の無効化 この機能を無効にすると、レプリケーション接続では認証にデータベースパスワードを使用できるようになります。 **注記** `rds_iam` ロールを持たないユーザーのレプリケーション接続は、この機能が有効になっている場合でもパスワード認証を使用できます。 ## 制約事項と考慮事項 論理レプリケーション接続に IAM 認証を使用する場合、以下の制限と考慮事項を考慮してください。 + この機能は、RDS for PostgreSQL バージョン 11 以降でのみ使用できます。 + パブリッシャーは、レプリケーション接続の IAM 認証をサポートする必要があります。 + IAM 認証トークンは、デフォルトで 15 分後に期限切れになります。トークンの有効期限が切れる前に、長時間実行されるレプリケーション接続を更新する必要がある場合があります。 # stats\$1temp\$1directory の RAM ディスク RDS for PostgreSQL パラメータ `rds.pg_stat_ramdisk_size` を使用して、PostgreSQL `stats_temp_directory` を保存する RAM ディスクに割り当てられたシステムメモリを指定できます。RAM ディスクパラメータは、RDS for PostgreSQL バージョン 14 以下のバージョンでのみ利用できます。 特定のワークロードでは、このパラメータを設定することでパフォーマンスが向上し、I/O 要件を軽減することができます。`stats_temp_directory` の詳細については、[PostgreSQL のドキュメント](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY)を参照してください。 `stats_temp_directory` の RAM ディスクをセットアップにするには、`rds.pg_stat_ramdisk_size` パラメータを、DB インスタンスで使用されるパラメータグループの整数リテラル値に設定します。このパラメータは MB を表すため、整数値を使用する必要があります。表現、数式、関数が `rds.pg_stat_ramdisk_size` パラメータに対して有効ではありません。変更が反映されるように、DB インスタンスを再起動してください。パラメータの設定の詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。 例えば、次の AWS CLI コマンドは、RAM ディスクパラメータを 256 MB に設定します。 ``` aws rds modify-db-parameter-group \ --db-parameter-group-name pg-95-ramdisk-testing \ --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot" ``` 再起動後は、次のコマンドを実行して `stats_temp_directory` のステータスを確認します。 ``` postgres=> SHOW stats_temp_directory; ``` コマンドは次の情報を返します。 ``` stats_temp_directory --------------------------- /rdsdbramdisk/pg_stat_tmp (1 row) ``` # RDS for PostgreSQL のテーブルスペース RDS for PostgreSQL では、互換性のためにテーブルスペースがサポートされています。すべてのストレージが 1 つの論理ボリューム上にあるため、I/O 分割または分離にテーブルスペースを使用することはできません。当社のベンチマークと経験は、ほとんどのユースケースで 単一の論理的なボリュームが最適なセットアップであることを示しています。 RDS for PostgreSQL DB インスタンスでテーブルスペースを作成して使用するには、`rds_superuser` ロール が必要です。RDS for PostgreSQL DB インスタンスのメインユーザーアカウント (デフォルトの名前は `postgres`) は、このロールのメンバーです。詳細については、「[PostgreSQL のロールとアクセス権限について](Appendix.PostgreSQL.CommonDBATasks.Roles.md)」を参照してください。 表空間の作成時にファイル名を指定する場合、パスの接頭辞は `/rdsdbdata/db/base/tablespace` になります。次の例では、`/rdsdbdata/db/base/tablespace/data`に表空間ファイルを配置しています。この例では、`dbadmin` ユーザー (ロール) が存在し、テーブルスペースの操作に必要な `rds_superuser` ロールが付与されていることを前提としています。 ``` postgres=> CREATE TABLESPACE act_data OWNER dbadmin LOCATION '/data'; CREATE TABLESPACE ``` PostgreSQL テーブルスペースの詳細については、PostgreSQL のドキュメントの「[Tablespaces](https://www.postgresql.org/docs/current/manage-ag-tablespaces.html)」(テーブル空間) を参照してください。 # EBCDIC やその他のメインフレーム移行のための RDS for PostgreSQL 照合順序 RDS for PostgreSQL バージョン 10 以降には ICU バージョン 60.2 が含まれています。これは Unicode 10.0 に基づいており、Unicode Common Locale Data Repositor、CLDR 32 からの照合順序が含まれています。これらのソフトウェア国際化ライブラリにより、オペレーティングシステムやプラットフォームに関係なく、文字エンコーディングが一貫した方法で表示されます。Unicode CLDR-32 の詳細については、Unicode CLDR のウェブサイトの「[CLDR 32 リリースノート](https://cldr.unicode.org/index/downloads/cldr-32)」を参照してください。Unicode の国際化コンポーネント (ICU) については、[ICU 技術委員会 (ICU-TC)](https://icu.unicode.org/home) のウェブサイトで詳しく説明されています。ICU-60 の詳細については、「[ICU 60 のダウンロード](https://icu.unicode.org/download/60)」を参照してください。 バージョン 14.3 以降、RDS for PostgreSQL には、EBCDIC ベースのシステムからのデータ統合と変換に役立つ照合順序も含まれています。Extended Binary Coded Decimal Interchange Code (*EBCDIC*) エンコーディングはメインフレームのオペレーティングシステムで一般的に使用されます。マッピングAmazon RDS が提供するこれらの照合順序は、EBCDIC コードページに直接マッピングされる Unicode 文字のみをソートするように狭義に定義されています。文字は、変換後のデータ検証を可能にするために、EBCDIC コードポイント順にソートされます。これらの照合順序には、非正規化された形式や、ソース EBCDIC コードページの文字に直接マッピングされない Unicode 文字は含まれていません。 EBCDIC コードページと Unicode コードポイント間の文字マッピングは、IBM が公開している表に基づいています。一式は、IBM から[圧縮ファイル](http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip)としてダウンロード可能です。RDS for PostgreSQL は、ICU から提供されたツールでこれらのマッピングを使用して、このセクションの表にリストされている照合順序を作成しました。照合順序名には、ICU が要求する言語と国が含まれます。ただし、EBCDIC コードページでは言語が指定されておらず、一部の EBCDIC コードページは複数の国を対象としています。つまり、テーブル内の照合名の言語と国の部分は任意であり、現在のロケールと一致する必要はありません。つまり、コードページ番号はこの表の照合順序名の最も重要な部分です。次の表に示す照合順序は、どの RDS for PostgreSQL データベースでも使用できます。 + [Unicode to EBCDIC collations table](#ebcdic-table) — メインフレームのデータ移行ツールの中には、LATIN1 または LATIN9 を内部的に使用してデータのエンコードと処理を行うものがあります。こういったツールは、ラウンドトリップスキームを使用してデータの整合性を維持し、逆変換をサポートします。この表の照合順序は、特別な処理を必要としない LATIN1 エンコーディングを使用してデータを処理するツールで使用できます。 + [Unicode to LATIN9 collations table](#latin9-table) — これらの照合順序は、どの RDS for PostgreSQL データベースでも使用できます。 次の表に、EBCDIC コードページを Unicode コードポイントにマッピングする RDS for PostgreSQL の照合順序を示します。IBM コードページの順序に基づいてソートする必要があるアプリケーション開発には、この表の照合順序を使用することをお勧めします。 | PostgreSQL 照合順序名 | コードページのマッピングとソート順序の説明 | | --- | --- | | da-DK-cp277-x-icu | IBM EBCDIC コードページ 277 (変換表ごと) に直接マッピングされる Unicode 文字は、IBM CP 277 コードポイント順にソートされます。 | | de-DE-cp273-x-icu | IBM EBCDIC コードページ 273 (変換表ごと) に直接マッピングされる Unicode 文字は、IBM CP 273 コードポイント順にソートされます。 | | en-GB-cp285-x-icu | IBM EBCDIC コードページ 285 (変換表ごと) に直接マッピングされる Unicode 文字は、IBM CP 285 コードポイント順にソートされます。 | | en-US-cp037-x-icu | IBM EBCDIC コードページ 037 (変換表ごと) に直接マッピングされる Unicode 文字は、IBM CP 037 コードポイント順にソートされます。 | | es-ES-cp284-x-icu | IBM EBCDIC コードページ 284 (変換表ごと) に直接マッピングされる Unicode 文字は、IBM CP 284 コードポイント順にソートされます。 | | fi-FI-cp278-x-icu | IBM EBCDIC コードページ 278 (変換表ごと) に直接マップされる Unicode 文字は、IBM CP 278 コードポイント順にソートされます。 | | fr-fr-cp297-X-ICU | IBM EBCDIC コードページ 297 (変換表ごと) に直接マップされる Unicode 文字は、IBM CP 297 コードポイント順にソートされます | | it-IT-cp280-x-icu | IBM EBCDIC コードページ 280 (変換表ごと) に直接マップされる Unicode 文字は、IBM CP 280 コードポイント順にソートされます | | nl-BE-cp500-x-icu | IBM EBCDIC コードページ 500 (変換テーブルごと) に直接マップされる Unicode 文字は、IBM CP 500 コードポイント順にソートされます | Amazon RDS には、IBM が公開しているテーブルを使用して、LATIN9 文字にマッピングされる Unicode コードポイントをソースデータの EBCDIC コードページに従って元のコードポイントの順序でソートする追加の照合セットが用意されています。 | PostgreSQL 照合順序名 | コードページのマッピングとソート順序の説明 | | --- | --- | | da-DK-cp1142m-x-icu | IBM EBCDIC コードページ 1142 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1142 コードポイント順にソートされます。 | | de-DE-cp1141m-x-icu | IBM EBCDIC コードページ 1141 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1141 コードポイント順にソートされます。 | | en-GB-cp1146m-x-icu | IBM EBCDIC コードページ 1146 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1146 コードポイント順にソートされます。 | | en-US-cp1140m-x-icu | IBM EBCDIC コードページ 1140 (変換テーブルごと) から最初に変換された LATIN9 文字にマップされる Unicode 文字は、IBM CP 1140 コードポイント順にソートされます。 | | es-ES-cp1145m-x-icu | IBM EBCDIC コードページ 1145 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1145 コードポイント順にソートされます。 | | fi-FI-cp1143m-x-icu | IBM EBCDIC コードページ 1143 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1143 コードポイント順にソートされます。 | | fr-FR-cp1147m-x-icu | IBM EBCDIC コードページ 1147 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1147 コードポイント順にソートされます。 | | it-IT-cp1144m-x-icu | IBM EBCDIC コードページ 1144 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1144 コードポイント順にソートされます。 | | nl-BE-cp1148m-x-icu | IBM EBCDIC コードページ 1148 (変換テーブルごと) から最初に変換された LATIN9 文字にマップされる Unicode 文字は、IBM CP 1148 コードポイント順にソートされます。 | 以下に、RDS for PostgreSQL 照合順序の使用例を示します。 ``` db1=> SELECT pg_import_system_collations('pg_catalog'); pg_import_system_collations ----------------------------- 36 db1=> SELECT '¤' < 'a' col1; col1 ------ t db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1; col1 ------ f ``` IBM コードページの順序に基づいてソートする必要があるアプリケーション開発には、[Unicode to EBCDIC collations table](#ebcdic-table) と [Unicode to LATIN9 collations table](#latin9-table) の照合順序を使用することをお勧めします。次の照合順序 (接尾辞に「b」の文字が付いている) は、`pg_collation` でも表示されますが、特定のコードポイントシフトを持つコードページをマッピングする AWS のメインフレームデータ統合および移行ツールで使用することを目的としており、照合順序で特別な処理が必要です。つまり、以下の照合順序の使用は推奨されません。 + da-DK-277b-x-icu + da-DK-1142b-x-icu + de-DE-cp273b-x-icu + de-DE-cp1141b-x-icu + en-GB-cp1146b-x-icu + en-GB-cp285b-x-icu + en-US-cp037b-x-icu + en-US-cp1140b-x-icu + es-ES-cp1145b-x-icu + es-ES-cp284b-x-icu + fi-FI-cp1143b-x-icu + fr-FR-cp1147b-x-icu + fr-FR-cp297b-x-icu + it-IT-cp1144b-x-icu + it-IT-cp280b-x-icu + nl-BE-cp1148b-x-icu + nl-BE-cp500b-x-icu メインフレーム環境から AWS へのアプリケーションの移行に関する詳細については、[「AWSMainframe Modernization とは?」](https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.html)を参照してください。 PostgreSQL における照合順序の管理の詳細については、PostgreSQL のドキュメントの「[Collation Support](https://www.postgresql.org/docs/current/collation.html)」(照合順序のサポート) を参照してください。 # RDS for PostgreSQL の論理スロット同期の管理 コミュニティ PostgreSQL 17 以降、プライマリサーバーからスタンバイサーバーに論理レプリケーションスロットを自動的に同期する新機能が、パラメータ `sync_replication_slots` や関連する関数 `pg_sync_replication_slots()` を通じて導入されました。これは、実行時にスロットを手動で同期します。 これらの機能は、RDS for PostgreSQL 17 以降で使用できます。一般的なセットアップには、プライマリインスタンスとその[リードレプリカ](USER_PostgreSQL.Replication.ReadReplicas.md)と、プライマリへの論理レプリケーションサブスクライバーがあります。 サブスクリプションがフェイルオーバーオプションを true に設定して作成されていることを確認します。 ``` CREATE SUBSCRIPTION subname CONNECTION 'host=...' PUBLICATION pubname WITH (failover = true); ``` これにより、フェイルオーバーを有効にした状態でパブリッシャーに論理スロットが作成されます。 ``` postgres=> SELECT slot_name, slot_type, failover FROM pg_catalog.pg_replication_slots; slot_name | slot_type | failover -----------+-----------+---------- subname | logical | t (1 row) ``` スロット同期を有効にすると、プライマリのすべてのフェイルオーバー論理レプリケーションスロットが物理スタンバイに自動的に作成され、定期的に同期されます。[パラメータグループ](USER_WorkingWithParamGroups.Associating.md)を通じて次の値が設定されていることを確認します。 + 論理レプリケーションを有効にするには `rds.logical_replication` が `1` である必要があります。 + `hot_standby_feedback` はスタンバイ時に `1` である必要があります。 + スタンバイの `rds.logical_slot_sync_dbname` には有効なデータベース名を設定する必要があります。 パラメータのデフォルト値は `postgres` です。論理パブリッシングインスタンスに `postgres` データベースがある場合、デフォルトのパラメータを変更する必要はありません。 + プライマリの `synchronized_standby_slots` は、同期するスタンバイの物理レプリケーションスロットに設定する必要があります。 + 自動同期を有効にするには `sync_replication_slots` が `1` である必要があります。 フェイルオーバー対応のサブスクリプションスロットと上記のパラメータ値を使用すると、スタンバイが昇格したとき、サブスクライバーはサブスクリプションをこの新しく昇格されたインスタンスに変更し、論理レプリケーションをシームレスに続行できます。