System functions¶

主にSQLから呼び出す関数を使用して、PGD管理を実行します。 PGDのすべての関数は、 bdr スキーマで公開されています。スキーマは、 search_path にbdr を置く代わりに、これらの関数への呼び出しを修飾します。

バージョン情報機能¶

bdr.bdr_version¶

この関数は、現在使用されているBDR拡張機能のバージョンのテキスト表現を取得します。

bdr.bdr_version_num¶

この関数は、現在使用されているBDR拡張機能のバージョン番号を取得します。バージョン番号は単調に増加するため、この値を小なりと大なりの比較に使用できます。

次の式は、メジャーバージョン、マイナーバージョン、およびパッチリリースで構成されるバージョン番号を1つの数値に返します。

MAJOR_VERSION  *10000+MINOR_VERSION*  100 + PATCH_RELEASE

システム情報機能¶

bdr.get_relation_stats¶

リレーション情報を返します。

bdr.get_subscription_stats¶

現在のサブスクリプション統計を返します。

システムと進捗情報パラメーター¶

PGDは、 psql のSHOW を使用して、またはクライアントアプリケーションからPQparameterStatus （または同等の）を使用してクエリできるいくつかのパラメーターを公開します。

bdr.local_node_id¶

セッションを初期化すると、これはクライアントが接続しているノードIDに設定されます。これにより、アプリケーションは、透過プロキシの背後であっても、接続されているノードを把握できます。

接続プールとプロキシでも使用されます。

bdr.last_committed_lsn¶

非同期トランザクションのCOMMIT ごとに、このパラメーターは更新され、起点ノードのコミットレコードの最後をポイントします。それをbdr.wait_for_apply_queue と組み合わせると、アプリケーションはマルチプルのノード間で因果読み取りを実行できます。つまり、トランザクションがリモートで可視になるまで待機できます。

transaction_id¶

PostgresがトランザクションIDを割り当てるとすぐに、 CAMOが有効になっている場合、このパラメーターが更新され、割り当てられたトランザクションIDが表示されます。

bdr.is_node_connected¶

概要¶

bdr.is_node_connected(node_name name)

特定のピアのウォルセンダーがこのノードでアクティブかどうかを確認して、ブール値を返します。

bdr.is_node_ready¶

概要¶

bdr.is_node_ready(node_name name, span interval DEFAULT NULL)

ラグが指定されたスパンよりも低いかどうか、またはTO ASYNC のtimeout よりも低いかどうかを確認して、ブール値を返します。

コンセンサス機能¶

bdr.consensus_disable¶

サーバーが再起動するまで、またはbdr.consensus_enable を使用して再度有効になるまで（どちらか早い方）、ローカルノードのコンセンサスワーカーを無効にします。

警告

コンセンサスを無効にすると、PGDの一部の機能が無効になり、長期間無効のままにした場合、 EDB Postgres分散クラスターの可用性に影響します。この機能は、テクニカルサポートと協力する場合にのみ使用してください。

bdr.consensus_enable¶

ローカルノードで無効になっているコンセンサスワーカーを再度有効にします。

bdr.consensus_proto_version¶

ローカルノードで現在使用されているコンセンサスプロトコルバージョンを返します。

PGDグループの再構成内部メカニズムによって必要とされます。

bdr.consensus_snapshot_export¶

概要¶

bdr.consensus_snapshot_export(version integer DEFAULT NULL)

ローカルノードの現在コミットおよび適用された状態から新しいPGDコンセンサススナップショットを生成し、byteaとして返します。

デフォルトでは、サポートされている最も高いRaftバージョンのスナップショットがエクスポートされます。ただし、明示的なversion 番号を渡すことにより、それをオーバーライドできます。

エクスポートするノードは現在のRaftリーダーである必要はなく、リーダーの最新の状態で完全に最新である必要もありません。ただし、 bdr.consensus_snapshot_import() はそのようなスナップショットを受け入れない場合があります。

新しいスナップショットは、ローカルノードのbdr.local_consensus_snapshot テーブルに自動的に保存されません。呼び出し元にのみ返されます。

生成されたスナップショットは、エクスポートノードのRaftログ位置の背後にある同じPGDノードグループ内の他のノードのbdr.consensus_snapshot_import() に渡される可能性があります。

この機能を動作させるには、ローカルPGDコンセンサスワーカーを無効にする必要があります。典型的な使用法は次のとおりです。

SELECT bdr.bdr_consensus_disable();
\copy (SELECT * FROM bdr.consensus_snapshot_export()) TO my_node_consensus_snapshot.data
SELECT bdr.bdr_consensus_enable();

PGDコンセンサスワーカーが無効になっている間：

ノードでのDDLロックの試行が失敗するか、タイムアウトします。
gallocシーケンスは新しい値を取得しません。
EagerおよびCAMOトランザクションは一時停止またはエラー。
分散コンセンサスシステムを必要とする他の機能が中断されます。必要なダウンタイムは一般的に非常に短時間です。

ユースケースによっては、 bdr.local_consensus_snapshot テーブルのsnapshot フィールドから既に存在するスナップショットを抽出し、代わりに使用する方が実用的な場合があります。そうすることで、コンセンサスワーカーを停止する必要はありません。

bdr.consensus_snapshot_import¶

概要¶

bdr.consensus_snapshot_import(IN snapshot bytea)

通常は同じPGDノードグループ内の別のノードから、 bdr.consensus_snapshot_export() によってエクスポートされたコンセンサススナップショットをインポートします。

別のノード上のbdr.local_consensus_snapshot テーブルのsnapshot フィールドから直接抽出したスナップショットを使用することもできます。

この関数は、破損またはユーザーエラーが発生した場合に、PGDノードのカタログ状態を既知の良好な状態にリセットするのに役立ちます。

スナップショットが生成されたときにインポートノードのapply_index がスナップショットのエクスポートノードのcommit_index 以下である場合、スナップショットをインポートできます。（bdr.get_raft_status() を参照。）ログがすでにはるか先にあるためにスナップショットを受け入れることができないノードは、エラーを発生させ、変更を行いません。スナップショットがインポートされると、ノードは現在のリーダーから残りの変更をフェッチするため、インポートされたスナップショットは完全に最新である必要はありません。

この機能を動作させるには、インポートノードでPGDコンセンサスワーカーを無効にする必要があります。詳細については、 bdr.consensus_snapshot_export() のノートを参照してください。

次を実行することにより、この関数を使用して、ローカルノードに新しいRaftスナップショットを生成させることができます。

SELECT bdr.consensus_snapshot_import(bdr.consensus_snapshot_export());

このアプローチは、現在適用されているログ位置までRaftログを切り捨てる場合もあります。

bdr.consensus_snapshot_verify¶

概要¶

bdr.consensus_snapshot_verify(IN snapshot bytea)

bdr.consensus_snapshot_export() によってエクスポートされた特定のコンセンサススナップショットを確認します。スナップショットヘッダーには、それが生成されたバージョンが含まれており、ノードは同じバージョンに対して検証しようとします。

スナップショットは、同じノードまたはクラスター内の他のノードでエクスポートされた可能性があります。スナップショットを検証するノードが、エクスポートされたスナップショットのバージョンをサポートしていない場合、エラーが発生します。

bdr.get_consensus_status¶

現在のコンセンサス（Raft）ワーカーに関するステータス情報を返します。

bdr.get_raft_status¶

現在のコンセンサス（Raft）ワーカーに関するステータス情報を返します。 bdr.get_consensus_status のエイリアス。

bdr.raft_leadership_transfer¶

概要¶

bdr.raft_leadership_transfer(IN node_name text, IN wait_for_completion boolean)

node_name で識別されるノードがRaftリーダーになることを要求します。要求は、任意のPGDノードから開始でき、現在のリーダーに内部的に転送され、指定されたノードにリーダーシップを転送します。指定されたノードは、完全な投票権を持つACTIVE PGDノードである必要があります。

wait_for_completion がfalseの場合、リクエストはベストエフォートベースで処理されます。 bdr.raft_election_timeout 期間中にノードがリーダーになれない場合、他の能力のあるノードが再びリーダーになります。また、リーダーシップは、ラフトプロトコルごとに期間にわたって変わる可能性があります。 true の戻り結果は、要求が正常に送信されたことのみを示します。

wait_for_completion がtrue である場合、関数は、指定されたノードが新しいリーダーになるまで待機し、要求されたノードがRaftリーダーにならない場合（ネットワークの問題などにより）、おそらく無限に待機します。したがって、無限ループを防ぐために、常にwait_for_completion でstatement_timeout を設定することをお勧めします。

ユーティリティ関数¶

bdr.wait_slot_confirm_lsn¶

このセッションの最後の書き込みが1つまたはすべてのノードで再生されるまで待機できます。

スロットが特定のLSNを通過するまで待機します。位置が指定されていない場合、ローカルノードで現在の書き込み位置が使用されます。

スロット名が渡されない場合、すべてのPGDスロットがLSNを渡すまで待機します。

この関数は、他のノードからの変更について1000ミリ秒ごとにポーリングします。

スロットが同時にドロップされた場合、そのスロットの待機は終了します。ノードが現在ダウンしており、スロットを更新していない場合、待機は継続されます。その場合、 statement_timeout をより早く完了するように設定することをお勧めします。

概要¶

bdr.wait_slot_confirm_lsn(slot_name text DEFAULT NULL, target_lsn pg_lsn DEFAULT NULL)

パラメーター¶

slot_name —レプリケーションスロットの名前、または、 NULLの場合、すべてのPGDスロット（のみ）。
target_lsn —待機するLSN。または、 NULLの場合、ローカルノード上の現在の書き込みLSNを使用します。

bdr.wait_for_apply_queue¶

関数bdr.wait_for_apply_queue を使用すると、PGDノードは、特定のPGDノードから発信される特定のトランザクションのローカルアプリケーションを待機できます。そのピアノードからのすべてのトランザクションがローカルに適用された後にのみ戻ります。アプリケーションまたはプロキシは、この機能を使用して、古い読み取りを防ぐことができます。

便宜上、PGDはCAMOおよびCAMOパートナーノードにこの機能のバリアントを提供します。: bdr.wait_for_camo_partner_queue を参照してください。

特定のLSNが指定されている場合、それはピアが待機する復旧ストリームのポイントです。これを、以前の接続または同時接続でそのピアノードから取得したbdr.last_committed_lsn で使用できます。

指定されたtarget_lsn がNULLの場合、この関数はローカル受信バッファーをチェックし、指定されたピアノードから受信した最後のトランザクションのLSNを使用し、既に受信したすべてのトランザクションが適用されるのを効果的に待機します。これは、ピアノードに障害が発生し、どのトランザクションが送信されたかがわからない場合に特に役立ちます。この場合、送信側でまだ転送中またはバッファリングされているトランザクションは待機されません。

概要¶

bdr.wait_for_apply_queue(peer_node_name TEXT, target_lsn pg_lsn)

パラメーター¶

peer_node_name —着信トランザクションがキューに入れられて待機するピアノードの名前。 NULLの場合、すべてのピアノードの適用キューが消費されるのを待ちます。
target_lsn —待機するピアノードからのレプリケーションストリーム内のLSN。通常、ピアノードからbdr.last_committed_lsn を介して学習されます。

bdr.get_node_sub_receive_lsn¶

サブスクライバーでこの関数を使用して、特定のオリジンから受信した最後のLSNを取得できます。適用するトランザクションに関連するLSNインクリメントのみを考慮に入れるように、フィルター処理しないか、フィルター処理することができます。

この関数の出力と bdr.get_node_sub_apply_lsn() の出力の差は、対応する適用キューのサイズを測定します。

概要¶

bdr.get_node_sub_receive_lsn(node_name name, committed bool default true)

パラメーター¶

node_name — LSNを取得するレプリケーションストリームのソースであるノードの名前。
committed —;デフォルト（true）では、この関数は最後のLSN全体ではなく、受信したトランザクションのコミットのみを考慮します。これには、サブスクライバーノードに影響を与えないアクションが含まれます。

bdr.get_node_sub_apply_lsn¶

サブスクライバーでこの関数を使用して、特定のオリジンから受信および適用された最後のLSNを取得できます。

概要¶

bdr.get_node_sub_apply_lsn(node_name name)

パラメーター¶

node_name — LSNが取得されるレプリケーションストリームのソースであるノードの名前。

bdr.run_on_all_nodes¶

すべてのノードでクエリを実行する関数。

警告

この関数は、ノードのDSNで指定されたノード間接続に使用されるユーザーの特権で、リモートノードで任意のクエリを実行します。このファンクションに権限を付与するときは注意してください。

概要¶

bdr.run_on_all_nodes(query text)

パラメーター¶

query —実行する任意のクエリ。

注意事項¶

この関数は、他のノードに接続してクエリを実行し、それぞれからの結果をJSON形式で返します。 JSON配列としてエンコードされた、各ノードから複数の行が返される場合があります。ノードがダウンしているために接続できないなどのエラーは、応答フィールドに表示されます。明示的な statement_timeout または他の実行時パラメーターは設定されていないため、デフォルトが使用されます。

この関数は、通常のレプリケーションを行いません。既知のすべてのノードへの直接クライアント接続を使用します。デフォルトでは、コマンドはすでにクラスター内のすべてのノードに送信されているため、接続はbdr.ddl_replication = off で作成されます。

レプリケーションを壊し、ノード間の矛盾を引き起こす危険があるため、この機能を使用するときは注意してください。透過的なDDLレプリケーションまたは bdr.replicate_ddl_command() を使用してDDLをレプリケートします。 DDLは、将来のリリースでブロックされる可能性があります。

例¶

次のクエリのように、監視でこの関数を使用すると便利です。

SELECT bdr.run_on_all_nodes($$
    SELECT local_slot_name, origin_name, target_name, replay_lag_size
      FROM bdr.node_slots
     WHERE origin_name IS NOT NULL
$$);

このクエリは、2ノードクラスターで次のようなものを返します。

[
    {
        "dsn": "host=node1 port=5432 dbname=bdrdb user=postgres ",
        "node_id": "2232128708",
        "response": {
            "command_status": "SELECT 1",
            "command_tuples": [
                {
                    "origin_name": "node1",
                    "target_name": "node2",
                    "local_slot_name": "bdr_bdrdb_bdrgroup_node2",
                    "replay_lag_size": "0 bytes"
                }
            ]
        },
        "node_name": "node1"
    },
    {
        "dsn": "host=node2 port=5432 dbname=bdrdb user=postgres ",
        "node_id": "2058684375",
        "response": {
            "command_status": "SELECT 1",
            "command_tuples": [
                {
                    "origin_name": "node2",
                    "target_name": "node1",
                    "local_slot_name": "bdr_bdrdb_bdrgroup_node1",
                    "replay_lag_size": "0 bytes"
                }
            ]
        },
        "node_name": "node2"
    }
]

bdr.run_on_nodes¶

指定されたノードのリストでクエリを実行する関数。

警告

この関数は、ノードのDSNで指定されたノード間接続に使用されるユーザーの特権で、リモートノードで任意のクエリを実行します。このファンクションに権限を付与するときは注意してください。

概要¶

bdr.run_on_nodes(node_names text[], query text)

パラメーター¶

node_names —クエリが実行されるノード名のText ARRAY。
query —実行する任意のクエリ。

注意事項¶

この関数は、他のノードに接続してクエリを実行し、それぞれからの結果をJSON形式で返します。 JSON配列としてエンコードされた、各ノードから複数の行を返すことができます。ノードがダウンしているために接続できないなどのエラーは、応答フィールドに表示されます。明示的な statement_timeout または他の実行時パラメーターは設定されていないため、デフォルトが使用されます。

この関数は、通常のレプリケーションを行いません。既知のすべてのノードへの直接クライアント接続を使用します。デフォルトでは、コマンドはすでにクラスター内のすべてのノードに送信されているため、接続はbdr.ddl_replication = off で作成されます。

レプリケーションを壊し、ノード間の矛盾を引き起こす危険があるため、この機能を使用するときは注意してください。透過的なDDLレプリケーションまたは bdr.replicate_ddl_command() を使用してDDLをレプリケートします。 DDLは、将来のリリースでブロックされる可能性があります。

bdr.run_on_group¶

ノードのグループでクエリを実行する関数。

警告

この関数は、ノードのDSNで指定されたノード間接続に使用されるユーザーの特権で、リモートノードで任意のクエリを実行します。このファンクションに権限を付与するときは注意してください。

概要¶

bdr.run_on_group(node_group_name text, query text)

パラメーター¶

node_group_name —クエリが実行されるノードグループの名前。
query —実行する任意のクエリ。

注意事項¶

この関数は、他のノードに接続してクエリを実行し、それぞれからの結果をJSON形式で返します。 JSON配列としてエンコードされた、各ノードから複数の行を返すことができます。ノードがダウンしているために接続できないなどのエラーは、応答フィールドに表示されます。明示的な statement_timeout または他の実行時パラメーターは設定されていないため、デフォルトが使用されます。

この関数は、通常のレプリケーションを行いません。既知のすべてのノードへの直接クライアント接続を使用します。デフォルトでは、コマンドはすでにクラスター内のすべてのノードに送信されているため、接続はbdr.ddl_replication = off で作成されます。

レプリケーションを壊し、ノード間の矛盾を引き起こす危険があるため、この機能を使用するときは注意してください。透過的なDDLレプリケーションまたは bdr.replicate_ddl_command() を使用してDDLをレプリケートします。 DDLは、将来のリリースでブロックされる可能性があります。

bdr.global_lock_table¶

このファンクションは、指定されたテーブルのグローバルDMLロックを取得します。グローバルDMLロックの詳細は、: DDLロックの詳細を参照してください。

概要¶

bdr.global_lock_table(relation regclass)

パラメーター¶

relation —ロックするリレーションの名前またはoid。

注意事項¶

このファンクションは、 ddl_locking 設定とは無関係にグローバルDMLロックを取得します。

bdr.global_lock_table ファンクションには、 bdr.backwards_compatibility が30618以下に設定されていない限り、ロックされたrelation に対するUPDATE 、DELETE 、またはTRUNCATE 特権が必要です。

bdr.wait_for_xid_progress¶

この関数を使用して、特定のノード（ノードIDで識別）で発生した特定のトランザクション（XIDで識別）がクラスターで十分に進行するのを待つことができます。進行状況は、ノードに適用されているトランザクションとして定義され、このノードは、トランザクションが適用される前に行われた他のすべてのレプリケーション変更を確認しています。

概要¶

bdr.wait_for_xid_progress(origin_node_id oid, origin_topxid int4, allnodes boolean DEFAULT true)

パラメーター¶

origin_node_id —トランザクションが発生したノードのノードID。
origin_topxid —トランザクションのXID。
allnodes — true の場合、すべてのノードでトランザクションが進行するのを待ちます。それ以外の場合は、現在のノードのみを待ちます。

注意事項¶

DDLコマンドをレプリケートしたトランザクションのみが現在追跡されているため、この関数を使用できます。間違ったorigin_node_id またはorigin_topxid が指定された場合、関数は永久に、またはstatement_timeout が発生するまで待機する場合があります。

bdr.local_group_slot_name¶

ローカルノードのグループスロットの名前を返します。

例¶

bdrdb=# SELECT bdr.local_group_slot_name();
 local_group_slot_name
- ----------------------
 bdr_bdrdb_bdrgroup

bdr.node_group_type¶

指定されたノードグループのタイプを返します。戻り値は、ノードグループの作成時にbdr.create_node_group() に渡されたものと同じですが、グループの作成時にnode_group_type がNULLとして渡された場合、 normal が返されます。

例¶

bdrdb=# SELECT bdr.node_group_type(bdrgroup);
 node_group_type
- ----------------
 normal

bdr.alter_node_kind¶

PGD5は、タスクマネージャーリーダーノードの概念を導入しました。ノードはPGDによって自動的に選択されますが、アップグレードされたクラスターの場合、クラスター内のすべてのノードに対してnode_kind を適切に設定することが重要です。ユーザーは、最新のPGDバージョンにアップグレードした後、各ノードのbdr.alter_node_kind() SQL関数を呼び出して、これを手動で行う必要があります。

概要¶

bdr.alter_node_kind(node_name text,
                    node_kind text);

パラメーター¶

node_name —種類を変更するノードの名前。
node_kind —ノードの種類。 data 、standby 、witness 、またはsubscriber-only のいずれか。

bdr.alter_subscription_skip_changes_upto¶

論理レプリケーションはバージョン間でレプリケートでき、ロールのようなグローバルな変更をレプリケートせず、選択的にレプリケートできるため、論理レプリケーション適用プロセスでエラーが発生し、変更の適用が停止する場合があります。

可能な限り、ターゲット側に変更を加えて、このような問題を修正します。 CREATE レプリケーションをブロックしている欠落しているテーブル、 CREATE 必要なロール、 GRANT 必要な権限など。ただし、場合によっては問題をその方法で修正できず、トランザクションを完全にスキップする必要がある場合があります。変更は、トランザクション全体としてスキップされます。スキップする場所を決定するには、次の例のようにログ出力を使用してコミットLSNを見つけるか、論理デコード関数で変更ストリームをピークします。

トランザクションが1つだけ変更を加えない限り、多くの場合、ターゲット側にトランザクションの効果を手動で適用する必要があるため、次の例に示すように、可能な限り問題のあるトランザクションを保存することが重要です。

pg_catalog.pg_logical_slot_get_binary_changes を使用して目的のLSNにスキップすることにより、bdr.alter_subscription_skip_changes_upto なしで変更をスキップすることが可能であるため、これは便利な関数です。論理デコードでいくつかの種類のエラーをバイパスする可能性がありますが、より高速にスキップします。

この機能は、無効になっているサブスクリプションでのみ機能します。

通常の手順は次のとおりです。

1.問題のサブスクリプションと問題のコミットのLSNを特定します。

1.サブスクリプションを無効にします。

1.可能であれば、ソースノードでpg_catalog.pg_logical_slot_peek_changes を使用してトランザクションのコピーを保存します。

1.ターゲットノード上のbdr.alter_subscription_skip_changes_upto 。

1.必要に応じて、修復した変更または同等の変更をターゲットに手動で適用します。

1.サブスクリプションを再度有効にします。

警告

この関数を使用すると、問題を悪化させるのは簡単です。それが唯一の選択肢であると確信できる場合を除き、何もしないでください。

概要¶

bdr.alter_subscription_skip_changes_upto(
  subname text,
  skip_upto_and_including pg_lsn
);

例¶

トランザクションの適用がエラーで失敗し、ターゲット側での変更などの影響の少ない修正ではこの問題を解決できないと判断しました。あなたは、トランザクションをスキップする必要があると判断します。

次の例のように、エラーログで、スキップするコミットレコードLSNを見つけます。

ERROR:  XX000: CONFLICT: target_table_missing; resolver skip_if_recently_dropped returned an error: table does not exist
CONTEXT:  during apply of INSERT from remote relation public.break_me in xact with commit-end lsn 0/300AC18 xid 131315
committs 2021-02-02 15:11:03.913792+01 (action #2) (effective sess origin id=2 lsn=0/300AC18)
while consuming I message from receiver for subscription bdr_regression_bdrgroup_node1_node2 (id=2667578509)
on node node2 (id=3367056606) from upstream node node1 (id=1148549230, reporiginid=2)

ログのこの部分には、必要な情報があります。the_target_lsn： 0/300AC18 the_subscription： bdr_regression_bdrgroup_node1_node2

次に、サブスクリプションを無効にして、適用ワーカーがレプリケーションスロットに接続しようとしないようにします。

SELECT bdr.alter_subscription_disable(the_subscription);

トランザクションの一部だけをスキップすることはできません。それはすべてか無かです。そのため、サブスクリプションのスロット名を使用して、最初にプロバイダー側でコピーして、そのレコードを保存することを強くお勧めします。

\copy (SELECT * FROM pg_catalog.pg_logical_slot_peek_changes(the_slot_name,
    the_target_lsn, NULL, min_proto_version, 1, max_proto_version, 1,
    startup_params_format, 1, proto_format, json))
 TO transaction_to_drop.csv WITH (FORMAT csv);

この例は、読みやすくするために複数行に分割されていますが、1行で発行してください。 \copy は複数行のコマンドをサポートしていません。

peek をget に変更することで変更をスキップできますが、 bdr....skip_changes_upto はより高速にスキップし、すべてのデータのデコードと出力を回避します。

SELECT bdr.alter_subscription_skip_changes_upto(subscription_name,
    the_target_lsn);

ダンプされたトランザクションの内容をガイドとして使用して、同じ変更（またはそれらの修復バージョン）をターゲットノードに手動で適用できます。

最後に、サブスクリプションを再度有効にします。

SELECT bdr.alter_subscription_enable(the_subscription);

グローバルアドバイザリーロック¶

PGDは、グローバル勧告ロックをサポートしています。これらのロックは、PGDでサポートされる勧告ロックがグローバルであることを除いて、PostgreSQLで利用可能な勧告ロックに似ています。これらは、 DDLロックと同様のセマンティクスに従います。したがって、アドバイザリーロックは多数決コンセンサスによって取得され、すべてのノードの過半数が連携できる限り、1つ以上のノードがダウンまたは遅れている場合でも使用できます。

現在、 EXCLUSIVE ロックのみがサポートされています。したがって、別のノードまたは同じノード上の別のバックエンドがオブジェクトの勧告ロックをすでに取得している場合、他のノードまたはバックエンドはロックが解放されるまで待つ必要があります。

アドバイザリーロックは本質的にトランザクションです。したがって、トランザクションの終了前に明示的に解放されない限り、トランザクションの終了時にロックは自動的に解放されます。この場合、リリースされ次第利用可能になります。セッションレベルのアドバイザリロックは現在サポートされていません。

グローバル勧告ロックはリエントラントです。したがって、同じリソースが3回ロックされている場合、他のセッションで使用できるように解放するには、3回ロック解除する必要があります。

bdr.global_advisory_lock¶

このファンクションは、指定されたオブジェクトのEXCLUSIVEロックを取得します。ロックが利用できない場合、ロックが利用可能になるか、 bdr.global_lock_timeout に到達するまで待機します。

概要¶

bdr.global_advisory_lock(key bigint)

パラメーター¶

key —アドバイザリロックが取得されるオブジェクト。

概要¶

bdr.global_advisory_lock(key1 integer, key2 integer)

パラメーター¶

key1 —複合キーの最初の部分。
key2 —複合キーの2番目の部分。

bdr.global_advisory_unlock¶

この関数は、アプリケーション定義のソースで以前に取得したロックを解放します。ロックは、アプリケーションが同じトランザクションで取得している必要があります。それ以外の場合、エラーが発生します。

概要¶

bdr.global_advisory_unlock(key bigint)

パラメーター¶

key —アドバイザリロックが取得されるオブジェクト。

概要¶

bdr.global_advisory_unlock(key1 integer, key2 integer)

パラメーター¶

key1 —複合キーの最初の部分。
key2 —複合キーの2番目の部分。

監視機能¶

bdr.monitor_group_versions¶

クラスター全体のバージョンチェックを提供するために、この関数はビューbdr.group_version_details から返されるPGDバージョン情報を使用します。

概要¶

bdr.monitor_group_versions()

注意事項¶

Monitoring で説明されているように、この関数は、フィールド status

およびmessage を持つレコードを返します。

この関数はbdr.run_on_all_nodes() を呼び出します。

bdr.monitor_group_raft¶

クラスター全体のRaftチェックを提供するために、この関数はビューbdr.group_raft_details から返されたPGD Raft情報を使用します。

概要¶

bdr.monitor_group_raft()

パラメーター¶

node_group_name —チェックするノードグループ名。

注意事項¶

Monitoring で説明されているように、この関数は、フィールド status

およびmessage を持つレコードを返します。

この関数はbdr.run_on_all_nodes() を呼び出します。

bdr.monitor_local_replslots¶

この関数は、ビューpg_replication_slots （スロットアクティブまたは非アクティブ）から返されたレプリケーションスロットステータス情報を使用して、PGDグループスロットを除くすべてのレプリケーションスロットを考慮したローカルチェックを提供します。

概要¶

bdr.monitor_local_replslots()

注意事項¶

レプリケーションスロットのモニタリングで説明されているように、この関数は、フィールド status

およびmessage を持つレコードを返します。

bdr.wal_sender_stats¶

デコードワーカーが有効になっている場合、この関数は、デコーダースロットと各WAL送信者によって読み取られている現在のLCR（論理変更レコード）セグメントファイルに関する情報を表示します。

概要¶

bdr.wal_sender_stats()

出力列¶

pid — WAL送信者のPID（ pg_stat_replication のpid 列に対応）。
is_using_lcr — WAL送信者がLCRファイルを送信しているかどうか。 is_using_lcr がFALSE の場合、次の列はNULL です。
decoder_slot_name —デコーダー複製スロットの名前。
lcr_file_name —現在のLCRファイルの名前。

bdr.get_decoding_worker_stat¶

デコードワーカーが有効になっている場合、この関数は、現在のデータベースに関連付けられているデコードワーカーの状態に関する情報を表示します。これはまた、

pg_replication_slots を介して利用可能なものよりも、デコードワーカーの進行状況に関するより詳細な情報を提供します。

概要¶

bdr.get_decoding_worker_stat()

出力列¶

pid —デコードワーカーのPID（ pg_replication_slots のactive_pid 列に対応）。
decoded_upto_lsn —デコードワーカーがトランザクションログを読み取るまでのLSN。
waiting —デコードワーカーが新しいWALを待っているかどうか。
waiting_for_lsn —次に予想されるWALのLSN。

注意事項¶

詳細については、 LCRを使用したWAL送信者のモニタリングを参照してください。

bdr.lag_control¶

Lag Control が有効になっている場合、この機能は、コミット遅延と、ローカルノードと現在のデータベースに構成されているラグメジャーに準拠するノードの数に関する情報を表示します。

概要¶

bdr.lag_control()

出力列¶

commit_delay —現在のランタイムコミット遅延（ミリ秒未満）。
commit_delay_maximum —構成された最大コミット遅延（ミリ秒未満）。
commit_delay_adjustment —サンプル間隔中に可能なランタイムコミット遅延への変更（ミリ秒未満）。
conforming_nodes —ラグメジャーに準拠するノードの現在のランタイム数。
conforming_nodes_minimum —ラグメジャーに準拠するために必要なノードの構成された最小数。それ以下ではコミット遅延調整が適用されます。
lag_bytes_threshold —コミット遅延が適用されるラグサイズ（キロバイト）。
lag_bytes_maximum —構成された最大ラグサイズ（キロバイト単位）。
lag_time_threshold —ミリ秒単位のコミット遅延が適用されるラグタイム。
lag_time_maximum —構成された最大ラグタイム（ミリ秒）。
sample_interval —ミリ秒単位のラグサンプルと可能なコミット遅延調整間の構成された最小時間。