Ctrl+K

System functions

目次

System functions#

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

バージョン情報ファンクション#

bdr.bdr_version#

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

bdr.bdr_version_num#

このファンクションは、現在使用されているBDR拡張機能のバージョン番号を取得します。バージョン番号は単調増加であるため、この値をより小さいおよびより大きい比較に使用できます。

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

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#

CAMOが有効になっている場合、PostgresがトランザクションIDを割り当てるとすぐに、このパラメーターが更新されて、割り当てられたばかりのトランザクション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シーケンスは新しい値を取得しません。

  • EageおよびCAMOトランザクションの一時停止またはエラー。

  • 分散コンセンサスシステムを必要とする他の機能が中断されます。必要なダウンタイムは、一般に非常に短時間です。

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

bdr.consensus_snapshot_import#

概要#

bdr.consensus_snapshot_import(snapshot bytea)

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

別のノード上の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(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(node_name text,
                             wait_for_completion boolean,
                             node_group_name text DEFAULT NULL)

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

wait_for_completion がfalseの場合、要求はベストエフォートベースで提供されます。ノードがbdr.raft_election_timeout 期間にリーダーになることができない場合、他の有効なノードが再びリーダーになります。また、リーダーシップはRaftプロトコルごとに時間の経過とともに変更される場合があります。 true の戻り結果は、要求が正常に送信されたことのみを示します。

wait_for_completion がtrue の場合、ファンクションは指定されたノードが新しいリーダーになるまで待機し、要求されたノードがRaftリーダーになれなかった場合たとえば、ネットワークの問題のため、無限に待機します。したがって、無限ループを防ぐために、常にstatement_timeout とwait_for_completion を設定することをお勧めします。

node_group_name はオプショナルであり、リーダーシップの移転が発生するノードグループの名前を指定するために使用できます。指定しない場合、デフォルトのNULLがクラスター内のトップレベルのグループとして解釈されます。 node_group_name が指定されている場合、ファンクションは指定されたノードグループ内のリーダーシップのみを転送します。

ユーティリティファンクション#

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.replicate_ddl_command#

ノードのグループにDDLコマンドを複製する機能。

概要#

bdr.replicate_ddl_command(ddlcommand text,
                          replication_sets text[],
                          ddl_locking text,
                          execute_locally bool)

パラメーター#

  • ddlcommand —実行するDDLコマンド。

  • replication_sets — ddlcommand を適用するレプリケーションセット名の配列。 NULLの場合、またはファンクションがddlcommand のみが渡される場合、これはアクティブなPGDグループのデフォルトのレプリケーションセットに設定されます。

  • ddl_locking —レプリケート中に bdr.ddl_locking 値を設定する文字列。 require_ddl_commandを実行しているローカルシステム上のbdr.ddl_locking のGUC値のデフォルト。

  • execute_locally — DDLコマンドをローカルに実行するかどうかを決定するブール値。デフォルトtrue。

注#

このファンクションの唯一の必須パラメーターはddlcommand です。

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 —クエリーが実行されるノード名のテキストARRAY

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

注#

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

このファンクションは、通常のレプリケーションを経由しません。すべての既知のノードへの直接クライアント接続を使用します。デフォルトでは、接続はbdr.ddl_replication = off で作成され、同じレプリケートされたDDLコマンドが複数のノードに送信された場合のレプリケーションの問題を回避します。

レプリケーションが中断され、ノード間で不一致が発生する危険があるため、この機能を使用する場合は注意してください。グローバルスキーマ変更の場合、透過的DDLレプリケーションまたは bdr.replicate_ddl_command() を使用して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コマンドが複数のノードに送信された場合のレプリケーションの問題を回避します。

レプリケーションが中断され、グループ内のノード間で不一致が発生する危険があるため、この機能を使用する場合は注意してください。グローバルスキーマ変更の場合、透過的DDLレプリケーションまたは bdr.replicate_ddl_command() を使用してDDLをレプリケートします。

bdr.global_lock_table#

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

DDL locking details を参照してください。

概要#

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として渡された場合、 global が返されます。

例#

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

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を特定します。

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

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

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

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

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

警告

このファンクションを使用すると、問題を悪化させるのは簡単です。それが唯一のオプションであると確信できない限り、何もしないでください。

概要#

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

この例は、読みやすいように複数行に分割されていますが、単一行で発行します。 \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()

注#

競合のモニタリング で説明しているように、このファンクションは、フィールド

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 —確認するノードグループ名。

注#

競合のモニタリング で説明しているように、このファンクションは、フィールド

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#

遅延制御 が有効になっている場合、このファンクションは、ローカルノードと現在のデータベースの構成された遅延測定に準拠するノードの数とコミット遅延に関する情報を表示します。

概要#

bdr.lag_control()

出力列#

  • commit_scope_id —コミットスコープのOID bdr.commit_scopes を参照してください。

  • sessions —遅延制御エントリを参照するセッション数

  • current_commit_delay —現在のランタイムコミット遅延ミリ秒単位。

  • maximum_commit_delay —構成された最大コミット遅延ミリ秒単位。

  • commit_delay_adjust —サンプルインターバル中に発生する可能性のあるランタイムコミット遅延の変更ミリ秒単位。

  • curent_conforming_nodes —遅延対策に適合しているノードの現在の実行時数。

  • minimum_conforming_nodes —遅延対策に適合するために必要なノードの構成済みの最小数。これを下回ると、コミット遅延調整が適用されます。

  • lag_bytes_threshold —コミット遅延が適用される遅延サイズキロバイト単位。

  • maximum_lag_bytes —キロバイト単位の構成された最大遅延サイズ。

  • lag_time_threshold —ミリ秒単位のコミット遅延が適用される遅延時間。

  • maximum_lag_time —設定された最大遅延時間ミリ秒単位。

  • sample_interval —ミリ秒単位の遅延サンプル間の構成された最小時間と考えられるコミット遅延調整。

CAMOファンクション#

CAMOでは、クライアントがトランザクションの進行状況を追跡することにより、トランザクションのコミットに積極的に参加する必要があります。ここにリストされているファンクションはそのために使用され、

CAMOまたはコミット・アット・モスト・ワンス セクションで説明されています。

bdr.is_camo_partner_connected#

ペアモードで構成されたCAMOパートナーノードの接続ステータスを確認できます。現在、Eagerレプリケーションで使用されるCAMOに相当するものはありません。

概要#

bdr.is_camo_partner_connected()

戻り値#

CAMOパートナーが現在ローカルノード上のWAL送信プロセスに接続しているため、トランザクションデータを受信し、確認を送り返すことができるかどうかを示すブール値。

bdr.is_camo_partner_ready#

ペアモードで構成されたCAMOパートナーノードの準備状況を確認できます。その下で、これはローカルモードへの、またはローカルモードからのスイッチをトリガーします。

概要#

bdr.is_camo_partner_ready()

戻り値#

CAMOパートナーがタイムリーに、つまりTO ASYNC のtimeout の有効期限が切れる前に、ローカルノードから発生したトランザクションを確認することが合理的に期待できるかどうかを示すブール値。

注釈

このファンクションは、過去または現在の状態を照会します。正の戻り値は、 CAMOパートナーが将来のトランザクションを確認できるかどうかを示しません。

bdr.get_configured_camo_partner#

この機能は、ローカルノードのCAMOパートナーペアモードで構成を表示します。

概要#

bdr.get_configured_camo_partner()

bdr.wait_for_camo_partner_queue#

このファンクションは、 CAMOパートナーノードを照会することがデフォルトのbdr.wait_for_apply_queue のラッパーです。ローカルノードがCAMOペアの一部でない場合、エラーを返します。

概要#

bdr.wait_for_camo_partner_queue()

bdr.camo_transactions_resolved#

このファンクションは、 CAMOトランザクションが完全に解決されるまでの待機を開始します。

概要#

bdr.camo_transactions_resolved()

bdr.logical_transaction_status#

ノードに障害が発生したときにコミットされていたトランザクションのステータスを確認するには、アプリケーションがこのファンクションを使用し、トランザクションが発生したノードのノードIDと元ノードのトランザクションIDをパラメーターとして渡す必要があります。これらの値は次のとおりです

概要#

bdr.logical_transaction_status(node_id OID, xid OID,
                               require_camo_partner boolean DEFAULT true)

パラメーター#

  • node_id —トランザクションが発生するPGDノードのノードID。通常は、COMMIT の前にクライアントによって PQ parameter bdr.local_node_id から取得されます。

  • xid —オリジンノードのトランザクションID。通常は、COMMIT の前にクライアントによって PQ parameter transaction_id から取得されます。

  • require_camo_partner —デフォルトでtrueで、構成チェックが有効になります。これらのチェックを無効にし、 CAMOトランザクションではないトランザクションのステータスを照会するには、falseに設定します。

戻り値#

ファンクションは、次のいずれかの結果を返します。

  • 'committed'::TEXT —トランザクションはコミットされ、 CAMOペアの両方のノードで可視され、最終的に他のすべてのPGDノードにレプリケートされます。クライアントが再試行する必要はありません。

  • 'aborted'::TEXT —トランザクションは中止され、他のPGDノードにレプリケートされません。クライアントは再試行するか、トランザクションのコミットの失敗をエスカレートする必要があります。

  • 'in progress'::TEXT —トランザクションはこのローカルノードでまだ進行中であり、まだコミットまたは中止されていません。トランザクションはCOMMITフェーズにあり、 CAMOパートナーがコミットを確認または拒否するのを待機している可能性があります。推奨されるクライアントの反応は、元のノードから切断し、 CAMOパートナーに再接続して、代わりにそれを照会することです。間にロードバランサーまたはプロキシがあり、クライアントがどのノードを照会するかを制御できない場合、クライアントはステータスが'committed' または'aborted' に切り替わるまで、繰り返しポーリングのみできます。

Eager全ノードレプリケーションの場合、ピアノードはまだコミットまたは中止されていないトランザクションに対してこの結果を生成します。この場合、まだレプリケートされていないトランザクション、またはオリジンノードで開始されていないトランザクションでも、ピアPGDノードでin progress 結果を生成する場合があります。ただし、クライアントは、オリジンでコミットする前にトランザクションステータスを照会してはなりません。

  • 'unknown'::TEXT —指定されたトランザクションは、将来であるか、その特定のノードにまだレプリケートされていない、または過去すぎるため不明です。このようなトランザクションのステータスはまだ知られていない、または不明です。この戻り値は、クライアントによる不適切な使用の兆候です。

クライアントは、エラーが発生した場合にファンクション呼び出しを再試行する準備をする必要があります。

コミットスコープファンクション#

bdr.add_commit_scope#

bdr.add_commit_scope は、指定されたコミットスコープ名とオリジンノードグループのルールを作成します。ルールがEDB Postgres分散クラスター内のすべてのノードで同じである場合、トップレベルのノードグループに対してこのファンクションを1回呼び出すだけで、コミットスコープを完全に定義できます。

または、同じcommit_scope_name ではあるが、トランザクションのオリジンによって異なるオリジンノードグループとコミットスコープのルールを使用して、複数回呼び出すこともできます。

概要#

bdr.add_commit_scope(
    commit_scope_name NAME,
    origin_node_group NAME,
    rule TEXT,
    wait_for_ready boolean DEFAULT true)

bdr.alter_commit_scope#

bdr.alter_commit_scope を使用すると、コミットスコープ内のシングルオリジンノードグループの特定のルールを変更できます。

概要#

bdr.alter_commit_scope(
    commit_scope_name NAME,
    origin_node_group NAME,
    rule TEXT)

bdr.remove_commit_scope#

コミットスコープ内の単一のルールを削除します。コミットスコープに複数のルールを定義する場合、ルールごとに1回このファンクションを呼び出して、コミットスコープ全体を完全に削除する必要があります。

概要#

bdr.remove_commit_scope(
    commit_scope_name NAME,
    origin_node_group NAME)

注釈

ノードグループによってデフォルトとして使用されているコミットスコープを削除することはできません。

目次