DDL replication

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

操作の利便性と正確さのために、 BDRはほとんどのDDLアクションをレプリケートしますが、次の例外があります。

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

  • 特定のDDLステートメント（ほとんどが長時間実行）;

    DDL statements with restrictions を参照）

  • ロックコマンド（LOCK ）

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

  • autovacuumのアクション

・操作コマンド（CHECKPOINT 、ALTER SYSTEM ）

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

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

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

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

テーブルレプリケーションとの主な違いは、 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;

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

警告

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

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

BDRシステムでのDDLの実行

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

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

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

BDRは、これらの問題に対して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種類のロックは、 BDRでレプリケートされたDDLの正確性を強制します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DDLのように動作するBDR関数 にリストされています。

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

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

グローバルDDLロックとグローバルDMLロックのモニタリングは、 Monitoring に示されています。

DDLの影響の最小化

任意のデータベースに対する優れた運用上のアドバイス、これらの点はBDRではさらに重要になります。

  • 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$);

bdr.run_on_all_nodes() テクニックをCREATE INDEX CONCURRENTLY で使用することをお勧めします。 CREATE INDEX CONCURRENTLY はマルチトランザクションコマンドであるため、セッション全体でDDLレプリケーションを無効にする必要があることに注意してください。実行中の書き込みを防ぐため、実稼働システムでは CREATE INDEX を避けてください。 REINDEX は3.6までのバージョンで複製されますが、 BDR 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操作がコミットされると、キャンセルまたは中止できません。 BDRグループは、グローバルロックを確認した他のノードに正常に適用され、再生を確認するまで待機する必要があります。このため、 DDLトランザクションは短くて高速に保ちます。

ダウンノードでのDDLの処理

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

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

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

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

グローバルDDLまたはグローバルDMLロックを使用すると、別のノードがダウンした場合、コマンドは正常に続行され、ロックが解放されます。

ステートメント固有のDDLレプリケーションに関する問題

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

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

DDL statements with restrictions で説明されています。

BDRで完全に許可されないコマンドは、禁止されているDDLステートメントで説明されています。

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

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

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

BDR 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

DDL

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

DDL

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シーケンス

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

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

ALTERテーブル

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

ALTER TABLEで許可されていないコマンド

ALTER TABLE の一部のバリアントは現在BDRノードで許可されていません。

  • ADD COLUMN ... DEFAULT (non-immutable expression) —現在、異なるノードで異なるデータが得られるため、これは許可されません。推奨される回避策については、

    列の追加 を参照してください。

  • ADD CONSTRAINT ... EXCLUDE —除外制約は現在サポートされていません。除外制約は非同期システムではあまり意味がなく、再生できない変更につながります。

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

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

  • 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;

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

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 BDR 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 BDR node

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

このような場合、制御されたDBA環境では、すべてのノードの非レプリケート環境でこの列のタイプのローリングアップグレードを1つずつ採用することにより、列のタイプを自動的にキャスト可能なものに変更できます。 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 BDR 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)

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

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

ALTERタイプ

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

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

コメント

COMMENT ON のすべてのバリアントが許可されていますが、 COMMENT ON TABLESPACE/DATABASE/LARGE OBJECT は複製されません。

シーケンスを作成する

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

テーブルを作成する

通常、 CREATE TABLE はサポートされていますが、 BDRノードではCREATE TABLE WITH OIDS は許可されていません。

CREATE TABLE ASとSELECT INTO

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

説明する

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

EXPLAIN ANALYZEレプリケーション

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

EXPLAIN ANALYZEロック

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

付与と取り消し

通常、 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インスタンスのグローバルオブジェクトです。つまり、 BDRは個々のデータベースレベルで動作します。これは、ロール操作ステートメントの処理には追加の考慮が必要であることを意味します。

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

bdr.role_replication が有効になっており（デフォルト）、ロール操作ステートメントがBDR対応のデータベースで実行されている場合、 BDRはロール操作ステートメントを複製します。

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

  • 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つのBDR対応データベースがbdr.role_replication = on を持つようにシステムを構成し、そのデータベースですべてのロール管理DDLを実行します。

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

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

注釈

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

制限されDDLの回避策

BDR DDL操作処理の制限の一部を回避できます。多くの場合、操作を小さな変更に分割すると、単一のステートメントとして許可されないか、過度のロックが必要な結果が得られます。

CONSTRAINTの追加

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

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

  • ALTER TABLE ... VALIDATE CONSTRAINT

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

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

  • 制約を適用するノードは、それらのノードにNOT VALID制約を作成する前に、他のすべてのノードからレプリケーションを変更します。

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

新しい機能では、クラスターが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;

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

最良の結果を得るには、更新をチャンクにまとめて、一度に数万または数十万を超える行を更新しないようにします。これは、トランザクションが埋め込まれた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() を使用してTEXT およびVARCHAR 、またはscale() を使用してNUMERIC データ型でこの手法を使用できます。

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

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レプリケーションなしで個別に実行しても安全です。

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

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

1.追加したトリガーをDROP します。

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

1.古い列をDROP 。

  1. ALTER TABLE mytable RENAME COLUMN newcolumn TO oldcolumn 。

  2. COMMIT 。

注釈

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

他のタイプの変更

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のように動作するBDR関数

次のBDR管理機能は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