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は、 SHOW またはcurrent_setting() ファンクションなどを使用してSQLで直接照会できるいくつかのパラメーターを公開します。クライアントアプリケーションからPQparameterStatus または同等のものを使用することもできます。

bdr.local_node_id#

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

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

bdr.last_committed_lsn#

非同期トランザクションのCOMMIT ごとに、このパラメーターは更新されて、オリジンノードのコミットレコードの最後を指します。 bdr.wait_for_apply_queue と組み合わせると、アプリケーションはマルチプルのノードにわたってカウサル読み取りを実行できます。つまり、トランザクションがリモートで可視されるまで待機します。

transaction_id#

CAMOトランザクションが進行中の場合、transaction_id が更新されて、割り当てられたトランザクションIDが表示されます。このパラメーターは、 PQparameterStatus または同等の使用を使用してのみ照会でき、 SQLではアクセスできません。 アプリケーションの使用 を参照

使用例

ノードステータスファンクション#

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_global_lection_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 をより早く完了するように設定することができます。

Optimized Topology を使用している場合、代わりに bdr.wait_node_confirm_lsn を使用することをお勧めします。 )

概要#

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

注#

使用するにはbdr_application 権限が必要です。

パラメーター#

Parameter

Description

slot_name

待機するレプリケーションスロットの名前。 NULLの場合、すべてのPGDスロットを待機します。

target_lsn

待機するLSN。 NULLの場合、ローカルノードの現在の書き込みLSNを使用します。

bdr.wait_node_confirm_lsn#

ノードが特定のLSNを通過するまで待機します。

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

ファンクションは、呼び出されると、ノードが特定のLSNを渡すのを待機します。 LSNが指定されない場合、現在のwal_flush_lsn pg_current_wal_flush_lsn() ファンクションを使用しての位置がローカルノードで使用されます。ノード名パラメーターを指定すると、そのノードがLSNを渡すのを待機するようにファンクションに指示します。 ノード名がNULLを渡すことにより指定されない場合、ファンクションはすべてのノードがLSNを渡すまで待機します。

bdr.wait_slot_confirm_lsn ではなく Optimized Topology を使用している場合、このファンクションを使用することをお勧めします。

これは、最適化トポロジでは、すべてのノードにレプリケーションスロットがあるわけではないため、ファンクション bdr.wait_slot_confirm_lsn が予想通りに動作しない場合があるためです。 bdr.wait_node_confirm_lsn は、レプリケーションスロットのないノードで動作するように設計されており、代替戦略を使用してノードの進行状況を判断します。

ノードが現在ダウンしているか、更新していない場合、または単に接続できない場合、待機は無期限に継続されます。この状態を回避するには、statement_timeoutを待機する準備ができている最大時間に設定します。

概要#

bdr.wait_node_confirm_lsn(node_name text DEFAULT NULL, target_lsn pg_lsn DEFAULT NULL)

パラメーター#

Parameter

Description

node_name

待機するノードの名前。 NULLの場合、すべてのノードを待機します。

target_lsn

待機するLSN。 NULLの場合、ローカルノードで現在のwal_flush_lsnを使用します。

注#

使用するにはbdr_application 権限が必要です。

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)

パラメーター#

Parameter

Description

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)

パラメーター#

Parameter

Description

node_name

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

committed

デフォルトtrueでは、このファンクションは、最後のLSN全体ではなく、受信したトランザクションのコミットのみを考慮します。これには、サブスクライバノードに影響を与えないアクションが含まれます。

bdr.get_node_sub_apply_lsn#

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

概要#

bdr.get_node_sub_apply_lsn(node_name name)

パラメーター#

Parameter

Description

node_name

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

bdr.replicate_ddl_command#

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

概要#

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

パラメーター#

Parameter

Description

ddl_cmd

実行するDDLコマンド。

replication_sets

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

ddl_locking

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

execute_locally

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

注#

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

bdr.replicate_ddl_command() は常にコマンドをレプリケートし、 bdr.ddl_replication の設定の影響を受けません。

bdr.run_on_all_nodes#

すべてのノードでクエリを実行するファンクション。

警告

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

概要#

bdr.run_on_all_nodes(query text)

パラメーター#

Parameter

Description

query

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

注#

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

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

PGD 6以降では、このファンクションは接続でbdr.xact_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=pgddb user=postgres ",
        "node_id": "2232128708",
        "response": {
            "command_status": "SELECT 1",
            "command_tuples": [
                {
                    "origin_name": "node1",
                    "target_name": "node2",
                    "local_slot_name": "bdr_pgddb_bdrgroup_node2",
                    "replay_lag_size": "0 bytes"
                }
            ]
        },
        "node_name": "node1"
    },
    {
        "dsn": "host=node2 port=5432 dbname=pgddb user=postgres ",
        "node_id": "2058684375",
        "response": {
            "command_status": "SELECT 1",
            "command_tuples": [
                {
                    "origin_name": "node2",
                    "target_name": "node1",
                    "local_slot_name": "bdr_pgddb_bdrgroup_node1",
                    "replay_lag_size": "0 bytes"
                }
            ]
        },
        "node_name": "node2"
    }
]

bdr.run_on_nodes#

指定されたノードのリストでクエリを実行するファンクション。

警告

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

概要#

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

パラメーター#

Parameter

Description

node_names

クエリが実行されるノード名のテキストARRAY。

query

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

注#

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

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

PGD 6以降では、このファンクションは接続でbdr.xact_replication=off も設定して、コマンドが別のノードで実行された場合にのみトランザクションがローカルで実行されるようにします。

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

bdr.run_on_group#

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

警告

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

概要#

bdr.run_on_group(node_group_name text, query text)

パラメーター#

Parameter

Description

node_group_name

クエリが実行されるノードグループの名前。

query

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

注#

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

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

PGD 6以降では、このファンクションは接続でbdr.xact_replication=off も設定して、コマンドが別のノードで実行された場合にのみトランザクションがローカルで実行されるようにします。

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

bdr.global_lock_table#

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

概要#

bdr.global_lock_table(relation regclass)

パラメーター#

Parameter

Description

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)

パラメーター#

Parameter

Description

origin_node_id

トランザクションが発生したノードのノードID。

origin_topxid

トランザクションのXID。

allnodes

`true`の場合、すべてのノードでトランザクションが進行するまで待機します。それ以外の場合、現在のノードのみを待機します。

注#

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

bdr.local_group_slot_name#

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

例#

pgddb=# SELECT bdr.local_group_slot_name();
 local_group_slot_name
- ----------------------
 bdr_pgddb_bdrgroup

bdr.node_group_type#

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

例#

pgddb=# 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);

パラメーター#

Parameter

Description

node_name

種類を変更するノードの名前。

node_kind

ノードの種類。

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)

パラメーター#

Parameter

Description

key1

複合キーの最初の部分。

key2

複合キーの2番目の部分。

bdr.global_advisory_unlock#

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

概要#

bdr.global_advisory_unlock(key bigint)

パラメーター#

Parameter

Description

key

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

概要#

bdr.global_advisory_unlock(key1 integer, key2 integer)

パラメーター#

Parameter

Description

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

パラメーター#

Parameter

Description

node_group_name

確認するノードグループ名。

注#

モニタリング パラレル 適用 で説明しているように、このファンクションは、フィールド status およびmessage を持つレコードを結果ます。

このファンクションはbdr.run_on_all_nodes() を呼び出します。

bdr.monitor_local_replslots#

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

この機能は、 optimized topology が有効になっているときにPGDクラスターでサブスクライバ専用グループリーダーとして動作しているサブスクライバ専用ノードのステータス情報も提供します。

概要#

bdr.monitor_local_replslots()

注#

このファンクションは、フィールドstatus およびmessage を持つレコードを結果ます。

Status

Message

UNKNOWN

This node is not part of any BDR group

OK

All BDR replication slots are working correctly

OK

This node is part of a subscriber-only group

CRITICAL

There is at least 1 BDR replication slot which is inactive

CRITICAL

There is at least 1 BDR replication slot which is missing

レプリケーションスロットの監視 で詳細な説明が得られます。

bdr.wal_sender_stats#

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

概要#

bdr.wal_sender_stats()

出力列#

Column name

Description

pid

WAL送信者のPID。 `pg_stat_replication`の`pid`列に対応します。

is_using_lcr

WAL送信者がLCRファイルを送信しているかどうか。

decoder_slot_name

デコーダーレプリケーションスロットの名前。

lcr_file_name

現在のLCRファイルの名前。

bdr.get_decoding_worker_stat#

Decoding worker が有効になっている場合、このファンクションは、現在のデータベースに関連付けられているデコードワーカーの状態に関する情報を表示します。これは、ワーカーの進行状況のデコードに関するより詳細な情報も提供します pg_replication_slots を介して利用可能な情報。

概要#

bdr.get_decoding_worker_stat()

出力列#

Column name

Description

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

出力列#

Column name

Description

commit_scope_id

コミットスコープのOID :ref:``bdr.commit_scopes` 列<bdr.commit_scopes 列>` を参照してください。

sessions

遅延制御エントリを参照するセッションの数。

current_commit_delay

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

maximum_commit_delay

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

commit_delay_adjust

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

current_conforming_nodes

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

minimum_conforming_nodes

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

lag_bytes_threshold

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

maximum_lag_bytes

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

lag_time_threshold

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

maximum_lag_time

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

sample_interval

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

ルーティング機能#

bdr.routing_leadership_transfer#

ルーティングリーダーを変更すると、ノードグループのリーダーシップが別のノードに転送されます。

概要#

bdr.routing_leadership_transfer(node_group_name text,
              leader_name text,
              transfer_method text DEFAULT strict,
              transfer_timeout interval DEFAULT 10s);

パラメーター#

Name

Type

Default

Description

node_group_name

text

リーダーシップの譲渡が要求されたグループの名前。

leader_name

text

書き込みリーダーになるノードの名前。

transfer_method

text

'strict'

転送の種類。 'fast'`またはデフォルトの'strict'`で、最大遅延をチェックします。

transfer_timeout

interval

'10s'

リーダーシップ転送のタイムアウト。デフォルトは10秒です。

CAMOファンクション#

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

bdr.is_camo_partner_connected#

ペアモードで構成されたCAMOパートナーノードの接続ステータスを確認できます。現在、熱心なレプリケーションで使用される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)

パラメーター#

Parameter

Description

node_id

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

xid

オリジンノードのトランザクションID。通常、COMMIT`から :ref:`pg_upgrade <Monitoring through SQL> `transaction_id`の前にクライアントによって取得されます。

require_camo_partner

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

戻り値#

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

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

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

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

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

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

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

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

bdr.add_commit_scope#

非推奨 。代わりに bdr.create_commit_scope を使用してください。以前は、この機能を使用してコミットスコープをノードグループに追加しました。現在は非推奨であり、将来のリリースで削除されるまで警告を発し、その時点でエラーが発生します。

bdr.create_commit_scope#

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

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

概要#

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

注#

bdr.create_commit_scope は、非推奨の bdr.add_commit_scope ファンクションを置き換えます。 add_commit_scope とは異なり、同じ名前が使用される場合、既存のコミットスコープをサイレントに上書きしません。代わりに、エラーが報告されます。

bdr.alter_commit_scope#

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

概要#

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

bdr.drop_commit_scope#

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

概要#

bdr.drop_commit_scope(
    commit_scope_name NAME,
    origin_node_group NAME)

注釈

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

bdr.remove_commit_scope#

非推奨 。代わりに bdr.drop_commit_scope を使用してください。以前は、このファンクションはノードグループからコミットスコープを削除するために使用されていました。現在は非推奨であり、将来のリリースで削除されるまで警告を発し、その時点でエラーが発生します。

目次