Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用する
PostgreSQL は、さまざまな拡張機能やモジュールをインストールすることで、機能を拡張することができます。例えば、空間データを操作するには、PostGIS 拡張機能をインストールして使用します。詳細については、「PostGIS 拡張機能を使用した空間データの管理」を参照してください。別の例として、非常に大きなテーブルへのデータ入力を改善する場合は、pg_partman
拡張機能を使用したデータのパーティション化を検討できます。詳細については、「pg_partman エクステンションによる PostgreSQL パーティションの管理」を参照してください。
RDS for PostgreSQL 14.5 以降、RDS for PostgreSQL は Trusted Language Extensions for PostgreSQL をサポートしています。この機能は拡張機能 pg_tle
として実装され、RDS for PostgreSQL DB インスタンスに追加できます。この拡張を使用することで、開発者は安全な環境で独自の PostgreSQL 拡張を作成できるため、セットアップと設定の要件が簡素化されます。詳細については、「Trusted Language Extensions for PostgreSQL を使用した操作」を参照してください。
場合によっては、拡張機能をインストールする代わりに、Aurora PostgreSQL DB クラスターのカスタム DB クラスターパラメータグループの shared_preload_libraries
リストに特定のモジュールを追加することもできます。通常、デフォルトの DB クラスターパラメータグループでは、pg_stat_statements
のみが読み込まれますが、リストに追加できるモジュールは他にもいくつかあります。例えば、PostgreSQL pg_cron エクステンションによるメンテナンスのスケジューリング で説明されているように、pg_cron
モジュールを追加することでスケジュール機能を追加できます。別の例として、auto_explain
モジュールをロードすることでクエリ実行計画を記録できます。詳細については、AWS ナレッジセンターの「クエリ実行計画のログ記録
RDS for PostgreSQL のバージョンによっては、拡張機能をインストールする際に、以下のような rds_superuser
の権限が必要になる場合があります。
RDS for PostgreSQL バージョン 12 以前のバージョンでは、拡張機能をインストールする際に
rds_superuser
の権限が必要となります。RDS for PostgreSQL バージョン 13 以降のバージョンでは、特定のデータベースインスタンスに対する作成権限を持つユーザー (ロール) は、信頼できる拡張機能をインストールして使用することができます。信頼できる拡張機能のリストについては、「PostgreSQL 信頼できるエクステンション」を参照してください。
また、RDS for PostgreSQL DBインスタンスにインストール可能な拡張機能は、rds.allowed_extensions
パラメータにリストアップして、正確に指定することができます。デフォルトでは、このパラメータは設定されていないため、ユーザーに権限がある場合は、サポートされている任意の拡張機能を追加できます。このパラメータに拡張機能のリストを追加すると、RDS for PostgreSQL DB インスタンスで使用できる拡張機能が明示的に特定できます。一覧にない拡張機能はインストールできません。この機能は、以下のバージョンで利用できます。
-
RDS for PostgreSQL バージョン 14.1 以降のバージョン
-
RDS for PostgreSQL 13.3 またはそれ以降のマイナーバージョン
-
RDS for PostgreSQL 12.7 またはそれ以降のマイナーバージョン
詳細については、「PostgreSQL エクステンションのインストールを制限する」を参照してください。
rds_superuser
ロールの詳細については、「PostgreSQL のロールとアクセス権限について」を参照してください。
トピック
orafce 拡張機能の関数の使用
orafce 拡張機能は、Oracle データベースから関数とパッケージのサブセットをエミュレートする関数と演算子を提供します。Oracle 拡張機能を使用すると、Oracle アプリケーションを PostgreSQL に簡単に移植できます。この拡張機能は、RDS for PostgreSQL バージョン 9.6.6 以降でサポートされています。orafce についての詳細は、GitHub で「orafce
RDS for PostgreSQL では、orafce 拡張機能の一部である utl_file
パッケージがサポートされていません。これは、utl_file
スキーマ関数が、基になるモストへのスーパーユーザーアクセスに必要なオペレーティングシステムテキストファイルで読み書き操作を実行するためです。マネージド型サービスの RDS for PostgreSQL では、ホストアクセスが許可されません。
orafce エクステンションを使用するには
DB インスタンスの作成で使用したプライマリユーザー名を使用して DB インスタンスに接続します。
同じ DB インスタンスにある別のデータベースで orafce をオンにする場合は、
/c dbname
psql コマンドを使用します。このコマンドを使用すると、接続を開始した後にプライマリデータベースから変更できます。CREATE EXTENSION
ステートメントを使用して、orafce 拡張機能をオンにします。CREATE EXTENSION orafce;
ALTER SCHEMA
ステートメントを使用して、oracle スキーマの所有権を rds_superuser ロールに転送します。ALTER SCHEMA oracle OWNER TO rds_superuser;
oracle スキーマの所有者のリストを表示する場合は、
\dn
psql コマンドを使用します。
pgAudit を使用してデータベースのアクティビティを記録する
金融機関、政府機関、および多くの業界では、規制要件を満たすために監査ログを保存する必要があります。 RDS for PostgreSQL DB インスタンスで PostgreSQL 監査拡張機能 (pgAudit) を使用することで、監査人が通常必要とする詳細なレコードや規制要件を満たすための詳細なレコードをキャプチャできます。例えば、pgAudit 拡張機能を設定して、特定のデータベースやテーブルに加えられた変更を追跡したり、変更を加えたユーザーやその他の多くの詳細を記録したりできます。
pgAudit 拡張機能は、ログメッセージをより詳細に拡張することにより、ネイティブの PostgreSQL ログ記録インフラストラクチャの機能に基づいて構築されています。つまり、監査ログは、他のログメッセージを表示するのと同じ方法を使用します。PostgreSQL ログ記録の詳細については、「RDS for PostgreSQL データベースログファイル」を参照してください。
pgAudit 拡張機能は、クリアテキストパスワードなどの機密データをログから編集します。 RDS for PostgreSQL DB インスタンスが、RDS for PostgreSQL DB インスタンスのクエリログ記録をオンにする で説明されているようにデータ操作言語 (DML) ステートメントをログに記録するように設定されている場合は、PostgreSQL Audit 拡張機能を使用することでクリアテキストパスワードの問題を回避できます。
データベースインスタンスの監査は、きわめて詳細に構成できます。すべてのデータベースとすべてのユーザーを監査できます。また、特定のデータベース、ユーザー、その他のオブジェクトのみを監査することもできます。特定のユーザーやデータベースを監査対象から明示的に除外することもできます。詳細については、「監査ログからのユーザーまたはデータベースの除外」を参照してください。
キャプチャできる詳細の量を考慮すると、pgAudit を使用する場合はストレージ消費量を監視することをお勧めします。
pgAudit 拡張モジュールは、使用可能なすべての RDS for PostgreSQL バージョン。利用可能な RDS for PostgreSQL バージョンでサポートされている pgAudit バージョンのリストについては、Amazon RDS for PostgreSQL リリースノートの「Amazon RDS for PostgreSQL の拡張バージョン」を参照してください。
pgAudit 拡張機能のセットアップ
RDS for PostgreSQL DB インスタンス に pgAudit 拡張機能を設定するには、まず RDS for PostgreSQL DB インスタンスのカスタム DB パラメータグループの共有ライブラリに pgAudit を追加します。カスタム DB パラメータグループの作成については、「パラメータグループを使用する」を参照してください。次に、pgAudit 拡張機能をインストールします。最後に、監査するデータベースとオブジェクトを指定します。このセクションの手順で、方法を示します。AWS Management Console または AWS CLI を使用できます。
これらすべてのタスクを実行するには、rds_superuser
ロールとして権限が必要です。
以下の手順では、 RDS for PostgreSQL DB インスタンスがカスタム DB パラメータグループに関連付けられていることを前提としています。
pgAudit 拡張機能をセットアップするには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
ナビゲーションペインで、 RDS for PostgreSQL DB インスタンスを選択します。
-
の [Configuration] (設定) タブを開きます。RDS for PostgreSQL DB インスタンス。インスタンスの詳細の中から、パラメータグループのリンクを見つけてください。
-
リンクを選択して、に関連するカスタムパラメータを開きます。RDS for PostgreSQL DB インスタンス。
-
パラメータ検索フィールドに、
shared_pre
を入力してshared_preload_libraries
パラメータを検索します。 -
プロパティ値にアクセスするには、[Edit parameters] (パラメータの編集) を選択します。
-
[Values] (値) フィールドのリストに
pgaudit
を追加します。値のリスト内の項目を区切るにはカンマを使用します。 RDS for PostgreSQL DB instance を再起動して、
shared_preload_libraries
パラメータの変更を有効にします。インスタンスが使用可能になったら、pgAudit が初期化されていることを確認します。
psql
を使用して RDS for PostgreSQL DB インスタンスに接続し、次のコマンドを実行します。SHOW shared_preload_libraries;
shared_preload_libraries -------------------------- rdsutils,pgaudit (1 row)
pgAudit を初期化すると、拡張機能を作成できるようになりました。
pgaudit
拡張機能はデータ定義言語 (DDL) ステートメントを監査するためのイベントトリガーをインストールするため、ライブラリを初期化した後に拡張機能を作成する必要があります。CREATE EXTENSION pgaudit;
psql
セッションを終了します。labdb=>
\q
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 リストで
pgaudit.log
パラメータを検索し、ユースケースに応じた値に設定します。例えば、次の画像に示すようにpgaudit.log
パラメータをwrite
に設定すると、ログへの挿入、更新、削除、およびその他のタイプの変更がキャプチャされます。pgaudit.log
パラメータには、次のいずれかの値を選択することもできます。none – これはデフォルトです。データベースの変更は記録されません。
すべて — すべてをログに記録します (読み取り、書き込み、関数、ロール、DDL、その他)。
ddl –
ROLE
クラスに含まれていない、すべてのデータ定義言語 (DDL) ステートメントのログ記録。function – 関数呼び出し、および
DO
ブロックのログ記録。misc –
DISCARD
、FETCH
、CHECKPOINT
、VACUUM
、SET
など、さまざまなコマンドのログ記録。read –
SELECT
およびCOPY
のログ記録 (ソースがリレーション (テーブルなどの) またはクエリの場合)。role –
GRANT
、REVOKE
、CREATE ROLE
、ALTER ROLE
、DROP ROLE
など、ロールと権限に関連するステートメントのログ記録。write –
INSERT
、UPDATE
、DELETE
、TRUNCATE
、およびCOPY
のログ記録 (送信先がリレーション (テーブル) の場合)。
[Save changes] (変更の保存) をクリックします。
Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 データベースリストから RDS for PostgreSQL DB インスタンス を選択して選択し、アクションメニューから [Reboot] (再起動) を選択します。
pgAudit をセットアップするには
AWS CLI を使用して pgAudit を設定するには、次の手順に示すように、modify-db-parameter-group オペレーションを呼び出してカスタムパラメータグループの監査ログパラメータを変更します。
次の AWS CLI コマンドを使用して
shared_preload_libraries
パラメータにpgaudit
を追加します。aws rds modify-db-parameter-group \ --db-parameter-group-name
custom-param-group-name
\ --parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" \ --regionaws-region
-
次の AWS CLI コマンドを使用して RDS for PostgreSQL DB インスタンスを再起動し、pgaudit ライブラリを初期化します。
aws rds reboot-db-instance \ --db-instance-identifier
your-instance
\ --regionaws-region
インスタンスが使用可能になると、
pgaudit
が初期化されていることを確認できます。psql
を使用して RDS for PostgreSQL DB インスタンスに接続し、次のコマンドを実行します。SHOW shared_preload_libraries;
shared_preload_libraries -------------------------- rdsutils,pgaudit (1 row)
pgAudit を初期化すると、拡張機能を作成できるようになりました。
CREATE EXTENSION pgaudit;
AWS CLI を使用できるように
psql
セッションを終了します。labdb=>
\q
次の AWS CLI コマンドを使用して、セッション監査ログによって記録するステートメントのクラスを指定します。この例では、
pgaudit.log
パラメータをwrite
に設定し、ログへの挿入、更新、削除をキャプチャします。aws rds modify-db-parameter-group \ --db-parameter-group-name
custom-param-group-name
\ --parameters "ParameterName=pgaudit.log,ParameterValue=write
,ApplyMethod=pending-reboot" \ --regionaws-region
pgaudit.log
パラメータには、次のいずれかの値を選択することもできます。none – これはデフォルトです。データベースの変更は記録されません。
すべて — すべてをログに記録します (読み取り、書き込み、関数、ロール、DDL、その他)。
ddl –
ROLE
クラスに含まれていない、すべてのデータ定義言語 (DDL) ステートメントのログ記録。function – 関数呼び出し、および
DO
ブロックのログ記録。misc –
DISCARD
、FETCH
、CHECKPOINT
、VACUUM
、SET
など、さまざまなコマンドのログ記録。read –
SELECT
およびCOPY
のログ記録 (ソースがリレーション (テーブルなどの) またはクエリの場合)。role –
GRANT
、REVOKE
、CREATE ROLE
、ALTER ROLE
、DROP ROLE
など、ロールと権限に関連するステートメントのログ記録。write –
INSERT
、UPDATE
、DELETE
、TRUNCATE
、およびCOPY
のログ記録 (送信先がリレーション (テーブル) の場合)。
次の AWS CLI コマンドを使用して、 RDS for PostgreSQL DB インスタンスを再起動します。
aws rds reboot-db-instance \ --db-instance-identifier
your-instance
\ --regionaws-region
データベースオブジェクトの監査
RDS for PostgreSQL DB インスタンスに pgAudit をセットアップし、要件に合わせて設定すると、より詳細な情報が PostgreSQL ログに取得されます。例えば、デフォルトの PostgreSQL ログ設定はデータベーステーブルに変更が加えられた日付と時刻を識別しますが、pgAudit 拡張機能では、拡張機能のパラメータの設定方法に応じて、スキーマ、変更を行ったユーザー、その他の詳細をログエントリに含めることができます。監査を設定して、次の方法で変更を追跡できます。
セッションごとに、ユーザー別。セッションレベルでは、完全修飾コマンドテキストをキャプチャできます。
オブジェクトごとに、ユーザー別、データベース別。
オブジェクト監査機能は、システムで rds_pgaudit
ロールを作成し、そのロールをカスタムパラメータグループの pgaudit.role
パラメータに追加したときに有効になります。デフォルトでは、pgaudit.role
パラメータは設定されておらず、許容される値は rds_pgaudit
だけです。以下の手順は、pgaudit
が初期化され、pgAudit 拡張機能のセットアップ の手順に従って pgaudit
拡張機能を作成したことを前提としています。

この例に示すように、「LOG: AUDIT: SESSION」行には、テーブルとそのスキーマなどの詳細情報が表示されます。
オブジェクト監査をセットアップするには
psql
を使用して RDS for PostgreSQL DB インスタンスに接続します。psql --host=
your-instance-name
.aws-region
.rds.amazonaws.com --port=5432 --username=postgres
postgres --password --dbname=labdb
-
次のコマンドを使用して、
rds_pgaudit
というデータベースロールを作成します。labdb=>
CREATE ROLE rds_pgaudit;
CREATE ROLE
labdb=>
psql
セッションを終了します。labdb=>
\q
次のステップでは、AWS CLI を使用してカスタムパラメータグループの監査ログパラメータを変更します。
-
次の AWS CLI コマンドを使用して、
pgaudit.role
パラメータをrds_pgaudit
に設定します。デフォルトでは、このパラメータは空で、rds_pgaudit
は、唯一の許容値です。aws rds modify-db-parameter-group \ --db-parameter-group-name
custom-param-group-name
\ --parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" \ --regionaws-region
-
次の AWS CLI コマンドを使用して RDS for PostgreSQL DB インスタンスを再起動し、パラメータの変更を有効にします。
aws rds reboot-db-instance \ --db-instance-identifier
your-instance
\ --regionaws-region
次のコマンドを実行して、
pgaudit.role
がrds_pgaudit
に設定されたことを確認します。SHOW pgaudit.role;
pgaudit.role ------------------ rds_pgaudit
pgAudit ログ記録をテストするには、監査するサンプルコマンドをいくつか実行します。例えば、次のコマンドを実行します。
CREATE TABLE t1 (id int); GRANT SELECT ON t1 TO rds_pgaudit; SELECT * FROM t1;
id ---- (0 rows)
データベースログには、次のようなエントリが含まれます。
...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...
ログの表示方法については、「Amazon RDS ログファイルのモニタリング」を参照してください。
pgAudit 拡張機能の詳細については、GitHub で「pgAudit
監査ログからのユーザーまたはデータベースの除外
RDS for PostgreSQL データベースログファイル で説明したように、PostgreSQL ログはストレージ容量を使用します。pgAudit 拡張機能を使用すると、追跡する変更に応じて、ログに収集されるデータの量が、程度の差はありますが、増加します。内のすべてのユーザーまたはデータベースを監査する必要はないかもしれません。RDS for PostgreSQL DB インスタンス。
ストレージへの影響を最小限に抑え、監査記録を不必要にキャプチャしないようにするには、ユーザーとデータベースを監査対象から除外できます。特定のセッション内のロギングを変更することもできます。次の例は、その方法を示しています。
セッションレベルのパラメータ設定は、 RDS for PostgreSQL DB インスタンスのカスタム DB パラメータグループの設定よりも優先されます。データベースユーザーに監査ログ設定の設定をバイパスさせたくない場合は、必ず権限を変更してください。
RDS for PostgreSQL DB インスタンスが、すべてのユーザーとデータベースについて同じレベルのアクティビティを監査するように設定されているとします。次に、myuser
ユーザーを監査しないことにします。次の SQL コマンドを使用して、myuser
の監査機能を無効にできます。
ALTER USER myuser SET pgaudit.log TO 'NONE';
次に、次のクエリを使用して pgaudit.log
の user_specific_settings
列をチェックし、パラメータが NONE
に設定されていることを確認できます。
SELECT usename AS user_name, useconfig AS user_specific_settings FROM pg_user WHERE usename = 'myuser';
次のような出力が表示されます。
user_name | user_specific_settings
-----------+------------------------
myuser | {pgaudit.log=NONE}
(1 row)
次のコマンドを使用すると、データベースとのセッションの最中に、指定したユーザーのログをオフにできます。
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';
次のクエリを使用して、特定のユーザーとデータベースの組み合わせの pgaudit.log の設定列を確認します。
SELECT usename AS "user_name", datname AS "database_name", pg_catalog.array_to_string(setconfig, E'\n') AS "settings" FROM pg_catalog.pg_db_role_setting s LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole WHERE usename = 'myuser' AND datname = 'mydatabase' ORDER BY 1, 2;
以下のような出力結果が表示されます。
user_name | database_name | settings
-----------+---------------+------------------
myuser | mydatabase | pgaudit.log=none
(1 row)
myuser
の監査を無効化した後に、mydatabase
の変更を追跡しないことにしました。次のコマンドを使用して、その特定のデータベースの監査を無効化します。
ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';
次に、以下のクエリで database_specific_settings 列を確認し、pgaudit.log が NONE に設定されていることを確認します。
SELECT a.datname AS database_name, b.setconfig AS database_specific_settings FROM pg_database a FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase WHERE a.datname = 'mydatabase';
次のような出力が表示されます。
database_name | database_specific_settings
---------------+----------------------------
mydatabase | {pgaudit.log=NONE}
(1 row)
myuser の設定をデフォルト設定に戻すには、次のコマンドを使用します。
ALTER USER myuser RESET pgaudit.log;
設定をデータベースのデフォルト設定に戻すには、次のコマンドを使用します。
ALTER DATABASE mydatabase RESET pgaudit.log;
ユーザーとデータベースをデフォルト設定にリセットするには、次のコマンドを使用します。
ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;
また、pgaudit.log
パラメータに pgaudit.log
を他の許容値のいずれかに設定することで、特定のイベントをログに記録することもできます (詳しくは、「pgaudit.log パラメータの許容設定のリスト」を参照してください)。
ALTER USER myuser SET pgaudit.log TO 'read'; ALTER DATABASE mydatabase SET pgaudit.log TO 'function'; ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'
pgAudit 拡張機能のリファレンス
このセクションにリストされている 1 つまたは複数のパラメータを変更することで、監査ログに必要な詳細レベルを指定できます。
pgAudit 動作の制御
監査ログは、次のテーブルに示す 1 つ以上のパラメータを変更することで制御できます。
パラメータ | 説明 |
---|---|
| セッション監査ログ記録によってログに記録されるステートメントのクラスを指定します。許容値には、ddl、関数、その他、読み取り、ロール、書き込み、なし、すべてが含まれます。(詳しくは、「pgaudit.log パラメータの許容設定のリスト」を参照してください)。 |
|
オンにすると (1 に設定)、ステートメント内のすべてのリレーションが pg_catalog 内にある場合に、ステートメントを監査証跡に追加します。 |
|
ログエントリに使用されるログレベルを指定します。指定できる値は debug5、debug4、debug3、debug2、debug1、info、notice、warning、log です。 |
|
オン (1 に設定) すると、ステートメントとともに渡されたパラメータが監査ログに記録されます。 |
|
オンにすると (1 に設定)、セッションの監査ログで、SELECT ステートメントまたは DML ステートメントで参照されるリレーション (TABLE、VIEW など) ごとに個別のログエントリが作成されます。 |
|
ログ記録に、ステートメントテキストとパラメータを、ステートメントとサブステートメントの組み合わせの最初のログエントリとともに含めるか、すべてのエントリとともに含めるかを指定します。 |
|
オブジェクト監査ログ記録に使用するマスターロールを指定します。唯一許容されるエントリは |
pgaudit.log
パラメータの許容設定のリスト
値 | 説明 |
---|---|
none | これがデフォルトです。データベースの変更は記録されません。 |
すべて | すべてをログに記録します (読み取り、書き込み、関数、ロール、DDL、その他)。 |
ddl |
|
function | 関数呼び出し、および |
misc |
|
read |
|
[ Role] ( ロール) |
|
書き込み |
|
セッション監査で複数のイベントタイプをログ記録するには、カンマ区切りリストを使用します。すべてのイベントタイプをログ記録するには、pgaudit.log
を ALL
に設定します。DB インスタンスを再起動して、変更を適用します。
オブジェクト監査では、監査のログ記録を絞り込み、特定のリレーションを操作できます。例えば、1 つまたは複数のテーブルで、READ
オペレーションのログ記録を監査するよう指定できます。
pglogical を使用してインスタンス間でデータを同期する
現在利用可能なすべての RDS for PostgreSQL バージョンは、pglogical
拡張機能をサポートしています。pglogical 拡張は、バージョン 10 で PostgreSQL により導入された機能的に類似した論理レプリケーション機能よりも前のものです。詳細については、「Amazon RDS for PostgreSQL の論理レプリケーションの実行」を参照してください。
pglogical
拡張が、2 つ以上の 間の論理レプリケーションをサポートします。RDS for PostgreSQL DB インスタンス。また、異なる PostgreSQL バージョン間のレプリケーション、および RDS for PostgreSQL DB と Aurora PostgreSQL DB クラスターで実行されているデータベース間のレプリケーションもサポートしています。pglogical
拡張は、公開/サブスクライブモデルを使用して、テーブルやその他のオブジェクト (シーケンスなど) への変更をパブリッシャーからサブスクライバーに複製します。パブリッシャーノードからサブスクライバーノードに変更が確実に同期されるようにするには、レプリケーションスロットを使用し、次のように定義されます。
パブリッシャーノードは、他のノードにレプリケートされるデータのソースである RDS for PostgreSQL DB インスタンスです。パブリッシャーノードは、パブリケーションセットでレプリケートするテーブルを定義します。
サブスクライバーノードは、公開者から WAL の更新を受け取る RDS for PostgreSQL DB インスタンスです。サブスクライバーは、パブリッシャーに接続してデコードされた WAL データを取得するためのサブスクリプションを作成します。サブスクライバーがサブスクリプションを作成すると、パブリッシャーノードに複製スロットが作成されます。
pglogical
拡張の設定についての情報は、以下を参照してください。
トピック
pglogical 拡張の要件と制限
RDS for PostgreSQL の現在利用可能なすべてのリリースが pglogical
拡張機能をサポートしています。
パブリッシャーノードとサブスクライバーノードの両方を論理レプリケーション用に設定する必要があります。
サブスクライバーからパブリッシャーにレプリケートするテーブルは、名前とスキーマが同じである必要があります。これらのテーブルにも同じ列が含まれている必要があり、列は同じデータ型を使用する必要があります。パブリッシャーテーブルとサブスクライバーテーブルの両方に同じプライマリキーが必要です。一意の制約事項としては PRIMARY KEY のみを使用することをお勧めします。
サブスクライバーノードのテーブルには、CHECK 制約と NOT NULL 制約について、パブリッシャーノードのテーブルよりも許可度が高い制約を設定できます。
pglogical
拡張は、PostgreSQL (バージョン 10 以降) に組み込まれている論理レプリケーション機能ではサポートされていない双方向レプリケーションなどの機能を提供します。詳細については、「PostgreSQL bi-directional replication using pglogical
pglogical 拡張のセットアップ
RDS for PostgreSQL DB インスタンスに pglogical
拡張機能を設定するには、RDS for PostgreSQL DB インスタンスのカスタム DB パラメータグループの共有ライブラリに pglogical
を追加します。また、論理デコードをオンにするには、rds.logical_replication
パラメータの値を 1
に設定する必要があります。最後に、データベースに拡張を作成します。これらのタスクには、AWS Management Console または AWS CLI を使用できます。
これらのタスクを実行するには、rds_superuser
ロールとしてアクセス許可が必要です。
以下の手順では、 RDS for PostgreSQL DB インスタンスがカスタム DB パラメータグループに関連付けられていることを前提としています。カスタム DB パラメータグループの作成については、「パラメータグループを使用する」を参照してください。
pglogical 拡張をセットアップするには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
ナビゲーションペインで、 RDS for PostgreSQL DB インスタンスを選択します。
-
の [Configuration] (設定) タブを開きます。RDS for PostgreSQL DB インスタンス。インスタンスの詳細の中から、パラメータグループのリンクを見つけてください。
-
リンクを選択して、に関連するカスタムパラメータを開きます。RDS for PostgreSQL DB インスタンス。
-
パラメータ検索フィールドに、
shared_pre
を入力してshared_preload_libraries
パラメータを検索します。 -
プロパティ値にアクセスするには、[Edit parameters] (パラメータの編集) を選択します。
-
[Values] (値) フィールドのリストに
pglogical
を追加します。値のリスト内の項目を区切るにはカンマを使用します。 rds.logical_replication
パラメータを見つけて1
に設定し、論理レプリケーションをオンにします。RDS for PostgreSQL DB インスタンス を再起動して、変更を有効にします。
インスタンスが使用可能になったら、
psql
(または pgAdmin) を使用して RDS for PostgreSQL DB インスタンスに接続します。psql --host=
111122223333
.aws-region
.rds.amazonaws.com --port=5432 --username=postgres
--password --dbname=labdb
pglogical が初期化されていることを確認するには、次のコマンドを実行します。
SHOW shared_preload_libraries;
shared_preload_libraries -------------------------- rdsutils,pglogical (1 row)
次のように、論理デコードを有効にする設定を確認します。
SHOW wal_level;
wal_level ----------- logical (1 row)
次のように拡張を作成します。
CREATE EXTENSION pglogical;
EXTENSION CREATED
[Save changes] (変更の保存) をクリックします。
Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 データベースリストから RDS for PostgreSQL DB インスタンス を選択して選択し、アクションメニューから [Reboot] (再起動) を選択します。
pglogical 拡張のセットアップするには
AWS CLI を使用して pglogical を設定するには、次の手順に示すように、modify-db-parameter-group オペレーションを呼び出してカスタムパラメータグループの特定のパラメータを変更します。
次の AWS CLI コマンドを使用して
shared_preload_libraries
パラメータにpglogical
を追加します。aws rds modify-db-parameter-group \ --db-parameter-group-name
custom-param-group-name
\ --parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \ --regionaws-region
次の AWS CLI コマンドを使用して
rds.logical_replication
を1
に設定し、の論理デコード機能をオンにします。RDS for PostgreSQL DB インスタンス。aws rds modify-db-parameter-group \ --db-parameter-group-name
custom-param-group-name
\ --parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \ --regionaws-region
-
次の AWS CLI コマンドを使用して RDS for PostgreSQL DB インスタンスを再起動し、pglogical ライブラリを初期化します。
aws rds reboot-db-instance \ --db-instance-identifier
your-instance
\ --regionaws-region
インスタンスが使用可能になったら、
psql
を使用して RDS for PostgreSQL DB インスタンスに接続します。psql --host=
111122223333
.aws-region
.rds.amazonaws.com --port=5432 --username=postgres
--password --dbname=labdb
次のように拡張を作成します。
CREATE EXTENSION pglogical;
EXTENSION CREATED
次の AWS CLI コマンドを使用して、 RDS for PostgreSQL DB インスタンスを再起動します。
aws rds reboot-db-instance \ --db-instance-identifier
your-instance
\ --regionaws-region
RDS for PostgreSQL DB インスタンスに論理レプリケーションを設定する
以下の手順では、2 つの RDS for PostgreSQL DB インスタンス間で論理レプリケーションを開始する方法を示しています。これらのステップでは、ソース (パブリッシャー) とターゲット (サブスクライバー) の両方に、pglogical 拡張のセットアップ で説明されているように pglogical
拡張が設定されていることを前提としています。
パブリッシャーノードを作成し、複製するテーブルを定義するには
これらのステップは、別のノードに複製する 1 つ以上のテーブルがあるデータベースが RDS for PostgreSQL インスタンスにあることを前提としています。サブスクライバー上のパブリッシャーからテーブル構造を再作成する必要があるため、まず必要に応じてテーブル構造を取得します。そのためには、psq1
メタコマンド \d
を使用してサブスクライバーインスタンスに同じテーブルを作成します。次の手順では、デモンストレーションを目的として、パブリッシャー (ソース) でサンプルテーブルを作成します。tablename
psql
を使用して、サブスクライバーのソースとして使用したいテーブルがあるインスタンスに接続します。psql --host=
source-instance
.aws-region
.rds.amazonaws.com --port=5432 --username=postgres
--password --dbname=labdb
複製する既存のテーブルがない場合は、次のようにサンプルテーブルを作成できます。
次の SQL ステートメントを使用してサンプルテーブルを作成します。
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
次の SQL ステートメントを使用して、生成されたデータをテーブルに入力します。
INSERT INTO docs_lab_table VALUES (generate_series(1,5000));
INSERT 0 5000
次の SQL ステートメントを使用して、テーブルにデータが存在することを確認します。
SELECT count(*) FROM docs_lab_table;
次のように、この RDS for PostgreSQL DB インスタンスをパブリッシャーノードとして指定します。
SELECT pglogical.create_node( node_name := '
docs_lab_provider
', dsn := 'host=source-instance
.aws-region
.rds.amazonaws.com port=5432 dbname=labdb
');create_node ------------- 3410995529 (1 row)
複製するテーブルをデフォルトのレプリケーションセットに追加します。レプリケーションセットの詳細については、pglogical ドキュメントの「Replication sets
」(レプリケーションセット) を参照してください。 SELECT pglogical.replication_set_add_table('default', '
docs_lab_table
', 'true', NULL, NULL);replication_set_add_table --------------------------- t (1 row)
パブリッシャーノードの設定が完了しました。これで、パブリッシャーから更新を受け取るようにサブスクライバーノードを設定できます。
サブスクライバーノードを設定し、更新を受信するサブスクリプションを作成するには
これらのステップは、RDS for PostgreSQL DB インスタンスが pglogical
拡張機能を使用してセットアップされていることを前提としています。詳細については、「pglogical 拡張のセットアップ」を参照してください。
psql
を使用して、パブリッシャーから更新を受け取るインスタンスに接続します。psql --host=
target-instance
.aws-region
.rds.amazonaws.com --port=5432 --username=postgres
--password --dbname=labdb
-
サブスクライバーの RDS for PostgreSQL DB インスタンスで、パブリッシャーに存在するのと同じテーブルを作成します。この例では、テーブルは
docs_lab_table
です。次に示すようにテーブルを作成できます。CREATE TABLE docs_lab_table (a int PRIMARY KEY);
このテーブルが空であることを確認します。
SELECT count(*) FROM docs_lab_table;
count ------- 0 (1 row)
次のように、この RDS for PostgreSQL DB インスタンスをサブスクライバーノードとして指定します。
SELECT pglogical.create_node( node_name := '
docs_lab_target
', dsn := 'host=target-instance
.aws-region
.rds.amazonaws.com port=5432 sslmode=require dbname=labdb
user=postgres
password=********
');create_node ------------- 2182738256 (1 row)
サブスクリプションを作成します。
SELECT pglogical.create_subscription( subscription_name := 'docs_lab_subscription', provider_dsn := 'host=
source-instance
.aws-region
.rds.amazonaws.com port=5432 sslmode=require dbname=labdb
user=postgres
password=*******
', replication_sets := ARRAY['default'], synchronize_data := true, forward_origins := '{}' );create_subscription --------------------- 1038357190 (1 row)
このステップを完了すると、パブリッシャーのテーブルのデータが、サブスクライバーのテーブルに作成されます。このことを確認するには、次の SQL クエリを使用します。
SELECT count(*) FROM docs_lab_table;
count ------- 5000 (1 row)
これ以降、パブリッシャーのテーブルに加えられた変更は、サブスクライバーのテーブルにレプリケートされます。
メジャーアップグレード後の論理レプリケーションの再確立
論理レプリケーションのパブリッシャーノードとして設定されている RDS for PostgreSQL DB インスタンスのメジャーバージョンアップグレードを実行する前に、アクティブではないものを含め、すべてのレプリケーションスロットを削除する必要があります。パブリッシャーノードからデータベーストランザクションを一時的に迂回させ、レプリケーションスロットを削除し、RDS for PostgreSQL DB インスタンスをアップグレードしてから、レプリケーションを再確立して再開することをお勧めします。
レプリケーションスロットはパブリッシャーノードでのみホストされます。論理レプリケーションシナリオの RDS for PostgreSQL サブスクライバーノードには削除するスロットはありませんが、パブリッシャーへのサブスクリプションを持つサブスクライバーノードとして指定されている間は、メジャーバージョンにアップグレードできません。RDS for PostgreSQL サブスクライバーノードをアップグレードする前に、サブスクリプションとノードを削除してください。詳細については、「RDS for PostgreSQL 用ロジカルレプリケーションスロットの管理」を参照してください。
論理レプリケーションが中断されたことの確認
次のように、パブリッシャーノードまたはサブスクライバーノードのいずれかにクエリを実行することで、レプリケーションプロセスが中断されたことを確認できます。
パブリッシャーノードを確認するには
psql
を使用してパブリッシャーノードに接続して、pg_replication_slots
関数をクエリします。active 列の値に注目します。通常はt
(true) が返されます。これは、レプリケーションがアクティブであることを示します。クエリがf
(false) を返す場合は、サブスクライバーへのレプリケーションが停止したことを示します。SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active -------------------------------------------+------------------+-----------+-------- pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f (1 row)
サブスクライバーノードを確認するには
サブスクライバーノードでは、3 つの異なる方法でレプリケーションのステータスを確認できます。
サブスクライバーノードの PostgreSQL ログを調べて、失敗のメッセージを見つけます。ログでは、次に示すように、終了コード 1 を含むメッセージで失敗が識別されます。
2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1 2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1
pg_replication_origin
関数をクエリします。次のように、psql
を使用してサブスクライバーノード上のデータベースに接続し、pg_replication_origin
関数をクエリします。SELECT * FROM pg_replication_origin;
roident | roname ---------+-------- (0 rows)
結果セットが空の場合は、レプリケーションが中断されたことを意味します。通常、次のような出力が表示されます。
roident | roname ---------+---------------------------------------------------- 1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c (1 row)
次の例に示すように、
pglogical.show_subscription_status
関数をクエリします。SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name ---====----------------+--------+------------------------------------- docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c (1 row)
この出力は、レプリケーションが中断されたことを示しています。そのステータスは
down
です。通常、出力にはステータスがreplicating
として表示されます。
論理レプリケーションプロセスが中断された場合は、次のステップに従ってレプリケーションを再確立できます。
パブリッシャーノードとサブスクライバーノード間の論理レプリケーションを再確立するには
レプリケーションを再確立するには、以下のステップで説明するように、まずサブスクライバーをパブリッシャーノードから切断し、次にサブスクリプションを再確立します。
次のように
psql
を使用してサブスクライバーノードに接続します。psql --host=
222222222222
.aws-region
.rds.amazonaws.com --port=5432 --username=postgres
--password --dbname=labdb
pglogical.alter_subscription_disable
関数を使用してサブスクリプションを非アクティブ化します。SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true);
alter_subscription_disable ---------------------------- t (1 row)
以下のように、
pg_replication_origin
をクエリして、パブリッシャーノードの識別子を取得します。SELECT * FROM pg_replication_origin;
roident | roname ---------+------------------------------------- 1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c (1 row)
前のステップからの応答を
pg_replication_origin_create
コマンドに使用して、サブスクリプションが再確立されたときに使用できる識別子を割り当てます。SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c');
pg_replication_origin_create ------------------------------ 1 (1 row)
次の例のように、ステータスを
true
にして名前を渡し、サブスクリプションを有効にします。SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true);
alter_subscription_enable --------------------------- t (1 row)
ノードのステータスを確認します。ステータスはこの例のように replicating
として表示されているはずです。
SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name -------------------------------+-------------+------------------------------------- docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c (1 row)
パブリッシャーノード上のサブスクライバーのレプリケーションスロットのステータスを確認します。スロットの active
列は t
(true) を返し、レプリケーションが再確立されたことを示します。
SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active -------------------------------------------+------------------+-----------+-------- pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t (1 row)
RDS for PostgreSQL 用ロジカルレプリケーションスロットの管理
論理レプリケーションシナリオでパブリッシャーノードとして機能している RDS for PostgreSQL DB インスタンスでメジャーバージョンアップグレードを実行する前に、インスタンスのレプリケーションスロットを削除する必要があります。メジャーバージョンアップグレードの事前確認プロセスにより、スロットが削除されるまでアップグレードを続行できないことが通知されます。
RDS for PostgreSQL DB インスタンスからスロットを削除するには、まずサブスクリプションを削除してからスロットを削除します。
pglogical
拡張を使用して作成されたレプリケーションスロットを特定するには、各データベースにログインしてノードの名前を取得します。サブスクライバーノードにクエリを実行すると、次の例に示すように、パブリッシャーノードとサブスクライバーノードの両方が出力されます。
SELECT * FROM pglogical.node;
node_id | node_name ------------+------------------- 2182738256 | docs_lab_target 3410995529 | docs_lab_provider (2 rows)
次のクエリで、サブスクリプションの詳細を取得できます。
SELECT sub_name,sub_slot_name,sub_target FROM pglogical.subscription;
sub_name | sub_slot_name | sub_target ----------+--------------------------------+------------ docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256 (1 row)
これで、次のようにサブスクリプションを削除できます。
SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
drop_subscription ------------------- 1 (1 row)
サブスクリプションを削除すると、ノードを削除できます。
SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
drop_node ----------- t (1 row)
次のように、ノードが存在しないことを確認できます。
SELECT * FROM pglogical.node;
node_id | node_name ---------+----------- (0 rows)
pglogical 拡張のパラメータリファレンス
表には、pglogical
拡張に関連するパラメータがあります。pglogical.conflict_log_level
や pglogical.conflict_resolution
などのパラメータは、更新の競合を処理するために使用されます。パブリッシャーから変更をサブスクライブしているテーブルにローカルで変更を加えると、競合が発生する可能性があります。これ以外にも、競合は、双方向のレプリケーションや、複数のサブスクライバーが同じパブリッシャーからレプリケートする場合など、さまざまなシナリオで発生する可能性があります。詳細については、「PostgreSQL bi-directional replication using pglogical
パラメータ | 説明 |
---|---|
pglogical.batch_inserts | 可能であれば、バッチ挿入。デフォルトでは設定されていません。オンにする場合は「1」に、オフにする場合は「0」に変更します。 |
pglogical.conflict_log_level | 解決された競合のログ記録に使用するログレベルを設定します。サポートされている文字列値は、debug5、debug4、debug3、debug2、debug1、info、notice、warning、error、log、fatal、panic です。 |
pglogical.conflict_resolution | 競合が解決可能な場合に競合を解決するために使用するメソッドを設定します。サポートされている文字列値は、error、apply_remote、keep_local、last_update_wins、first_update_wins です。 |
pglogical.extra_connection_options | すべてのピアノード接続に追加する接続オプション。 |
pglogical.synchronous_commit | pglogical 固有の同期コミット値 |
pglogical.use_spi | 低レベル API の代わりに SPI (サーバープログラミングインターフェイス) を使用して変更を適用します。オンにする場合は「1」に、オフにする場合は「0」に設定します。SPI の詳細については、PostgreSQL ドキュメントの「サーバープログラミングインターフェイス |
pg_repack 拡張機能を使用して、テーブルやインデックスの膨張を抑制する
pg_repack 拡張機能使用して、テーブルやインデックスの膨張を取り除くことができます。このエクステンションは、RDS for PostgreSQL のバージョン 9.6.3 以降でサポートされています。pg_repack 拡張機能の詳細については、「GitHub プロジェクトのドキュメント
pg_repack エクステンションを使用するには
-
次のコマンドを実行して、RDS for PostgreSQL DB インスタンスに pg_repack 拡張機能をインストールします。
CREATE EXTENSION pg_repack;
-
次のコマンドを実行して、pg_repack によって作成されたテンポラリログテーブルを再パックするための書き込みアクセスを許可します。
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT INSERT ON TABLES TO PUBLIC; ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT USAGE, SELECT ON SEQUENCES TO PUBLIC;
pg_repack クライアントユーティリティを使用してデータベースに接続します。
rds_superuser
権限を持つアカウントを使用します。例として、rds_test
ロールにrds_superuser
権限があるとします。コマンドの構文を次に示します。pg_repack -h
db-instance-name
.111122223333.aws-region
.rds.amazonaws.com -U rds_test -k postgres-k オプションを使用して接続します。-a オプションはサポートされていません。
pg_repack クライアントからの応答により、再パッケージされる DB インスタンスのテーブルに関する情報が提供されます。
INFO: repacking table "pgbench_tellers" INFO: repacking table "pgbench_accounts" INFO: repacking table "pgbench_branches"
PLV8 拡張機能のアップグレードおよび使用
PLV8 は、信頼できる JavaScript 言語の PostgreSQL 用エクステンションです。ストアドプロシージャ、トリガー、SQL から呼び出し可能なその他のプロシージャルコードに使用できます。この言語のエクステンションは、PostgreSQL のすべての最新リリースでサポートされています。
PLV8
アップグレードプロセスでは、既存の PLV8 機能がすべて削除されます。そのため、アップグレードする前に、RDS for PostgreSQL DB インスタンスのスナップショットを作成しておくことをお勧めします。詳細については、「DB スナップショットの作成」を参照してください。
カタログメタデータを新しいバージョンの PLV8 と同期させるには
-
更新する必要があることを確認します。そのためには、インスタンスに接続されている間に以下のコマンドを実行します。
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
インストールされているバージョンとしてデフォルトのバージョンより低いバージョンが表示された場合は、この手順を実行して、エクステンションを更新する必要があります。例えば、以下の結果セットは更新の必要があることを表します。
name | default_version | installed_version | comment --------+-----------------+-------------------+-------------------------------------------------- plls | 2.1.0 | 1.5.3 | PL/LiveScript (v8) trusted procedural language plcoffee| 2.1.0 | 1.5.3 | PL/CoffeeScript (v8) trusted procedural language plv8 | 2.1.0 | 1.5.3 | PL/JavaScript (v8) trusted procedural language (3 rows)
RDS for PostgreSQL DB インスタンスのスナップショットを作成していない場合は、作成してください。次のステップは、スナップショットの作成中も続行できます。
-
DB インスタンスの PLV8 関数の数を取得し、アップグレード後にすべて揃っていることを確認できるようにします。例えば次の SQL クエリ では、plv8、plcoffee、plls で記述されている関数の数が返ります。
SELECT proname, nspname, lanname FROM pg_proc p, pg_language l, pg_namespace n WHERE p.prolang = l.oid AND n.oid = p.pronamespace AND lanname IN ('plv8','plcoffee','plls');
-
pg_dump を使用して、スキーマのみのダンプファイルを作成します。例えば、クライアントマシンの
/tmp
ディレクトリに、ファイルを作成します。./pg_dump -Fc --schema-only -U master postgres >/tmp/test.dmp
この例では、以下のオプションを使用します。
-
-Fc
– カスタム形式 -
-- スキーマのみ – スキーマの作成に必要なコマンド (ここでは関数) のみをダンプする
-
-U
– RDS マスターユーザー名 -
database
– DB インスタンスのデータベース名
pg_dump の詳細については、「PostgreSQL ドキュメント」の「pg_dump
」を参照してください。 -
-
ダンプファイルに存在する "CREATE FUNCTION" DDL ステートメントを抽出します。次の例では
grep
コマンドを実行して、関数を作成する DDL ステートメントを抽出し、ファイルに保存します。この ddl は後続のステップで関数を再作成するために使用します。./pg_restore -l /tmp/test.dmp | grep FUNCTION > /tmp/function_list/
pg_restore の詳細については、「PostgreSQL ドキュメント」の「pg_restore
」を参照してください。 -
関数およびエクステンションを削除します。次の例では、PLV8 ベースのオブジェクトを削除します。CASCADE オプションでは、すべての依存が削除されます。
DROP EXTENSION pvl8 CASCADE;
plcoffee または plls に基づくオブジェクトが PostgreSQL インスタンスに含まれている場合は、それらのエクステンションに対してこのステップを繰り返します。
-
エクステンションを作成します。次の例では、plv8、plcoffee、plls のエクステンションが作成されます。
CREATE EXTENSION plv8; CREATE EXTENSION plcoffee; CREATE EXTENSION plls;
-
ダンプファイルおよび "ドライバ" ファイルを使用して関数を作成します。
次の例では、前に抽出した関数が再作成されます。
./pg_restore -U master -d postgres -Fc -L /tmp/function_list /tmp/test.dmp
-
次のクエリを使用して、すべての関数が再作成されたことを確認します。
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
PLV8 バージョン 2 では、次の行が結果セットに追加されます。
proname | nspname | lanname ---------------+------------+---------- plv8_version | pg_catalog | plv8