DDL replication#

DDLはデータ定義言語の略で、データベースオブジェクトを作成、変更、および削除するSQL言語のサブセットです。

操作の利便性と正確性を維持するために、 PGDはほとんどのDDLアクションをレプリケートしますが、次の例外を除きます。

  • 一時的なまたはログに記録されていない関係

  • 特定のDDLステートメントほとんどの場合、長時間実行

  • ロックコマンド LOCK

  • テーブルメンテナンスコマンド VACUUM 、ANALYZE 、CLUSTER 、REINDEX

  • オートバキュームのアクション

・操作コマンド CHECKPOINT 、ALTER SYSTEM

  • データベースまたはテーブルスペースに関連するアクション

自動DDLレプリケーションにより、 DDL変更をすべてのノードに手動で配布し、一貫性を確認する必要がなく、特定のDDL変更が簡単になります。

デフォルトのレプリケーションセットでは、 DDLはデフォルトですべてのノードにレプリケートされます。 DDLをレプリケートするには、 DDLレプリケーションフィルタをレプリケーションセットに追加する必要があります。

DDLレプリケーションフィルタリング を参照してください。

DDLレプリケーションに関して、 PGDはスタンドアロンのPostgreSQLとは大きく異なります。それを同じに扱うことは、PGDで最も一般的な問題です。

テーブルレプリケーションとの主な違いは、 DDLレプリケーションがDDLの結果ではなくステートメント自分自身をレプリケートすることです。これは、ほとんどの場合で非常にうまく機能しますが、 DDLをすべてのノードで同様に実行する必要があるという要件が導入されます。より微妙な点は、 DDLは、拡張機能ビルトインではなくによって導入されたデータ型を含む、すべてのデータ型固有のパラメーター設定に関して不変である必要があることです。たとえば、 DDLステートメントは、各ノードで使用されるデフォルトのエンコーディングで正しく実行される必要があります。

DDLレプリケーションオプション#

bdr.ddl_replication パラメーターは、レプリケーション動作を指定します。

bdr.ddl_replication = on はデフォルトであり、 DDLをデフォルトのレプリケーションセットにレプリケートします。デフォルトでは、すべてのノードを意味します。デフォルト以外のレプリケーションセットは、

DDL filter がない限りDDLをレプリケートしません

彼らのために定義されました。

ファンクション bdr.replicate_ddl_command() を使用して、 DDLを特定のレプリケーションセットにレプリケートすることもできます。これは、ノードがダウンしているときにDDLコマンドを実行する場合、またはサイト1のすべてのノードなど、ノードまたは担当セットのサブセットに存在するインデックスまたはパーティションを必要とする場合に役立ちます。

SELECT bdr.replicate_ddl_command(
                CREATE INDEX CONCURRENTLY ON foo (col7);,
                ARRAY[site1],     -- the replication sets
                on);              -- ddl_locking to apply

お勧めしませんが、 自動DDLレプリケーションをスキップし、 bdr.ddl_replication 構成パラメーターを使用して各ノードで手動で実行できます。

SET bdr.ddl_replication = off;

設定すると、PGDは実行されたDDLコマンドのグローバルロックとレプリケーションの両方をスキップします。次に、すべてのノードでDDLを手動で実行する必要があります。

警告

グローバルロックを使用せずに各ノードでDDLを手動で実行すると、競合するDDLまたはDMLが同時に実行される場合、PGDグループ全体のレプリケートが停止される場合があります。

bdr.ddl_replication パラメーターは、 bdr_superuser、スーパーユーザー、またはconfig ファイルでのみ設定できます。

PGDシステムでのDDLの実行#

PGDグループは、スタンドアロンのPostgreSQLサーバーと同じではありません。これは、集中ロックやトランザクションコーディネーターを使用しない非同期マルチマスターレプリケーションに基づいています。これは、 DDLの実行時に重要な意味を持ちます。

パラレルに実行されるDDLは、PGDで引き続き実行されます。 DDLの実行は、実行時に各ノードの並列オペレーションに影響を与えるパラメーターを尊重するため、ノード間の設定の違いに気づく場合があります。

競合するDDLの実行を防止します。そうしないと、 DDLレプリケーションでエラーが発生し、レプリケーションが停止します。

PGDは、これらの問題に対する3つのレベルの保護を提供します。

ddl_locking = 'dml' は操作に最適なオプションであり、一度に1つのノードのみからDDLを実行する場合に使用できます。これはデフォルトではありませんが、 DDLを実行する場所を制御できる場合は、この設定を使用することをお勧めします。こうすることで、ノード間の競合が発生しないようにします。ノード内の競合はPostgreSQLによって既に処理されています。

ddl_locking = on は最も厳密なオプションであり、 DDLが任意のノードから同時に実行される可能性があり、正確性を保証したい場合に最適です。

ddl_locking = off は最も厳密でないオプションであり、一般的な使用は危険です。このオプションは、ロックを完全にスキップし、パフォーマンスのオーバーヘッドを回避するため、新しい空のデータベーススキーマを作成するときに役立つオプションです。

これらのオプションは、 bdr_superuser、スーパーユーザー、またはconfig file でのみ設定できます。

bdr.replicate_ddl_command を使用する場合、そのファンクションに渡されるDDLコマンドにのみ指定されたbdr.ddl_locking 設定を使用して、3番目の引数でこのパラメーターを直接設定できます。

DDLロックの詳細#

2種類のロックは、PGDでレプリケートされたDDLの正しさを強制します。

最初の種類はグローバルDDLロックと呼ばれ、ddl_locking = on の場合にのみ使用されます。グローバルDDLロックは、各DDLステートメントの実行中にクラスターで他のDDLが実行されないようにします。これにより、一般的な場合に完全な正しさが保証されますが、多くの単純な場合には厳密すぎます。 PGDは、スキーマ変更が行われるトランザクションで初めてDDL操作のグローバルロックを取得します。これにより、クラスター内のDDL実行トランザクションが効果的にシリアル化されます。つまり、 DDLの実行中は、ノード上の他の接続は、別のテーブルに影響を与える場合でも、別のDDLコマンドを実行できません。

DDL操作のロックを取得するために、 DDLを実行するPGDノードはPGDグループ内の他のノードに接続し、 DDLを実行する排他的権限を付与するように求めます。ロック要求は通常のレプリケーションストリームによって送信され、ノードは同様にレプリケーションストリームによって応答します。したがって、ノードまたは少なくともノードの大部分が、レプリケーション遅延をほとんど発生せずに実行されることが重要です。そうしないと、ノードがDDLロックを取得するまでに時間がかかる場合があります。ノードの大部分が同意すると、 DDL実行が実行されます。

DDLロックの順序は、Raftプロトコルを使用して決定されます。 1つのノードで実行されたDDLステートメントは、他のすべてのノードで同じシーケンスで実行されます。

DDLを実行しているノードがクラスター内で実行された以前のすべてのDDLの効果を確認したことを確認するために、以前のDDLを実行したノードに追いつくまで待機します。現在のDDLを実行しているノードが、以前のDDLを実行したノードと比較してレプリケーションが遅れている場合、ロックの取得に時間がかかる場合があります。したがって、単一のノード、または他のノードで発生したレプリケーションの変更にほぼ追いついたノードからDDLを実行することをお勧めします。

2番目の種類は、グローバルDMLロックまたはリレーションDMLロックと呼ばれます。この種類のロックは、 ddl_locking = on またはddl_locking = dml のいずれか、およびDDLステートメントによりフライト中のDMLステートメントが失敗する可能性がある場合に使用されます。これらの障害は、一意制約、チェック制約、NOT NULL制約などの制約を追加または変更するときに発生する可能性があります。リレーションDMLロックは、一度に1つのリレーションにのみ影響します。リレーションDMLロックは、エラーでレプリケーションを停止する可能性のある変更がキューにあるときにDDLが実行されないことを保証します。

テーブルのグローバルDMLロックを取得するために、 DDLを実行するPGDノードはPGDグループ内の他のすべてのノードに接続し、書き込みに対してテーブルをロックするように依頼し、そのテーブルの保留中の変更がすべてドレインされるまで待機します。すべてのノードが完全に追いつくと、DMLロックの発信者は自由にテーブルのスキーマ変更を実行し、他のノードにレプリケートできます。

グローバルDMLロックは、各ノードのテーブルのEXCLUSIVE LOCKを保持するため、実行中にそのテーブルに対するDML、他のDDL、VACUUM、およびindexコマンドをブロックします。これは、通常EXCLUSIVE LOCK以上を使用しないコマンドにグローバルDMLロックが保持されている場合にも当てはまります。

保留中のDML操作がドレインされるまでに長い時間がかかる場合があり、レプリケーションが現在遅延している場合はさらに長くなります。これは、データの変更とは異なり、行表現とコンストレインに影響を与えるスキーマの変更が、構成されているすべてのノードに到達でき、現在の書き込みレートに適度に追随しているときにのみ実行できることを意味します。ノードがダウンしているときにこのようなDDLコマンドを実行する必要がある場合は、最初にダウンしたノードを構成から削除します。

DDLステートメントがレプリケートされない場合、グローバルロックは取得されません。

PGDシステムでのDDLの実行 で説明しているように、ロック動作はbdr.ddl_locking

パラメーターで指定されます。

  • ddl_locking = on は、グローバルDDLロックを取得し、必要に応じてリレーションDMLロックを取得します。

  • ddl_locking = dml は、グローバルDDLロックをスキップし、必要に応じてリレーションDMLロックを取得します。

  • ddl_locking = off は、グローバルDDLロックとリレーションDMLロックの両方をスキップします。

一部のPGDファンクションはDDL変更を行います。これらのファンクションには、 DDLロック動作が適用されます。これについては、各ファンクションのドキュメントに記載されています。

したがって、 ddl_locking = dml は、競合するDDLが他のノードから実行されないことを保証できる場合にのみ安全です。この設定では、グローバルDDLロックのみを必要とするステートメントは、グローバルロックをまったく使用しません。

ddl_locking = off は、 DDLが実行されるデータベースオブジェクトで競合するDDLと競合するDML操作がないことを保証できる場合にのみ安全です。ロックをオフにした後に問題が発生すると、データの進行中の変更が失われる可能性があります。ユーザーアプリケーションチームは、発生した問題を解決する必要があります。

場合によっては、同時に実行されるDDLを適切にシリアル化できる場合があります。これらのシリアル化障害が発生した場合、 DDLが再実行される場合があります。

DDLレプリケーションは、昇格するまでロジカルスタンバイノードでアクティブになりません。

一部のPGD管理機能はDDLのように動作します。つまり、グローバルロックを取得しようとし、 DDLレプリケーションがアクティブな場合、アクションがレプリケートされます。レプリケートファンクションの完全なリストは、

DDLのように動作するPGDファンクション にリストされています。

一時テーブルで実行されるDDLは、グローバルロックを必要としません。

現在のトランザクションで作成されたオブジェクトのALTERまたはDROPには、グローバルDMLロックは必要ありません。

グローバルDDLロックとグローバルDMLロックのモニタリングは

Monitoring に表示されます。

DDLのインパクトの最小化#

あらゆるデータベースに対する適切な運用上のアドバイス。PGDではこれらの点がさらに重要になります。

  • DDLの影響を最小限にするには、 DDLを実行するトランザクションを短くし、大量の行変更と組み合わせず、長時間実行される外部キーまたはその他の制約の再チェックを回避します。

  • ALTER TABLE の場合、 ADD CONSTRAINT を単独で使用するのではなく、 ADD CONSTRAINT NOT VALID を使用し、その後にVALIDATE CONSTRAINT との別のトランザクションを使用します。 VALIDATE CONSTRAINT は、すべてのノードで再生されるまで待機するため、確認の受信に顕著な遅延が発生します。

  • インデックスを作成するときは、可能な限りCONCURRENTLY オプションを使用します。

長時間実行DDLを実行する別の方法は、 DDLレプリケーションを無効にして、各ノードで個別にDDLステートメントを実行することです。次の例に示すように、単一のSQLステートメントを使用してこれを行うことができます。グローバルロックルールは引き続き適用されるため、このタイプの使用法で自分自身をロックアウトしないように注意してください。これは回避策です。

SELECT bdr.run_on_all_nodes($ddl$
        CREATE INDEX CONCURRENTLY index_a ON table_a(i);
$ddl$);

CREATE INDEX CONCURRENTLY はマルチトランザクションコマンドであるため、セッション全体でDDLレプリケーションを無効にする必要があることに注意して、 bdr.run_on_all_nodes() テクニックを使用することをお勧めします。実行中の書き込みを防止するため、実稼働システムではCREATE INDEX を避けてください。 REINDEX は、3.6までのバージョンでレプリケートされていますが、PGD 3.7以降ではレプリケートされません。 REINDEX は、AccessExclusiveLocksを保持するため、使用を避けてください。

代わりに、PG12+または2QPG11+で使用可能なREINDEX CONCURRENTLY またはreindexdb --concurrently を使用します。

次のようなコマンドラインユーティリティを使用する場合、 DDLレプリケーションを無効にできます。

$ export PGOPTIONS="-c bdr.ddl_replication=off"
$ pg_restore --section=post-data

複数のDDLステートメントは、個々のステートメントとして起動されるよりも単一のトランザクションに束ねたほうがメリットがある場合があるため、 DDLロックは1回のみを取ります。テーブルレベルのロックが通常の操作を妨げる場合、これは望ましくない場合があります。

DDLがシステムを長時間保持している場合は、 psqlの Control-C またはpg_cancel_backend() を使用して、元のノードでDDLを安全にキャンセルできます。他のノードからDDLロックをキャンセルすることはできません。

オプションのグローバルロックタイムアウト設定を使用して、グローバルロックにかかる時間を制御できます。 bdr.global_lock_timeout は、グローバルロックの取得がキャンセルされるまでの待機時間を制限します。 bdr.global_lock_statement_timeout は、グローバルロックを保持するトランザクション内のステートメントの実行タイム長を制限し、 bdr.global_lock_idle_timeout は、グローバルロックを保持するトランザクションの最大許可アイドル時間ステートメント間の時間を設定します。値をゼロに設定することにより、これらのタイムアウトをすべて無効にできます。

元のノードでDDL操作がコミットされると、キャンセルまたは中止することはできません。 PGDグループは、グローバルロックを確認した他のノードに正常に適用され、それらが再生を確認するまで待機する必要があります。このため、 DDLトランザクションは短くて速いままにしてください。

ダウンしたノードでのDDLの処理#

グローバルDDLロックを開始するノードがグローバルロックDDLまたはDMLを取得した後にダウンした場合、ロックはアクティブなままです。タイムアウトが設定されていても、グローバルロックはタイムアウトしません。ノードが復旧した場合、ノードは保持しているすべてのグローバルロックを解放します。

長時間または無期限にダウンしたままになる場合は、PGDグループからノードを削除してグローバルロックを解放します。これが、 bdr_superuserとしてSET コマンドを使用して緊急DDLを実行し、 bdr.ddl_locking 値を更新する理由の1つです。

グローバルロックを確認した後、それを取得するコマンドが実行される前に、他のノードのいずれかがダウンした場合、ノードがアップしているかのように、ロックを要求するそのコマンドの実行は続行されます。

前述のように、グローバルDDLロックはノードの大部分のみが応答する必要があるため、大部分が実行され到達可能である限り、クラスターの一部がダウンしている場合に機能します。ただし、クラスター全体が利用できない限りDMLロックは取得できません。

グローバルDDLまたはグローバルDMLロックでは、別のノードがダウンすると、コマンドは通常に続行され、ロックが解放されます。

ステートメント固有のDDLレプリケーションの問題#

すべてのコマンドを自動的に複製できるわけではありません。 bdr.ddl_replication をオフにしてDDLレプリケーションをオフにしない限り、このようなコマンドは許可されません。

PGDは、データベースでアクティブなときに一部のDDLステートメントの実行を防止します。これにより、正しくレプリケートできないステートメント、またはレプリケーションがまだサポートされていないステートメントを禁止することにより、システムの一貫性が保護されます。

ステートメントがPGDで許可されない場合、多くの場合、同じことを行う別の方法を見つけることができます。たとえば、揮発性のデフォルト値を含む列を追加するALTER TABLE は実行できません。しかし、一般的には、機能する一連の独立したALTER TABLE およびUPDATE ステートメントとして言い換えることができます。

通常、サポートされていないステートメントは実行されず、 feature_not_supported SQLSTATE 0A000 エラーが発生します。

一時オブジェクトを参照または依存するDDLは、PGDでレプリケートできず、 DDLレプリケーションを有効にして実行するとエラーがスローされます。

PGD DDLコマンド処理マトリックス#

次の表では、許可されるユーティリティまたはDDLコマンド、レプリケートされるもの、およびレプリケート時に使用されるグローバルロックの種類について説明します。

ALTER TABLE のようなより複雑なステートメントの場合、これらは実行されるサブコマンドによって異なる場合があります。このようなすべてのコマンドには、次の表の下に詳細な説明があります。

Command

Allowed

Replicated

Lock

ALTER AGGREGATE

Y

Y

DDL

ALTER CAST

Y

Y

DDL

ALTER COLLATION

Y

Y

DDL

ALTER CONVERSION

Y

Y

DDL

ALTER DATABASE

Y

N

N

ALTER DATABASE LINK

Y

Y

DDL

ALTER DEFAULT PRIVILEGES

Y

Y

DDL

ALTER DIRECTORY

Y

Y

DDL

ALTER DOMAIN

Y

Y

DDL

ALTER EVENT TRIGGER

Y

Y

DDL

ALTER EXTENSION

Y

Y

DDL

ALTER FOREIGN DATA WRAPPER

Y

Y

DDL

ALTER FOREIGN TABLE

Y

Y

DDL

ALTER FUNCTION

Y

Y

DDL

ALTER INDEX

Y

Y

DDL

ALTER LANGUAGE

Y

Y

DDL

ALTER LARGE OBJECT

N

N

N

ALTER MATERIALIZED VIEW

Y

N

N

ALTER OPERATOR

Y

Y

DDL

ALTER OPERATOR CLASS

Y

Y

DDL

ALTER OPERATOR FAMILY

Y

Y

DDL

ALTER PACKAGE

Y

Y

DDL

ALTER POLICY

Y

Y

DDL

ALTER PROCEDURE

Y

Y

DDL

ALTER PROFILE

Y

Y

アーキテクチャの詳細

ALTER PUBLICATION

Y

Y

DDL

ALTER QUEUE

Y

Y

DDL

ALTER QUEUE TABLE

Y

Y

DDL

ALTER REDACTION POLICY

Y

Y

DDL

ALTER RESOURCE GROUP

Y

N

N

ALTER ROLE

Y

Y

DDL

ALTER ROUTINE

Y

Y

DDL

ALTER RULE

Y

Y

DDL

ALTER SCHEMA

Y

Y

DDL

ALTER SEQUENCE

アーキテクチャの詳細

Y

DML

ALTER SERVER

Y

Y

DDL

ALTER SESSION

Y

N

N

ALTER STATISTICS

Y

Y

DDL

ALTER SUBSCRIPTION

Y

Y

DDL

ALTER SYNONYM

Y

Y

DDL

ALTER SYSTEM

Y

N

N

ALTER TABLE

アーキテクチャの詳細

Y

アーキテクチャの詳細

ALTER TABLESPACE

Y

N

N

ALTER TEXT SEARCH CONFIGURATION

Y

Y

DDL

ALTER TEXT SEARCH DICTIONARY

Y

Y

DDL

ALTER TEXT SEARCH PARSER

Y

Y

DDL

ALTER TEXT SEARCH TEMPLATE

Y

Y

DDL

ALTER TRIGGER

Y

Y

DDL

ALTER TYPE

Y

Y

DDL

ALTER USER MAPPING

Y

Y

DDL

ALTER VIEW

Y

Y

DDL

ANALYZE

Y

N

N

BEGIN

Y

N

N

CHECKPOINT

Y

N

N

CLOSE

Y

N

N

CLOSE CURSOR

Y

N

N

CLOSE CURSOR ALL

Y

N

N

CLUSTER

Y

N

N

COMMENT

Y

アーキテクチャの詳細

DDL

COMMIT

Y

N

N

COMMIT PREPARED

Y

N

N

COPY

Y

N

N

COPY FROM

Y

N

N

CREATE ACCESS METHOD

Y

Y

DDL

CREATE AGGREGATE

Y

Y

DDL

CREATE CAST

Y

Y

DDL

CREATE COLLATION

Y

Y

DDL

CREATE CONSTRAINT

Y

Y

DDL

CREATE CONVERSION

Y

Y

DDL

CREATE DATABASE

Y

N

N

CREATE DATABASE LINK

Y

Y

DDL

CREATE DIRECTORY

Y

Y

DDL

CREATE DOMAIN

Y

Y

DDL

CREATE EVENT TRIGGER

Y

Y

DDL

CREATE EXTENSION

Y

Y

DDL

CREATE FOREIGN DATA WRAPPER

Y

Y

DDL

CREATE FOREIGN TABLE

Y

Y

DDL

CREATE FUNCTION

Y

Y

DDL

CREATE INDEX

Y

Y

DML

CREATE LANGUAGE

Y

Y

DDL

CREATE MATERIALIZED VIEW

Y

N

N

CREATE OPERATOR

Y

Y

DDL

CREATE OPERATOR CLASS

Y

Y

DDL

CREATE OPERATOR FAMILY

Y

Y

DDL

CREATE PACKAGE

Y

Y

DDL

CREATE PACKAGE BODY

Y

Y

DDL

CREATE POLICY

Y

Y

DML

CREATE PROCEDURE

Y

Y

DDL

CREATE PROFILE

Y

Y

アーキテクチャの詳細

CREATE PUBLICATION

Y

Y

DDL

CREATE QUEUE

Y

Y

DDL

CREATE QUEUE TABLE

Y

Y

DDL

CREATE REDACTION POLICY

Y

Y

DDL

CREATE RESOURCE GROUP

Y

N

N

CREATE ROLE

Y

Y

DDL

CREATE ROUTINE

Y

Y

DDL

CREATE RULE

Y

Y

DDL

CREATE SCHEMA

Y

Y

DDL

CREATE SEQUENCE

アーキテクチャの詳細

Y

DDL

CREATE SERVER

Y

Y

DDL

CREATE STATISTICS

Y

Y

DDL

CREATE SUBSCRIPTION

Y

Y

DDL

CREATE SYNONYM

Y

Y

DDL

CREATE TABLE

アーキテクチャの詳細

Y

DDL

CREATE TABLE AS

アーキテクチャの詳細

Y

DDL

CREATE TABLESPACE

Y

N

N

CREATE TEXT SEARCH CONFIGURATION

Y

Y

DDL

CREATE TEXT SEARCH DICTIONARY

Y

Y

DDL

CREATE TEXT SEARCH PARSER

Y

Y

DDL

CREATE TEXT SEARCH TEMPLATE

Y

Y

DDL

CREATE TRANSFORM

Y

Y

DDL

CREATE TRIGGER

Y

Y

DDL

CREATE TYPE

Y

Y

DDL

CREATE TYPE BODY

Y

Y

DDL

CREATE USER MAPPING

Y

Y

DDL

CREATE VIEW

Y

Y

DDL

DEALLOCATE

Y

N

N

DEALLOCATE ALL

Y

N

N

DECLARE CURSOR

Y

N

N

DISCARD

Y

N

N

DISCARD ALL

Y

N

N

DISCARD PLANS

Y

N

N

DISCARD SEQUENCES

Y

N

N

DISCARD TEMP

Y

N

N

DO

Y

N

N

DROP ACCESS METHOD

Y

Y

DDL

DROP AGGREGATE

Y

Y

DDL

DROP CAST

Y

Y

DDL

DROP COLLATION

Y

Y

DDL

DROP CONSTRAINT

Y

Y

DDL

DROP CONVERSION

Y

Y

DDL

DROP DATABASE

Y

N

N

DROP DATABASE LINK

Y

Y

DDL

DROP DIRECTORY

Y

Y

DDL

DROP DOMAIN

Y

Y

DDL

DROP EVENT TRIGGER

Y

Y

DDL

DROP EXTENSION

Y

Y

DDL

DROP FOREIGN DATA WRAPPER

Y

Y

DDL

DROP FOREIGN TABLE

Y

Y

DDL

DROP FUNCTION

Y

Y

DDL

DROP INDEX

Y

Y

DDL

DROP LANGUAGE

Y

Y

DDL

DROP MATERIALIZED VIEW

Y

N

N

DROP OPERATOR

Y

Y

DDL

DROP OPERATOR CLASS

Y

Y

DDL

DROP OPERATOR FAMILY

Y

Y

DDL

DROP OWNED

Y

Y

DDL

DROP PACKAGE

Y

Y

DDL

DROP PACKAGE BODY

Y

Y

DDL

DROP POLICY

Y

Y

DDL

DROP PROCEDURE

Y

Y

DDL

DROP PROFILE

Y

Y

DDL

DROP PUBLICATION

Y

Y

DDL

DROP QUEUE

Y

Y

DDL

DROP QUEUE TABLE

Y

Y

DDL

DROP REDACTION POLICY

Y

Y

DDL

DROP RESOURCE GROUP

Y

N

N

DROP ROLE

Y

Y

DDL

DROP ROUTINE

Y

Y

DDL

DROP RULE

Y

Y

DDL

DROP SCHEMA

Y

Y

DDL

DROP SEQUENCE

Y

Y

DDL

DROP SERVER

Y

Y

DDL

DROP STATISTICS

Y

Y

DDL

DROP SUBSCRIPTION

Y

Y

DDL

DROP SYNONYM

Y

Y

DDL

DROP TABLE

Y

Y

DML

DROP TABLESPACE

Y

N

N

DROP TEXT SEARCH CONFIGURATION

Y

Y

DDL

DROP TEXT SEARCH DICTIONARY

Y

Y

DDL

DROP TEXT SEARCH PARSER

Y

Y

DDL

DROP TEXT SEARCH TEMPLATE

Y

Y

DDL

DROP TRANSFORM

Y

Y

DDL

DROP TRIGGER

Y

Y

DDL

DROP TYPE

Y

Y

DDL

DROP TYPE BODY

Y

Y

DDL

DROP USER MAPPING

Y

Y

DDL

DROP VIEW

Y

Y

DDL

EXECUTE

Y

N

N

EXPLAIN

Y

アーキテクチャの詳細

アーキテクチャの詳細

FETCH

Y

N

N

GRANT

Y

アーキテクチャの詳細

DDL

GRANT ROLE

Y

Y

DDL

IMPORT FOREIGN SCHEMA

Y

Y

DDL

LISTEN

Y

N

N

LOAD

Y

N

N

LOAD ROW DATA

Y

Y

DDL

LOCK TABLE

Y

N

アーキテクチャの詳細

MOVE

Y

N

N

NOTIFY

Y

N

N

PREPARE

Y

N

N

PREPARE TRANSACTION

Y

N

N

REASSIGN OWNED

Y

Y

DDL

REFRESH MATERIALIZED VIEW

Y

N

N

REINDEX

Y

N

N

RELEASE

Y

N

N

RESET

Y

N

N

REVOKE

Y

アーキテクチャの詳細

DDL

REVOKE ROLE

Y

Y

DDL

ROLLBACK

Y

N

N

ROLLBACK PREPARED

Y

N

N

SAVEPOINT

Y

N

N

SECURITY LABEL

Y

アーキテクチャの詳細

DDL

SELECT INTO

アーキテクチャの詳細

Y

DDL

SET

Y

N

N

SET CONSTRAINTS

Y

N

N

SHOW

Y

N

N

START TRANSACTION

Y

N

N

TRUNCATE TABLE

Y

アーキテクチャの詳細

アーキテクチャの詳細

UNLISTEN

Y

N

N

VACUUM

Y

N

N

ALTER SEQUENCE#

一般にALTER SEQUENCE がサポートされていますが、グローバルシーケンスを使用する場合、一部のオプションは効果がありません。

ALTER SEQUENCE ... RENAME は、gallocシーケンスのみでサポートされていません。 ALTER SEQUENCE ... SET SCHEMA は、gallocシーケンスのみでサポートされていません。

ALTER TABLE#

通常、 ALTER TABLE コマンドは許可されます。ただし、いくつかのサブコマンドはサポートされていません。

ALTER TABLEは許可されないコマンド#

ALTER TABLE の一部のバリアントは、現在PGDノードで使用できません。

  • ADD COLUMN ... DEFAULT (non-immutable expression) —これは、現在別のノードで別のデータになるため、許可されていません。推奨される回避策については、 列の追加 を参照してください。

  • ADD CONSTRAINT ... EXCLUDE —除外コンストレインは、現時点ではサポートされていません。除外コンストレインは非同期システムではあまり意味がなく、再生できない変更をもたらします。

  • ALTER TABLE ... SET WITH[OUT] OIDS — CREATE TABLE と同じ理由でサポートされていません。

  • ALTER COLUMN ... SET STORAGE external —列がテーブルのレプリカIDの列の1つである場合、拒否されます。

  • RENAME —自動パーティション化されたテーブルの名前は変更できません。

  • SET SCHEMA —自動パーティション化されたテーブルのスキーマは設定できません。

  • ALTER COLUMN ... TYPE —コマンドによってテーブル全体が書き換えられる場合、列のタイプの変更はサポートされません。これは、変更がバイナリ強制可能でない場合に発生します。バイナリの強制変更は、一方通行のみが許可される場合があります。たとえば、VARCHAR(128) からVARCHAR(256) への変更はバイナリ強制可能であるため許可されますが、 VARCHAR(256) からVARCHAR(128) への変更はバイナリ強制可能ではないため、通常は許可されません。非レプリケートのALTER COLUMN ... TYPE は、列が新しいタイプに自動的にキャスト可能である場合に許可されますUSING 句が含まれません。次に例を示します。テーブルリライトは、大規模なテーブルでAccessExclusiveLockを長期間保持するため、このようなコマンドは、いずれの場合も高可用データベースでは実行不可能である可能性があります。推奨される回避策については、 列のタイプの変更 を参照してください。

  • ALTER TABLE ... ADD FOREIGN KEY —現在のユーザーが参照されるテーブルを読み取る権限がない場合、または参照されるテーブルで現在のユーザーがバイパスできないRLS制限が有効になっている場合、サポートされません。

次の例は、 timestamp 型の定数値をtimestamptz 型の列に追加しようとするため、失敗します。 timestamp とtimestamptz 間のキャストは、セッションのタイムゾーンに依存するため、不変ではありません。

ALTER TABLE foo
  ADD expiry_date timestamptz DEFAULT timestamp 2100-01-01 00:00:00 NOT NULL;

PGD 3.7.4以降、DMLロックを取得せずに、 CHECK やFOREIGN KEY 制約などの特定のタイプの制約を追加できます。ただし、これには、最初にNOT VALID 制約を作成し、次に ALTER TABLE ... VALIDATE CONSTRAINT コマンドを使用して別のトランザクションで制約を検証する2段階のプロセスが必要です。

詳細については、

ALTER TABLE ロック#

ALTER TABLE の次のバリアントは、 DDLロックのみを取得し、DMLロックは取得しません。

  • ALTER TABLE ... ADD COLUMN ... (immutable) DEFAULT

  • ALTER TABLE ... ALTER COLUMN ... SET DEFAULT expression

  • ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT

  • ALTER TABLE ... ALTER COLUMN ... TYPE リライトが必要ない場合

  • ALTER TABLE ... ALTER COLUMN ... SET STATISTICS

  • ALTER TABLE ... VALIDATE CONSTRAINT

  • ALTER TABLE ... ATTACH PARTITION

  • ALTER TABLE ... DETACH PARTITION

  • ALTER TABLE ... ENABLE TRIGGER ENABLE REPLICA TRIGGER は引き続きDMLロックを取得します

  • ALTER TABLE ... CLUSTER ON

  • ALTER TABLE ... SET WITHOUT CLUSTER

  • ALTER TABLE ... SET ( storage_parameter = value [, ... ] )

  • ALTER TABLE ... RESET ( storage_parameter = [, ... ] )

  • ALTER TABLE ... OWNER TO

ALTER TABLE の他のすべてのバリアントは、変更されるテーブルでDMLロックを取得します。 ALTER TABLE の一部のバリアントには、以下に説明する制限があります。

ALTER TABLEの例#

この次の例は、型の変更がバイナリ強制可能であるため、テーブルの書き換えが発生しないため、機能します。カタログのみの変更として実行されます。

CREATE TABLE foo (id BIGINT PRIMARY KEY, description VARCHAR(20));
ALTER TABLE foo ALTER COLUMN description TYPE VARCHAR(128);

ただし、 VARCHAR(128) からVARCHAR(20) への変更はバイナリ強制可能ではないため、コマンドを逆に変更することは不可能です。

ALTER TABLE foo ALTER COLUMN description TYPE VARCHAR(20);

回避策については、 制限されDDLの回避策 を参照してください。

一般におよび非レプリケート環境で可能なさまざまなタイプのALTER TABLE ... ALTER COLUMN TYPE ATCT操作のコンテキストを提供すると役立ちます。

一部のATCT操作は、基になる列タイプのメタデータのみを更新し、基になるテーブルデータの書き換えは必要ありません。これは通常、既存の列タイプとターゲットタイプがバイナリ強制可能な場合に当てはまります。例

CREATE TABLE sample (col1 BIGINT PRIMARY KEY, col2 VARCHAR(128), col3 INT);
ALTER TABLE sample ALTER COLUMN col2 TYPE VARCHAR(256);

バイナリの強制性のため、列タイプをVARCHAR またはTEXT データ型に変更することもできます。繰り返しますが、これは基になる列タイプの単なるメタデータの更新です。

ALTER TABLE sample ALTER COLUMN col2 TYPE VARCHAR;
ALTER TABLE sample ALTER COLUMN col2 TYPE TEXT;

ただし、col2のサイズを削減したい場合は、基になるテーブルデータの書き換えが必要になります。テーブルの書き換えは通常制限されています。

ALTER TABLE sample ALTER COLUMN col2 TYPE VARCHAR(64);
ERROR:  ALTER TABLE ... ALTER COLUMN TYPE that rewrites table data may not affect replicated tables on a PGD node

非テキストタイプの例として、INTEGERタイプを使用した上記のcol3を検討します。 SMALLINTまたはBIGINTに変換しようとするATCT操作は、上記と同様の方法で失敗します。

ALTER TABLE sample ALTER COLUMN col3 TYPE bigint;
ERROR:  ALTER TABLE ... ALTER COLUMN TYPE that rewrites table data may not affect replicated tables on a PGD node

これらの失敗したケースは両方とも、現在の型からターゲット型への自動割り当てキャストがあります。ただし、バイナリの強制力がないため、基になるテーブルデータの書き換えが発生します。

このような場合、制御されたDBA環境では、すべてのノードの非レプリケート環境でこの列のタイプのローリングアップグレードを採用することにより、列のタイプを自動的にキャスト可能なものに変更できます。 DDLはレプリケートされず、列型の変更は自動的にキャスト可能なものであると仮定します。次に、この同じテーブル上の他のノードでの同時アクティビティとともに、変更を実行するノードでローカルに書き換えを許可できます。次に、すべてのノードでこの非レプリケートのATCT操作を1つずつ繰り返し、 EDB Postgres分散クラスター全体で列タイプの目的の変更をもたらすことができます。これには書き換えが含まれるため、アクティビティは引き続き短期間DMLロックを取得するため、クラスター全体が利用できる必要があります。これらの詳細を設定すると、次のような非レプリケートの変更アクティビティのローリングアップグレードを実行できます。

- - foreach node in EDB Postgres Distributed cluster do:
SET bdr.ddl_replication TO FALSE;
ALTER TABLE sample ALTER COLUMN col2 TYPE VARCHAR(64);
ALTER TABLE sample ALTER COLUMN col3 TYPE BIGINT;
RESET bdr.ddl_replication;
- - done

自動割り当てキャストは多くのデータ型で利用できるため、このローカルの非レプリケートATCT操作は、さまざまな変換をサポートします。また、 USING 句を使用するATCT操作は、自動割り当てキャストがないため失敗する可能性があります。この例は、自動割り当てキャストを使用したいくつかの一般的な変換を示しています。

- - foreach node in EDB Postgres Distributed cluster do:
SET bdr.ddl_replication TO FALSE;
ATCT operations to-from {INTEGER, SMALLINT, BIGINT}
ATCT operations to-from {CHAR(n), VARCHAR(n), VARCHAR, TEXT}
ATCT operations from numeric types to text types
RESET bdr.ddl_replication;
- - done

この例は、非レプリケート環境で許可される可能性のあるATCT操作の完全なリストではありません。すべてのATCT操作が機能するわけではありません。自動割り当てができない場合、 DDLレプリケーションを無効にしても失敗します。したがって、数値型からテキスト型への変換は非レプリケート環境で機能しますが、テキスト型から数値型への逆変換は失敗します。

SET bdr.ddl_replication TO FALSE;
- - conversion from BIGINT to TEXT works
ALTER TABLE sample ALTER COLUMN col3 TYPE TEXT;
- - conversion from TEXT back to BIGINT fails
ALTER TABLE sample ALTER COLUMN col3 TYPE BIGINT;
ERROR:  ALTER TABLE ... ALTER COLUMN TYPE which cannot be automatically cast to new type may not affect replicated tables on a PGD node
RESET bdr.ddl_replication;

非レプリケート環境のATCT操作はさまざまな型変換をサポートしていますが、基になるテーブルデータに新しいデータ型に割り当てできない値が含まれている場合、リライトは失敗する場合があります。たとえば、列の現在のタイプがVARCHAR(256) で、非レプリケートATCT操作を試行してVARCHAR(128) に変換するとします。テーブルに128バイトを超える既存のデータがある場合、書き換え操作はローカルに失敗します。

INSERT INTO sample VALUES (1, repeat(a, 200), 10);
SET bdr.ddl_replication TO FALSE;
ALTER TABLE sample ALTER COLUMN col2 TYPE VARCHAR(128);
INFO:  in rewrite
ERROR:  value too long for type character varying(128)

基になるテーブルデータが新しい型の特性を満たしている場合、書き換えは成功します。ただし、非レプリケートのローリングデータタイプのアップグレードをまだ実行していない他のノードが、128バイトより広い新しいデータをこのローカルATCT操作に同時に導入する場合、レプリケーションは失敗する可能性があります。これにより、クラスターでのレプリケーションが停止します。したがって、これらの非レプリケートのローリングデータ型のアップグレード操作を実行する間は、データベースおよびアプリケーションレベルでのデータ型の制限と特性に注意してください。このようなATCT操作は、制御された完全に認識したDBA環境で実行およびテストすることを強くお勧めします。これらのATCT操作は非対称であり、失敗した特定の変更をバックアウトすると、時間がかかるテーブルの書き換えが発生する可能性があります。

また、トランザクションブロックで暗黙的なキャスト可能ALTERアクティビティを実行することはできません。

ALTER TYPE#

ALTER TYPE はレプリケートされますが、 PostgreSQLはこれらの依存関係を記録しないため、グローバルDMLロックはそのデータ型を使用するすべてのテーブルに適用されません。

制限されDDLの回避策 を参照してください。

コメントオン#

COMMENT ON のすべてのバリアントが許可されますが、 COMMENT ON TABLESPACE/DATABASE/LARGE OBJECT はレプリケートされません。

CREATE PROFILEまたはALTER PROFILE#

ファンクションがSECURITY DEFINER の場合、プロファイルに関連付けられているPASSWORD_VERIFY_FUNCTION はIMMUTABLE である必要があります。このようなCREATE PROFILE またはALTER PROFILE コマンドはレプリケートされますが、このプロファイルを使用する後続のCREATE USER またはALTER USER コマンドは、 writer ワーカーがcannot change current role within security-restricted operation エラーをスローするため、レプリケーションを中断します。

CREATE SEQUENCE#

一般にCREATE SEQUENCE がサポートされていますが、グローバルシーケンスを使用する場合、一部のオプションは効果がありません。

CREATE TABLE#

一般にCREATE TABLE はサポートされていますが、 CREATE TABLE WITH OIDS はPGDノードでは許可されていません。

CREATE TABLE ASとSELECT INTO#

CREATE TABLE AS およびSELECT INTO は、すべてのサブコマンドも許可される場合にのみ許可されます。

EXPLAIN#

一般にEXPLAIN は許可されますが、 EXPLAIN ANALYZE はデータベースに副作用を与える可能性があるため、いくつかの制限があります。

EXPLAIN ANALYZEレプリケーション#

EXPLAIN ANALYZE は、分析されたステートメントのレプリケーションルールに従います。

EXPLAIN ANALYZEロック#

EXPLAIN ANALYZE は、分析されたステートメントのロックルールに従います。

GRANTとREVOKE#

通常、GRANT およびREVOKE ステートメントはサポートされていますが、 GRANT/REVOKE ON TABLESPACE/LARGE OBJECT はレプリケートされません。

ロックテーブル#

LOCK TABLEはレプリケートされませんが、 bdr.lock_table_locking がon に設定されている場合、グローバルDMLロックを取得する場合があります。

bdr.global_lock_table() ファンクションを使用して、グローバルDMLロックを明示的に要求することもできます。

セキュリティラベル#

SECURITY LABEL のすべてのバリアントが許可されますが、 SECURITY LABEL ON TABLESPACE/DATABASE/LARGE OBJECT はレプリケートされません。

TRUNCATEレプリケーション#

TRUNCATE コマンドは、 DDLステートメントではなくDMLとしてレプリケートされます。テーブルのTRUNCATE がレプリケートされるかどうかは、影響を受ける各テーブルのレプリケーション設定によって異なります。

TRUNCATEロック#

TRUNCATE は他のDDLと同じ方法でレプリケートされませんが、 bdr.truncate_locking がon に設定されている場合、グローバルDMLロックを取得できます。

ロール操作ステートメント#

ユーザーはPostgreSQLインスタンスのグローバルオブジェクトです。つまり、ユーザーは複数のデータベースにまたがりますが、 PGDは個々のデータベースレベルで動作します。これは、ロール操作ステートメントの処理に追加の検討が必要であることを意味します。

PGDでは、レプリケートされたDDLによって参照されるロールがすべてのノードに存在する必要があります。ロールの付与、パスワードなどは同じである必要はありませんが、存在する必要があります。

bdr.role_replication が有効デフォルトであり、ロール操作ステートメントがPGD対応データベースで実行されている場合、PGDはロール操作ステートメントをレプリケートします。

ロール操作ステートメントには次のものが含まれます。

  • CREATE ROLE

  • ALTER ROLE

  • DROP ROLE

  • GRANT ROLE

  • CREATE USER

  • ALTER USER

  • DROP USER

  • CREATE GROUP

  • ALTER GROUP

  • DROP GROUP

一般に、次のいずれかです。

  • bdr.role_replication = off でシステムを構成し、Ansible、Puppet、Chefなどの外部オーケストレーションツールまたはbdr.replicate_ddl_command(...) によって明示的にレプリケートされて、すべてのロール変更ユーザーとグループを展開します。

  • PostgreSQLインスタンス上のちょうど1つのPGD対応データベースがbdr.role_replication = on を持つようにシステムを構成し、そのデータベースですべてのロール管理DDLを実行します。

すべてのロール管理コマンドを1つのデータベースで実行することをお勧めします。

ロールレプリケーションがオフになっている場合、管理者は、あるノードでDDLが使用するロールが他のノードにも存在することを確認する必要があります。それ以外の場合、PGD applyは、他のノードでロールが作成されるまで、エラーでストールします。

注釈

PGDは、 PGD対応のPostgreSQLインスタンスの非PGD対応データベースで実行される場合、ロール管理ステートメントをキャプチャおよびレプリケートしません。たとえば、DB 'bdrdb' bdrグループメンバーと'postgres'ベアdb、および`bdr.role_replication = on` がある場合、 bdrdb で実行される`CREATE USER` はレプリケートされますが、 postgres で実行される`CREATE USER` はレプリケートされません。

制限されDDLの回避策#

PGD DDLオペレーション処理の制限の一部は回避できます。多くの場合、操作をより小さな変更に分割すると、単一のステートメントとして許可されないか、過剰なロックが必要な目的の結果が生成される場合があります。

コンストレインの追加#

DMLロックを必要とせずにCHECK およびFOREIGN KEY 制約を追加できます。これには、2段階のプロセスが含まれます。

  • ALTER TABLE ... ADD CONSTRAINT ... NOT VALID

  • ALTER TABLE ... VALIDATE CONSTRAINT

2つの異なるトランザクションでこれらの手順を実行します。これらの手順は両方とも、テーブルでのみDDLロックを取得するため、1つ以上のノードがダウンしている場合でも実行できます。ただし、コンストレインを検証するには、PGDは次のことを確認する必要があります。

  • クラスター内のすべてのノードはADD CONSTRAINT コマンドを参照します。

  • コンストレインを検証するノードは、これらのノードにNOT VALIDコンストレインを作成する前に、他のすべてのノードからレプリケーション変更を適用します。

したがって、新しいメカニズムでは、制約の検証中にすべてのノードがアップしている必要はありませんが、すべてのノードがALTER TABLE .. ADD CONSTRAINT ... NOT VALID コマンドを適用し、十分に進行していることは必要です。 PGDは、コンストレインを検証する前に、一貫した状態に到達するのを待機します。

新しい機能では、クラスターがRaftプロトコルバージョン24以降で実行されている必要があります。 Raftプロトコルがまだアップグレードされていない場合、古いメカニズムが使用され、DMLロック要求が発生します。

列の追加#

揮発性のデフォルトを使用して列を追加するには、別のトランザクションで次のコマンドを実行します。

ALTER TABLE mytable ADD COLUMN newcolumn coltype; -- Note the lack of DEFAULT or NOT NULL

ALTER TABLE mytable ALTER COLUMN newcolumn DEFAULT volatile-expression;

BEGIN;
SELECT bdr.global_lock_table(mytable);
UPDATE mytable SET newcolumn = default-expression;
COMMIT;

このアプローチでは、スキーマの変更と行の変更をPGDが実行できる別のトランザクションに分割し、PGDグループ内のすべてのノードで一貫したデータが得られます。

最良の結果を得るには、更新をチャンクにバッチ処理して、一度に数万〜数十万行を更新しないようにします。これは、埋め込みトランザクションでPROCEDURE を使用して行うことができます。

変更の最後のバッチは、テーブルのグローバルDMLロックを取得するトランザクションで実行する必要があります。そうしないと、他のノードのテーブルに同時に挿入される行を見逃す可能性があります。

必要に応じて、UPDATE が完了した後、ALTER TABLE mytable ALTER COLUMN newcolumn NOT NULL; を実行できます。

列のタイプの変更#

列のタイプを変更すると、PostgreSQLがテーブルを書き換える場合があります。ただし、場合によっては、この書き換えを回避できる場合があります。例

CREATE TABLE foo (id BIGINT PRIMARY KEY, description VARCHAR(128));
ALTER TABLE foo ALTER COLUMN description TYPE VARCHAR(20);

制限をデータ型の変更ではなくテーブル制約にすることにより、テーブルのリライトを回避するようにこのステートメントをリライトできます。必要に応じて、後続のコマンドでコンストレインを検証して、長いロックを回避できます。

CREATE TABLE foo (id BIGINT PRIMARY KEY, description VARCHAR(128));
ALTER TABLE foo
  ALTER COLUMN description TYPE varchar,
  ADD CONSTRAINT description_length_limit CHECK (length(description) <= 20) NOT VALID;
ALTER TABLE foo VALIDATE CONSTRAINT description_length_limit;

検証が失敗した場合は、失敗した行のみをUPDATE できます。このテクニックは、 length() を使用するか、 scale() を使用してNUMERIC データ型を使用するTEXT およびVARCHAR に使用できます。

列タイプを変更する一般的な場合、最初に目的のタイプの列を追加します。

ALTER TABLE mytable ADD COLUMN newcolumn newtype;

BEFORE INSERT OR UPDATE ON mytable FOR EACH ROW .. として定義されたトリガーを作成します。これは、テーブルへの新しい書き込みによって新しい列が自動的に更新されるように、NEW.newcolumn をNEW.oldcolumn に割り当てます。

UPDATE 埋め込みトランザクションでPROCEDURE を使用して、oldcolumn の値をnewcolumn にコピーするバッチ内のテーブル。作業をバッチ処理することは、大きなテーブルの場合、レプリケーションラグを削減するのに役立ちます。 IDの範囲または任意の方法で更新しても問題ありません。または、小さなテーブルの場合、1パスでテーブル全体を更新できます。

CREATE INDEX ... 新しい列に必要なインデックス。ロック期間を短縮するために、各ノードでDDLレプリケーションを使用せずに個別に実行されるCREATE INDEX ... CONCURRENTLY を使用するのが安全です。

ALTER 必要に応じて、NOT NULL およびCHECK 制約を追加する列。

  1. BEGIN トランザクション。

  2. DROP 追加したトリガー。

  3. ALTER TABLE 列に必要なDEFAULT を追加します。

  4. DROP 古い列。

1.ALTER TABLE mytable RENAME COLUMN newcolumn TO oldcolumn .

1.COMMIT .

注釈

列を削除するため、テーブルに依存するビュー、プロシージャなどを再作成する必要がある場合があります。列を削除する場合は、それを参照したすべてを再作成する必要があるため、注意してください。

他のタイプの変更#

ALTER TYPE ステートメントはレプリケートされますが、影響を受けるテーブルはロックされていません。

このDDLを使用する場合、新しいタイプを使用する前に、すべてのノードでステートメントが正常に実行されたことを確認してください。これは、 bdr.wait_slot_confirm_lsn() ファンクションを使用して実現できます。

この例では、DMLステートメントで新しい値を使用する前に、 DDLがすべてのノードに書き込まれるようにします。

ALTER TYPE contact_method ADD VALUE email;
SELECT bdr.wait_slot_confirm_lsn(NULL, NULL);

DDLのように動作するPGDファンクション#

次のPGD管理機能はDDLのように動作します。これは、 DDLレプリケーションがアクティブで、 DDLフィルター設定で許可されている場合、グローバルロックを取得しようとし、アクションがレプリケートされることを意味します。詳細については、各機能のドキュメントを参照してください。

レプリケーションセット管理

  • bdr.create_replication_set

  • bdr.alter_replication_set

  • bdr.drop_replication_set

  • bdr.replication_set_add_table

  • bdr.replication_set_remove_table

  • bdr.replication_set_add_ddl_filter

  • bdr.replication_set_remove_ddl_filter

競合管理

  • bdr.alter_table_conflict_detection

  • bdr.column_timestamps_enable

  • bdr.column_timestamps_disable

シーケンス管理

  • bdr.alter_sequence_set_kind

ストリームトリガー

  • bdr.create_conflict_trigger

  • bdr.create_transform_trigger

  • bdr.drop_trigger