DDL Replication

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

操作上の利便性と正確さのために、 BDRは次の例外を除き、ほとんどのDDLactionsを複製します。

• 一時的またはログに記録されていないリレーション

• 特定の、主に長時間実行さDDLステートメント（以下のリストを参照）

• ロックコマンド（LOCK）

• テーブル保守コマンド（VACUUM、 ANALYZE、CLUSTER、REINDEX） オートバキュームのアクション

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

• データベースまたは表領域に関連するアクション

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

デフォルトのレプリケーションセットでは、 DDLはデフォルトですべてのノードに複製されますDDLDDLレプリケーションを追加する必要があります。 [DDL Replication Filtering]を参照してください。

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

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

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

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

bdr.ddl_replication = onがデフォルトであり、 DDLをデフォルトのレプリケーションセットに複製します。これはデフォルトですべてのノードを意味します。デフォルト以外の複製セットは、aDDL filterが定義されていない限り、 DDLを複製しません。

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

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;

設定makeと、 BDRがグローバルロックと実行されたDDLコマンドの複製の両方をスキップするため、すべてのノードでDDLを手動で実行する必要があります。

!!! Warning * グローバルロックなしで各ノードでDDLを手動で実行すると、競合するDDLまたはDMLが同時に実行されると、 BDRグループ全体の複製が停止する可能性があります。

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

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、 スーパーユーザ、または構成ファイルでのみ設定できます。

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

DDLロックの詳細

BDRを使用して複製されたDDLの正確さを強制するために使用されるロックには、2種類があります。

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

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

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

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

2番目の種類は、リレーションDMLロックと呼ばれます。この種類のロックは、ddl_locking = onまたはddl_locking = dmlのいずれかであり、一意性制約、検査制約、NOT NULL制約などの制約を追加または変更する場合など、 DDLステートメントによって飛行中のDMLステートメントが失敗する場合に使用されます。一度に1つのリレーション。リレーション保証は、キューに変更があり、エラーでレプリケーションが停止する可能性がある間、 DDLが実行されないようにします。

テーブルのグローバルDMLロックを取得するために、DDLを実行しているBDRノードは、 BDRグループ内の他のすべてのノードに連絡し、書き込みに対してテーブルをロックするように要求し、そのテーブルに対するすべての保留中の変更が排出されるまで待機します。すべてのノードが完全に追いついており、DMLロックの発信者はテーブルのスキーマ変更を自由に実行し、それらを他のノードに複製します。

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

保留中のDML操作が排出されるのを待つには時間がかかるか、レプリケーションが現在遅れている場合は長くなります。つまり、行の表現形式とコンストレインに影響するスキーマ変更は、データの変更とは異なり、構成されたすべてのノードが到達可能であり、合理的に維持されている場合にのみ実行できますノードがダウンしている間にそのようなDDLコマンドを絶対に実行する必要がある場合、ダウンノードを最初に構成から削除する必要がありレート。

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

ロック動作は、Executing DDL on BDR systemsで説明されているように、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のように機能することに注意してください。つまり、DDLreplicationがアクティブな場合、グローバルロックの取得を試み、そのアクションが複製されます。複製された関数の完全なリストは、DDLのように動作するBDRFunctionsにリストされています。

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

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

グローバルDDLロックおよびグローバルDMLロックの監視については、Monitoringの章で説明しています。

DDLの影響を最小限に抑える

すべてのデータベースに対する適切な運用上のアドバイス、これらのポイントはBDRでさらに重要になります。

DDLのインパクトを最小限に抑えるため、 DDLを実行するトランザクションは短くする必要があります。 行の多くの変更と組み合わせてはならず、長い間避けるべきです 外部キーまたは他の制約の再チェックを実行します。

• ALTER TABLEの場合は、ADD CONSTRAINT NOT VALIDを使用してから、別の ADD CONSTRAINTを使用するだけでなく、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（）テクニックをCREATEINDEX CONCURRENTLYで使用することをお勧めし稼動。CREATEINDEX CONCURRENTLYはマルチトランザクションコマンドであるため、 DDLレプリケーションをセッション全体で無効にする必要があることに注意してください。 REINDEXはBDR3.6までのバージョンで複製されますが、BDR3.7以降では複製されません。REINDEXの使用は、AccessExclusiveLocksが保持されているため避ける必要があります。

代わりに、PG12 +または2QPG11 +で使用可能なREINDEX CONCURRENTLYを使用する（またはreindexdb –concurrently）必要があります。

無効なインデックスに対するREINDEXまたはREINDEX CONCURRENTLYは、 BDRノードでの実行に失敗します。無効なインデックスは、ドロップして再度作成する必要がありノード。無効なインデックスは、 DDL BDR ..を使用してドロップする必要があります。

次のようなコマンドラインユーティリティを使用する場合、 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ロックをキャンセルすることはできません。

（オプショナルの）グローバルロックタイムアウト設定で、グローバルロックをロックするwaitforがキャンセル長さトランザクションまでの時間を制限します。グローバルロックを保持し、bdr.global_lock_idle_timeoutは、グローバルロックを保持するトランザクションの最大許容アイドル時間（ステートメント間の時間）を設定します。これらのタイムアウトはすべて、値をゼロに設定することで無効にできます。

発信元ノードでDDLオペレーションがコミットされると、キャンセルまたは中止できません。 BDRグループは、グローバルロックを確認した他のノードに正常に適用され、リプレイを確認するまで待機する必要があります。これが、 DDLトランザクションを短く高速に保つことが重要な理由です。

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

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

長時間（または永久に）ダウンしたままになっている場合は、グローバルロックをリリースオーダーにBDRグループからノードを削除します。これが、SETコマンドをbdr_superuserとして使用してbdr.ddl_locking値を更新する緊急DDLを実行する理由の1つである可能性があります。

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

前のセクションで述べたように、グローバルDDLロックは応答するノードの過半数のみを必要とするため、大部分が実行中で到達可能である限り、クラスターのパートがダウンしていても機能しますが、DMLロックはクラスタ全体が利用可能です。

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

ステートメント固有のDDLレプリケーションの懸念

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

BDRは、データベース上でアクティブなときに一部のDDLステートメントが実行されないようにします。これにより、正しく複製できないステートメントやレプリケーションがまだサポートされていないステートメントを禁止することにより、システムの一貫性が保護されます。一部の制限付きでサポートされているステートメントは、[制限付きのDDLステートメント]で説明されています。一方、 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	` Details <#bdr_ ddl_allowed_Al terSeqStmt>`__	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	De tails	Y	Details
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	D etails	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	D etails	Y	DDL
CREATE SERVER	Y	Y	DDL
CREATE STATISTICS	Y	Y	DDL
CREATE SUBSCRIPTION	Y	Y	DDL
CREATE SYNONYM	Y	Y	DDL
CREATE TABLE	Details	Y	DDL
CREATE TABLE AS	Detai ls	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	D etails	Details
FETCH	Y	N	N
GRANT	Y	Details	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	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	Details	DDL
REVOKE ROLE	Y	Y	DDL
ROLLBACK	Y	N	N
ROLLBACK PREPARED	Y	N	N
SAVEPOINT	Y	N	N
SECURITY LABEL	Y	De tails	DDL
SELECT INTO	Detai ls	Y	DDL
SET	Y	N	N
SET CONSTRAINTS	Y	N	N
SHOW	Y	N	N
START TRANSACTION	Y	N	N
TRUNCATE TABLE	Y	De tails	Details
UNLISTEN	Y	N	N
VACUUM	Y	N	N

</ div>

ALTER SEQUENCE

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

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

ALTER TABLE

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

</ div>

ALTER TABLE禁止コマンド

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

• ADD COLUMN ... DEFAULT (non-immutable expression)-これは許可されていません 現在、異なるノードで異なるデータが生成されます。見る 推奨される回避策については、Adding a Column。

• ADD CONSTRAINT ... EXCLUDE-現時点では、除外コンストレインはサポートされていません。 非同期システムでは、除外コンストレインはあまり意味がありませmake。 リプレイできない変更につながります。

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

• ALTER COLUMN ... SET STORAGE external-列が次の場合は拒否されます テーブルのレプリカアイデンティティの列の1つ。

• RENAME-自動パーティションテーブルの名前を変更できません。

• SET SCHEMA-自動パーティションテーブルのスキーマを設定できません。

• ALTER COLUMN ... TYPE-列のタイプの変更は、 コマンドにより、テーブル全体が書き換えられます。 バイナリ強制互換ではありません。 バイナリ強制互換変更は、一方向にのみ許可されることに注意してください。例、 VARCHAR（128）からVARCHAR（256）への変更はバイナリ強制互換であるため、 許可されますが、VARCHAR（256）からVARCHAR（128）への変更はバイナリ強制互換ではありません したがって、通常は許可されていません。複製されていないALTER COLUMN ... TYPEの場合 列が新しい型に自動的にキャストできる場合は許可されます （USING句は含まれません）。例については、以下を参照してください。 テーブルの書き換えは、 大きなテーブルで拡張AccessExclusiveLockを使用するため、このようなコマンド いずれにしても、高可用性データベースでは実行不可能です。 推奨される回避策については、Changing a Column’s Typeを参照してください。

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

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

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

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

</ div>

ALTER TABLEロック

ALTER TABLEの次のバリアントは、 DDLロックのみを取得し、aDMLロックは「**」ではありません：

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

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

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

• 書き換えが不要な場合はALTER TABLE ... ALTER COLUMN ... TYPE （現在、 EDB Postgres ExtendedおよびEDB Postgres Advancedでのみ利用可能）

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

推奨される回避策については、後で参照してください。

一般的な環境およびレプリケートされない環境で可能なさまざまなタイプの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またはTEXTdatatypesに変更してもかまいません。繰り返しますが、これは基になる列タイプの単なるメタデータの更新です。

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

非テキスト型の例を与えるには、typeINTEGERを使用した上記の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つずつ繰り返して、 BDRクラスター全体にわたって列タイプの望ましい変更をもたらすことができます。これは書き換えを伴うため、アクティビティはまだ短い期間DMLロックを取得するため、クラスター全体が使用可能である必要があります。上記の仕様が整ったら、次のように非複製者アクティビティのローリングアップグレードを実行できます。

-- foreach node in BDR 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 BDR 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)である可能性があり、複製されないATCToperationを試して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バイトを超える新しいデータを同時に導入すると、複製が失敗する可能性があります。これにより、クラスター内でレプリケーションが停止します。したがって、これらのレプリケートされないローリングデータタイプのアップグレード操作を実行する際には、データベースレベルおよびアプリケーションレベルでのデータタイプの制限と特性を認識することが重要です。制御された完全に認識されたDBA環境で、このようなATCT操作を実行およびテストすることを強くお勧めします。これらのATCT操作は非対称であり、失敗するとテーブルの書き換えが長時間続く可能性がある特定の変更をバックアウトすることに注意する必要があります。

また、上記の暗黙的なキャスト可能なALTERアクティビティは、トランザクションブロックで実行できないことにノートしてください。

!!! Note * これは現在、 EDB Postgres ExtendedおよびEDB Postgres Advancedでのみ機能します。

ALTER TYPE

ユーザーはノートは複製されますが、 PostgreSQLはこれらの依存関係を記録しないため、そのデータタイプを使用するすべてのテーブルにグローバルDMLロックが適用されないことに注意してください。以下の回避策を参照してください。

</ div>

コメントオン

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

</ div>

シーケンスの作成

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

</ div>

テーブルの作成

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

</ div>

CREATE TABLE ASおよびSELECT INTO

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

theCREATE TABLE ASがPostgresのバリアントでサポートされていない場合は、代わりにを使用して同じ効果を実現できます。

CREATE TABLE mytable;
INSERT INTO mytable SELECT ... ;

説明

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

</ div>

EXPLAIN ANALYZEレプリケーション

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

</ div>

EXPLAIN ANALYZEロック

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

</ div>

付与および取り消し

通常、GRANTおよびREVOKEステートメントがサポートされますが、GRANT/REVOKE ON TABLESPACE/LARGE OBJECTは複製されません。

ロックテーブル

LOCK TABLEはローカルでのみ実行され、複製されません。トランザクションコミット後に通常のレプリケーションが発生するため、LOCK TABLEは他のノードに影響を与えません。

テーブルをグローバルにロックする場合、ユーザーはbdr.global_lock_table()を呼び出してグローバルDMLロックを明示的に要求できます。

</ div>

セキュリティラベル

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

</ div>

切り捨てレプリケーション

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

</ div>

TRUNCATEロック

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

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

ユーザーはPostgreSQLインスタンスのグローバルオブジェクト。つまり、 BDRが個々のデータベースレベルで動作している間、複数のデータベースにまたがっています。これは、ロール操作ステートメントのハンドリングに特別な配慮がニーズであることを意味します。

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

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

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

• ロールの作成

• ALTER ROLE

• ドロップロール

• 権限付与

• ユーザーの作成

• ALTER USER

• ユーザーをドロップ

• グループの作成

• ALTER GROUP

• ドロップグループ

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

• システムはbdr.role_replication = offおよび すべてのロール（ユーザおよびグループ）の変更は、外部オーケストレーションによって展開する必要があります Ansible、Puppet、Chefなどのツール、または経由で明示的に複製されたツール bdr.replicate_ddl_command(...);または

• システムは、 BDR対応データベースが1つだけになるように構成する必要があります PostgreSQLインスタンスではbdr.role_replication = onとすべてを持っています ロール管理DDLはそのデータベースで実行する必要があります。

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

ロールレプリケーションがオフになっている場合、管理者は、1つのノードでDDLが使用するロールが他のノードにも存在することを保証必要があります。そうしないと、 BDRが他のノードでロールが作成されるまでERRORで停止します。

注： BDRは、 BDR対応のPostgreSQLインスタンス内の非BDR対応データベースで実行された場合、ロール管理ステートメントをキャプチャおよびレプリケートしません。例、DB ‘bdrdb’（bdr group メンバ）および ’postgres’がある場合（bare db）、およびbdr.role_replication = onの場合、bdrdbで実行されるCREATE USERは複製されますが、postgresで実行されるCREATE USERは複製されません。

制限されDDLの回避策

BDR DDLオペレーションハンドリングの制限のいくつかは回避できます。多くの場合、オペレーションを小さな変更に分割すると、単一のステートメントとして許可されないか、過度のロックが必要な望ましい結果が生成されます。

制約の追加

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

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

• ALTER TABLE ... VALIDATE CONSTRAINT

これらのステップは、2つの異なるトランザクションで実行する必要があります。これらのステップは両方ともテーブルのDDLロックのみを取得するため、1つ以上のノードがダウンしている場合でも実行できます。しかし、制約を検証するオーダーに、 BDRはクラスター内のすべてのノードがADD CONSTRAINTコマンドを認識し、制約を検証するノードがそれらのノードにNOT VALID制約を作成する前に他のすべてのノードからreplicationchangesを適用することを保証する必要があります。そのため、新しいメカニズムでは、制約の検証中にすべてのノードを起動する必要はありませんが、すべてのノードがALTER TABLE .. ADD CONSTRAINT ... NOT VALIDコマンドを適用し、十分な進歩を遂げている必要があります。 BDRは、制約を検証する前に、consistentstateに到達するのを待ちます。

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

!!! Note * これは現在、 EDB Postgres ExtendedおよびEDB Postgres Advancedでのみ機能します。

列を追加する

volatileデフォルトの列を追加するには、これらのコマンドを個別のトランザクションで実行します。

*   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で実行可能な個別のトランザクションに分割され、aBDRグループのすべてのノードで一貫したデータが得られます。

最良の結果を得るには、一度に数万または数十万を超える行を更新しないように、更新をチャンクにバッチします。これは、埋め込みトランザクションで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;

バリデーションに失敗した場合は、失敗した行のみを更新できます。この手法は、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のレンジまたは任意のメソッドで更新することは問題ありません。また、テーブル全体を小さなテーブルにまとめて更新することもできます。

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

ALTER必要に応じて、NOT NULLおよびCHECKコンストレインを追加する列。

BEGINトランザクション、DROPは追加したトリガー、ALTER TABLEは列に必要なanyDEFAULTを追加し、DROPは古い列、andb_tran_6、COMMITの順に追加します。

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

他のタイプの変更

ALTER TYPEステートメントは複製されますが、影響を受けるテーブルはロックされません。

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

例、

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

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

DDLのように動作するBDRFunctions

次のBDR管理機能はDDLのように機能します。これは、DDLreplicationがアクティブで、 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