Amazon RDS for PostgreSQL でサポートされている PostgreSQL の機能を使用する - Amazon Relational Database Service

Amazon RDS for PostgreSQL でサポートされている PostgreSQL の機能を使用する

Amazon RDS for PostgreSQL は、PostgreSQL の代表的な機能の多くをサポートしています。例えば、PostgreSQL には、データベースの定期的なメンテナンスを実行する自動バキューム機能があります。autovacuum 機能は、デフォルトでアクティブになっています。この機能をオフにすることはできますが、オンにしておくことを強くお勧めします。この機能を理解し、それを正しく動作させるために何ができるかを把握することは、どの DBA にとっても基本的なタスクです。自動バキュームの詳細については、「Amazon RDS for PostgreSQL での PostgreSQL 自動バキュームの使用」を参照してください。その他の一般的な DBA タスクの詳細については、「Amazon RDS for PostgreSQL の一般的な DBA タスク」を参照してください。

RDS for PostgreSQL では、DB インスタンスに重要な機能性を追加する拡張機能もサポートされています。例えば、PostGIS 拡張機能を使用して空間データを操作したり、pg_cron 拡張機能を使用してインスタンス内からメンテナンスをスケジュールしたりできます。PostgreSQL 拡張機能の詳細については、「Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用する」を参照してください。

外部データラッパーは、RDS for PostgreSQL DB インスタンスが他の商用データベースまたはデータ型と連携できるように設計された特定のタイプの拡張機能です。RDS for PostgreSQL でサポートされている外部データラッパーの詳細については、「Amazon RDS for PostgreSQL でサポートされている外部データラッパーを使用する」を参照してください。

RDS for PostgreSQL でサポートされているその他の機能については、次で説明します。

RDS for PostgreSQL でのカスタムデータ型および列挙型

PostgreSQL では、カスタムデータ型の作成と列挙型の操作がサポートされています。列挙型とその他のデータ型の作成および操作の詳細については、「PostgreSQL のドキュメント」の「列挙型」を参照してください。

次は、列挙型として型を作成し、テーブルに値を挿入する例です。

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」を参照してください。

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」(資源の消費) を参照してください。

Amazon RDS for PostgreSQL の論理レプリケーションの実行

バージョン 10.4 以降、RDS for PostgreSQL は、PostgreSQL 10 で導入されたパブリケーションおよびサブスクリプション SQL 構文をサポートしています。詳細については、「PostgreSQL のドキュメント」の「論理レプリケーション」を参照してください。

注記

PostgreSQL 10 で導入されたネイティブの PostgreSQL 論理レプリケーション機能に加えて、PostgreSQL 用 RDS は pglogical 拡張機能もサポートしています。詳細については、「pglogical を使用してインスタンス間でデータを同期する」を参照してください。

RDS for PostgreSQL DB インスタンスに対する論理レプリケーションの設定については、次で説明します。

論理レプリケーションと論理デコードについて

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 ロール

  2. rds.logical_replication 静的パラメータを 1 に設定します。このパラメータを適用する一環として、wal_levelmax_wal_sendersmax_replication_slotsmax_connections の各パラメータも設定します。これらのパラメータの変更により、生成される WAL が増えることがあるため、論理スロットを使用する場合にのみ、rds.logical_replication パラメータを設定してください。

  3. 静的 rds.logical_replication パラメータの DB インスタンスを再起動して有効にします。

  4. 次のセクションの説明に従って論理的なレプリケーションスロットを作成します。このプロセスでは、デコードプラグインを指定する必要があります。現在、RDS for PostgreSQL は、PostgreSQL に付属する出力プラグイン test_decoding および wal2json をサポートしています。

PostgreSQL 論理的なデコードの使用の詳細については、PostgreSQL のドキュメントを参照してください。

論理的なレプリケーションスロットの使用

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」を参照してください。

論理的なレプリケーションスロットを作成すると、ストリーミングをスタートできます。次の例は、ストリーミングレプリケーションプロトコルで論理的なデコードがどのように制御されるかを示しています。この例では、PostgreSQL ディストリビューションに含まれているプログラム pg_recvlogical を使用しています。これを行うには、レプリケーション接続を許可するようにクライアント認証が設定されている必要があります。

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)

stats_temp_directory の RAM ディスク

RDS for PostgreSQL パラメータ rds.pg_stat_ramdisk_size を使用して、PostgreSQL stats_temp_directory を保存する RAM ディスクに割り当てられたシステムメモリを指定できます。RAM ディスクパラメータは、Amazon RDS のすべての PostgreSQL バージョンで利用できます。

特定のワークロードでは、このパラメータを設定することでパフォーマンスが向上し、I/O 要件を軽減することができます。stats_temp_directory の詳細については、PostgreSQL のドキュメントを参照してください。

stats_temp_directory の RAM ディスクをセットアップにするには、rds.pg_stat_ramdisk_size パラメータを、DB インスタンスで使用されるパラメータグループの整数リテラル値に設定します。このパラメータは MB を表すため、整数値を使用する必要があります。表現、数式、関数が rds.pg_stat_ramdisk_size パラメータに対して有効ではありません。変更が反映されるように、DB インスタンスを再起動してください。パラメータの設定の詳細については、「「パラメータグループを使用する」 」を参照してください。

例えば、次の 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 のロールとアクセス権限について」を参照してください。

表空間の作成時にファイル名を指定する場合、パスの接頭辞は /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」(テーブル空間) を参照してください。

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 リリースノート」を参照してください。Unicode の国際化コンポーネント (ICU) については、ICU 技術委員会 (ICU-TC) のウェブサイトで詳しく説明されています。ICU-60 の詳細については、「ICU 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 から圧縮ファイルとしてダウンロード可能です。RDS for PostgreSQL は、ICU から提供されたツールでこれらのマッピングを使用して、このセクションの表にリストされている照合順序を作成しました。照合順序名には、ICU が要求する言語と国が含まれます。ただし、EBCDIC コードページでは言語が指定されておらず、一部の EBCDIC コードページは複数の国を対象としています。つまり、テーブル内の照合名の言語と国の部分は任意であり、現在のロケールと一致する必要はありません。つまり、コードページ番号はこの表の照合順序名の最も重要な部分です。次の表に示す照合順序は、どの RDS for PostgreSQL データベースでも使用できます。

  • Unicode to EBCDIC collations table — メインフレームのデータ移行ツールの中には、LATIN1 または LATIN9 を内部的に使用してデータのエンコードと処理を行うものがあります。こういったツールは、ラウンドトリップスキームを使用してデータの整合性を維持し、逆変換をサポートします。この表の照合順序は、特別な処理を必要としない LATIN1 エンコーディングを使用してデータを処理するツールで使用できます。

  • Unicode to LATIN9 collations 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 tableUnicode to LATIN9 collations 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 とは?」を参照してください。

PostgreSQL における照合順序の管理の詳細については、PostgreSQL のドキュメントの「Collation Support」(照合順序のサポート) を参照してください。