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に設定されます。これにより、アプリケーションは、透明なプロキシの背後にある場合でも、接続されているノードを認識できます。 :ref:`接続プールとプロキシ <接続プールとプロキシ>` でも使用されます。 bdr.last_committed_lsn ^^^^^^^^^^^^^^^^^^^^^^ 非同期トランザクションの\ ``COMMIT`` ごとに、このパラメーターは更新されて、オリジンノードのコミットレコードの最後を指します。 ``bdr.wait_for_apply_queue`` と組み合わせると、アプリケーションはマルチプルのノードにわたってカウサル読み取りを実行できます。つまり、トランザクションがリモートで可視されるまで待機します。 transaction_id ^^^^^^^^^^^^^^ CAMOが有効になっている場合、PostgresがトランザクションIDを割り当てるとすぐに、このパラメーターが更新されて、割り当てられたばかりのトランザクションIDを表示します。 bdr.is_node_connected ^^^^^^^^^^^^^^^^^^^^^ 概要 ^^^^ .. code:: sql bdr.is_node_connected(node_name name) 指定されたピアのワルセンダーがこのノードでアクティブかどうかを確認することにより、ブール値を返します。 bdr.is_node_ready ^^^^^^^^^^^^^^^^^ .. _概要-1: 概要 ^^^^ .. code:: sql bdr.is_node_ready(node_name name, span interval DEFAULT NULL) ラグが指定されたスパンより低いか、それ以外の場合は\ ``TO ASYNC`` の\ ``timeout`` より低いかどうかをチェックすることにより、ブール値を返します。 コンセンサスファンクション -------------------------- bdr.consensus_disable ^^^^^^^^^^^^^^^^^^^^^ サーバーが再起動するか、\ ``bdr.consensus_enable`` を使用して再有効化されるまで、ローカルノードのコンセンサスワーカーを無効にします。最初に発生した方。 .. Warning:: コンセンサスを無効にすると、PGDの一部の機能が無効になり、長時間無効になっているとEDB Postgres分散クラスターの可用性に影響します。この機能は、テクニカルサポートと協力する場合にのみ使用します。 bdr.consensus_enable ^^^^^^^^^^^^^^^^^^^^ ローカルノードで無効になったコンセンサスワーカーが再度有効になりました。 bdr.consensus_proto_version ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ローカルノードが現在使用しているコンセンサスプロトコルのバージョンを返します。 PGDグループの再構成の内部メカニズムに必要です。 bdr.consensus_snapshot_export ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. _概要-2: 概要 ^^^^ .. code:: sql 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. _概要-3: 概要 ^^^^ .. code:: sql 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. _概要-4: 概要 ^^^^ .. code:: sql 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. _概要-5: 概要 ^^^^ .. code:: sql 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`` をより早く完了するように設定することができます。 .. _概要-6: 概要 ^^^^ .. code:: sql 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パートナーノードにこのファンクションのバリアントを提供します。 :ref:`bdr.wait_for_camo_partner_queue ` を参照してください。 特定のLSNが指定された場合、それは、ピアが待機するリカバリストリームのポイントです。これは、以前のまたは同時接続でそのピアノードから取得した\ ``bdr.last_committed_lsn`` と使用できます。 指定された\ ``target_lsn`` がNULLの場合、このファンクションはローカル受信バッファをチェックし、指定されたピアノードから受け取った最後のトランザクションのLSNを使用し、既に受信したすべてのトランザクションが適用されるのを効果的に待機します。これは、ピアノードに障害が発生し、どのトランザクションが送信されたかが不明な場合に特に役立ちます。この場合、送信者側でまだ転送中またはバッファリングされているトランザクションは待機されません。 .. _概要-7: 概要 ^^^^ .. code:: sql bdr.wait_for_apply_queue(peer_node_name TEXT, target_lsn pg_lsn) .. _パラメーター-1: パラメーター ^^^^^^^^^^^^ - ``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()`` の出力の差は、対応する適用キューのサイズを測定します。 .. _概要-8: 概要 ^^^^ .. code:: sql bdr.get_node_sub_receive_lsn(node_name name, committed bool default true) .. _パラメーター-2: パラメーター ^^^^^^^^^^^^ - ``node_name`` — LSNが取得されるレプリケーションストリームのソースであるノードの名前。 - ``committed`` —;デフォルトtrueでは、このファンクションは、最後のLSN全体ではなく、受信したトランザクションのコミットのみを考慮します。これには、サブスクライバノードに影響を与えないアクションが含まれます。 bdr.get_node_sub_apply_lsn ^^^^^^^^^^^^^^^^^^^^^^^^^^ サブスクライバーでこのファンクションを使用して、特定のオリジンから受信および適用された最後のLSNを取得できます。 .. _概要-9: 概要 ^^^^ .. code:: sql bdr.get_node_sub_apply_lsn(node_name name) .. _パラメーター-3: パラメーター ^^^^^^^^^^^^ - ``node_name`` — LSNが取得されるレプリケーションストリームのソースであるノードの名前。 bdr.replicate_ddl_command ^^^^^^^^^^^^^^^^^^^^^^^^^ ノードのグループにDDLコマンドを複製する機能。 .. _概要-10: 概要 ^^^^ .. code:: sql bdr.replicate_ddl_command(ddlcommand text, replication_sets text[], ddl_locking text, execute_locally bool) .. _パラメーター-4: パラメーター ^^^^^^^^^^^^ - ``ddlcommand`` —実行するDDLコマンド。 - ``replication_sets`` — ``ddlcommand`` を適用するレプリケーションセット名の配列。 NULLの場合、またはファンクションが\ ``ddlcommand`` のみが渡される場合、これはアクティブなPGDグループのデフォルトのレプリケーションセットに設定されます。 - ``ddl_locking`` —レプリケート中に :ref:`bdr.ddl_locking ` 値を設定する文字列。 require_ddl_commandを実行しているローカルシステム上の\ ``bdr.ddl_locking`` のGUC値のデフォルト。 - ``execute_locally`` — DDLコマンドをローカルに実行するかどうかを決定するブール値。デフォルトtrue。 注 ^^ このファンクションの唯一の必須パラメーターは\ ``ddlcommand`` です。 bdr.run_on_all_nodes ^^^^^^^^^^^^^^^^^^^^ すべてのノードでクエリを実行するファンクション。 .. Warning:: このファンクションは、ノードのDSNで指定されたノード間接続に使用されるユーザーの権限を使用して、リモートノードで任意のクエリーを実行します。この機能に特権を付与するときは注意してください。 .. _概要-11: 概要 ^^^^ .. code:: sql bdr.run_on_all_nodes(query text) .. _パラメーター-5: パラメーター ^^^^^^^^^^^^ - ``query`` —実行する任意のクエリー。 .. _注-1: 注 ^^ このファンクションは、他のノードに接続してクエリーを実行し、各ノードからJSON形式で結果を返します。複数の行が各ノードから返され、JSON配列としてエンコードされる場合があります。ノードがダウンしているため接続できないなどのエラーは、応答フィールドに表示されます。明示的なstatement_timeoutまたはその他のランタイムパラメーターが設定されていないため、デフォルトが使用されます。 このファンクションは、通常のレプリケーションを経由しません。すべての既知のノードへの直接クライアント接続を使用します。デフォルトでは、コマンドはクラスター内のすべてのノードに既に送信されているため、\ ``bdr.ddl_replication = off`` で接続が作成されます。 レプリケーションが中断され、ノード間で不一致が発生する危険があるため、この機能を使用する場合は注意してください。透過的DDLレプリケーションまたは\ ``bdr.replicate_ddl_command()`` を使用してDDLをレプリケートします。 DDLは、将来のリリースでブロックされる可能性があります。 例 ^^ 例、次のクエリのように、モニタリングでこのファンクションを使用すると便利です。 .. code:: sql 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 ^^^^^^^^^^^^^^^^ 指定されたノードのリストでクエリを実行するファンクション。 .. Warning:: このファンクションは、ノードのDSNで指定されたノード間接続に使用されるユーザーの権限を使用して、リモートノードで任意のクエリーを実行します。この機能に特権を付与するときは注意してください。 .. _概要-12: 概要 ^^^^ .. code:: postgresql bdr.run_on_nodes(node_names text[], query text) .. _パラメーター-6: パラメーター ^^^^^^^^^^^^ - ``node_names`` —クエリーが実行されるノード名のテキストARRAY - ``query`` —実行する任意のクエリー。 .. _注-2: 注 ^^ このファンクションは、他のノードに接続してクエリーを実行し、各ノードからJSON形式で結果を返します。複数の行を各ノードから返すことができ、JSON配列としてエンコードされます。ノードがダウンしているため接続できないなどのエラーは、応答フィールドに表示されます。明示的なstatement_timeoutまたはその他のランタイムパラメーターが設定されていないため、デフォルトが使用されます。 このファンクションは、通常のレプリケーションを経由しません。すべての既知のノードへの直接クライアント接続を使用します。デフォルトでは、接続は\ ``bdr.ddl_replication = off`` で作成され、同じレプリケートされたDDLコマンドが複数のノードに送信された場合のレプリケーションの問題を回避します。 レプリケーションが中断され、ノード間で不一致が発生する危険があるため、この機能を使用する場合は注意してください。グローバルスキーマ変更の場合、透過的DDLレプリケーションまたは ``bdr.replicate_ddl_command()`` を使用してDDLをレプリケートします。 bdr.run_on_group ^^^^^^^^^^^^^^^^ ノードのグループでクエリを実行する機能。 .. Warning:: このファンクションは、ノードのDSNで指定されたノード間接続に使用されるユーザーの権限を使用して、リモートノードで任意のクエリーを実行します。この機能に特権を付与するときは注意してください。 .. _概要-13: 概要 ^^^^ .. code:: postgresql bdr.run_on_group(node_group_name text, query text) .. _パラメーター-7: パラメーター ^^^^^^^^^^^^ - ``node_group_name`` —クエリが実行されるノードグループの名前。 - ``query`` —実行する任意のクエリー。 .. _注-3: 注 ^^ このファンクションは、他のノードに接続してクエリーを実行し、各ノードからJSON形式で結果を返します。複数の行を各ノードから返すことができ、JSON配列としてエンコードされます。ノードがダウンしているため接続できないなどのエラーは、応答フィールドに表示されます。明示的なstatement_timeoutまたはその他のランタイムパラメーターが設定されていないため、デフォルトが使用されます。 このファンクションは、通常のレプリケーションを経由しません。すべての既知のノードへの直接クライアント接続を使用します。デフォルトでは、接続は\ ``bdr.ddl_replication = off`` で作成され、同じレプリケートされたDDLコマンドが複数のノードに送信された場合のレプリケーションの問題を回避します。 レプリケーションが中断され、グループ内のノード間で不一致が発生する危険があるため、この機能を使用する場合は注意してください。グローバルスキーマ変更の場合、透過的DDLレプリケーションまたは ``bdr.replicate_ddl_command()`` を使用してDDLをレプリケートします。 bdr.global_lock_table ^^^^^^^^^^^^^^^^^^^^^ このファンクションは、指定されたテーブルのグローバルDMLロックを取得します。グローバルDMLロックの詳細については、 :ref:`DDL locking details ` を参照してください。 .. _概要-14: 概要 ^^^^ .. code:: sql bdr.global_lock_table(relation regclass) .. _パラメーター-8: パラメーター ^^^^^^^^^^^^ - ``relation`` —ロックへの関係の名前またはoid。 .. _注-4: 注 ^^ このファンクションは、\ ``ddl_locking`` 設定とは無関係にグローバルDMLロックを取得します。 ``bdr.global_lock_table`` ファンクションには、 ``bdr.backwards_compatibility`` が30618以下に設定されていない限り、ロックされた\ ``relation`` に対する\ ``UPDATE`` 、\ ``DELETE`` 、または\ ``TRUNCATE`` 特権が必要です。 bdr.wait_for_xid_progress ^^^^^^^^^^^^^^^^^^^^^^^^^ このファンクションを使用して、特定のノードノードIDで識別される特定のトランザクションXIDで識別されるが、クラスターで十分な進行を行うのを待機できます。進行状況は、ノードに適用されているトランザクションとして定義され、このノードは、トランザクションが適用される前に行われた他のすべてのレプリケーション変更を確認しています。 .. _概要-15: 概要 ^^^^ .. code:: sql bdr.wait_for_xid_progress(origin_node_id oid, origin_topxid int4, allnodes boolean DEFAULT true) .. _パラメーター-9: パラメーター ^^^^^^^^^^^^ - ``origin_node_id`` —トランザクションが発生したノードのノードID。 - ``origin_topxid`` —トランザクションのXID。 - ``allnodes`` — ``true`` の場合、すべてのノードでトランザクションが進行するまで待機します。それ以外の場合は、現在のノードのみを待機します。 .. _注-5: 注 ^^ 現在、これらのトランザクションのみが追跡されるため、 DDLコマンドをレプリケートしたトランザクションにのみファンクションを使用できます。誤った\ ``origin_node_id`` または\ ``origin_topxid`` が指定された場合、ファンクションは永久にまたは\ ``statement_timeout`` が発生するまで待機する場合があります。 bdr.local_group_slot_name ^^^^^^^^^^^^^^^^^^^^^^^^^ ローカルノードのグループスロットの名前を返します。 .. _例-1: 例 ^^ .. code:: sql 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`` が返されます。 .. _例-2: 例 ^^ .. code:: sql 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ファンクションを呼び出すことにより、これを手動で行うことが予想されます。 .. _概要-16: 概要 ^^^^ .. code:: sql bdr.alter_node_kind(node_name text, node_kind text); .. _パラメーター-10: パラメーター ^^^^^^^^^^^^ - ``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. サブスクリプションを再度有効にします。 .. Warning:: このファンクションを使用すると、問題を悪化させるのは簡単です。それが唯一のオプションであると確信できない限り、何もしないでください。 .. _概要-17: 概要 ^^^^ .. code:: sql bdr.alter_subscription_skip_changes_upto( subname text, skip_upto_and_including pg_lsn ); .. _例-3: 例 ^^ トランザクションの適用はエラーで失敗し、ターゲット側の変更などのインパクトの低い修正ではこの問題を解決できないと判断しました。トランザクションをスキップする必要があると判断します。 エラーログで、次の例のように、スキップするコミットレコード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** 次に、サブスクリプションを無効にして、適用ワーカーがレプリケーションスロットに接続しようとしないようにします。 .. code:: sql SELECT bdr.alter_subscription_disable(the_subscription); トランザクションの一部だけをスキップすることはできません。それはオール・オア・ナッシングです。したがって、サブスクリプションのスロット名を使用して、最初にプロバイダー側でコピーして、レコードを保存することを強くお勧めします。 .. code:: sql \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`` は、すべてのデータのデコードと出力を回避する高速なスキップを行います。 .. code:: sql SELECT bdr.alter_subscription_skip_changes_upto(subscription_name, the_target_lsn); ダンプされたトランザクションの内容をガイドとして使用して、同じ変更またはその修復バージョンをターゲットノードに手動で適用できます。 最後に、サブスクリプションを再度有効にします。 .. code:: sql SELECT bdr.alter_subscription_enable(the_subscription); グローバルアドバイザリーロック ------------------------------ PGDは、グローバルアドバイザリーロックをサポートしています。これらのロックは、 PGDでサポートされている勧告ロックがグローバルであることを除き、 PostgreSQLで使用可能な勧告ロックと似ています。これらはDDLロックと同様のセマンティクスに従います。したがって、アドバイザリロックはマジョリティコンセンサスによって取得され、すべてのノードの大部分が連携できる限り、1つ以上のノードがダウンまたは遅延している場合でも使用できます。 現在、EXCLUSIVEロックのみがサポートされています。したがって、別のノードまたは同じノード上の別のバックエンドがオブジェクトの勧告ロックを既に取得している場合、他のノードまたはバックエンドはロックが解放されるまで待機する必要があります。 アドバイザリーロックはトランザクション的な性質を持っています。したがって、トランザクションが終了する前に明示的に解放しない限り、トランザクションが終了するとロックは自動的に解放されます。この場合、リリースされるとすぐに利用可能になります。セッションレベルの勧告ロックは現在サポートされていません。 グローバル勧告ロックは再入可能です。したがって、同じリソースが3回ロックされている場合、他のセッションで使用できるように解放するには、3回ロックを解除する必要があります。 bdr.global_advisory_lock ^^^^^^^^^^^^^^^^^^^^^^^^ このファンクションは、提供されたオブジェクトのEXCLUSIVEロックを取得します。ロックが利用できない場合、ロックが利用可能になるか、\ ``bdr.global_lock_timeout`` に到達するまで待機します。 .. _概要-18: 概要 ^^^^ .. code:: sql bdr.global_advisory_lock(key bigint) .. _パラメーター-11: パラメーター ^^^^^^^^^^^^ - ``key`` —アドバイザリロックが取得されるオブジェクト。 .. _概要-19: 概要 ^^^^ .. code:: sql bdr.global_advisory_lock(key1 integer, key2 integer) .. _パラメーター-12: パラメーター ^^^^^^^^^^^^ - ``key1`` —複合キーの最初の部分。 - ``key2`` —複合キーの2番目の部分。 bdr.global_advisory_unlock ^^^^^^^^^^^^^^^^^^^^^^^^^^ このファンクションは、アプリケーション定義のソースで以前に取得したロックを解放します。ロックは、アプリケーションによって同じトランザクションで取得されている必要があります。それ以外の場合、エラーが発生します。 .. _概要-20: 概要 ^^^^ .. code:: sql bdr.global_advisory_unlock(key bigint) .. _パラメーター-13: パラメーター ^^^^^^^^^^^^ - ``key`` —アドバイザリロックが取得されるオブジェクト。 .. _概要-21: 概要 ^^^^ .. code:: sql bdr.global_advisory_unlock(key1 integer, key2 integer) .. _パラメーター-14: パラメーター ^^^^^^^^^^^^ - ``key1`` —複合キーの最初の部分。 - ``key2`` —複合キーの2番目の部分。 モニタリング機能 ---------------- bdr.monitor_group_versions ^^^^^^^^^^^^^^^^^^^^^^^^^^ クラスター全体のバージョンチェックを提供するために、このファンクションはビュー ``bdr.group_version_details`` から返されたPGDバージョン情報を使用します。 .. _概要-22: 概要 ^^^^ .. code:: sql bdr.monitor_group_versions() .. _注-6: 注 ^^ :ref:`競合のモニタリング <競合のモニタリング>` で説明しているように、このファンクションは、フィールド ``status`` および\ ``message`` を持つレコードを結果ます。 このファンクションは\ ``bdr.run_on_all_nodes()`` を呼び出します。 bdr.monitor_group_raft ^^^^^^^^^^^^^^^^^^^^^^ クラスター全体のRaftチェックを提供するために、このファンクションはビュー\ ``bdr.group_raft_details`` から返されたPGD Raft情報を使用します。 .. _概要-23: 概要 ^^^^ .. code:: sql bdr.monitor_group_raft() .. _パラメーター-15: パラメーター ^^^^^^^^^^^^ - ``node_group_name`` —確認するノードグループ名。 .. _注-7: 注 ^^ :ref:`競合のモニタリング <競合のモニタリング>` で説明しているように、このファンクションは、フィールド ``status`` および\ ``message`` を持つレコードを結果ます。 このファンクションは\ ``bdr.run_on_all_nodes()`` を呼び出します。 bdr.monitor_local_replslots ^^^^^^^^^^^^^^^^^^^^^^^^^^^ このファンクションは、ビュー\ ``pg_replication_slots`` スロットアクティブまたは非アクティブから返されたレプリケーションスロットステータス情報を使用して、PGDグループスロットを除くすべてのレプリケーションスロットを考慮したローカルチェックを提供します。 .. _概要-24: 概要 ^^^^ .. code:: sql bdr.monitor_local_replslots() .. _注-8: 注 ^^ :ref:`レプリケーションスロットの監視 <レプリケーションスロットの監視>` で説明しているように、このファンクションは、フィールド ``status`` および\ ``message`` を持つレコードを結果ます。 bdr.wal_sender_stats ^^^^^^^^^^^^^^^^^^^^ :ref:`デコードワーカー <デコードワーカー>` が有効になっている場合、このファンクションは、デコーダースロットと、各WAL送信者によって読み取られている現在のLCR論理変更レコードセグメントファイルに関する情報を表示します。 .. _概要-25: 概要 ^^^^ .. code:: sql 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :ref:`デコードワーカー <デコードワーカー>` が有効になっている場合、このファンクションは、現在のデータベースに関連付けられているデコードワーカーの状態に関する情報を表示します。これは、ワーカーの進行状況のデコードに関するより詳細な情報も提供します ``pg_replication_slots`` を介して利用可能な情報。 .. _概要-26: 概要 ^^^^ .. code:: sql bdr.get_decoding_worker_stat() .. _出力列-1: 出力列 ^^^^^^ - ``pid`` —デコードワーカーのPID ``pg_replication_slots`` の列\ ``active_pid`` に対応します。 - ``decoded_upto_lsn`` —デコードワーカーがトランザクションログを読み取るLSN。 - ``waiting`` —デコードワーカーが新しいWALを待機しているかどうか。 - ``waiting_for_lsn`` —次に予想されるWALのLSN。 .. _注-9: 注 ^^ 詳細については、 :ref:`LCRを使用したWAL送信者のモニタリング ` を参照してください。 bdr.lag_control ^^^^^^^^^^^^^^^ :ref:`遅延制御 <遅延制御>` が有効になっている場合、このファンクションは、ローカルノードと現在のデータベースの構成された遅延測定に準拠するノードの数とコミット遅延に関する情報を表示します。 .. _概要-27: 概要 ^^^^ .. code:: sql bdr.lag_control() .. _出力列-2: 出力列 ^^^^^^ - ``commit_scope_id`` —コミットスコープのOID :ref:`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では、クライアントがトランザクションの進行状況を追跡することにより、トランザクションのコミットに積極的に参加する必要があります。ここにリストされているファンクションはそのために使用され、 :ref:`CAMOまたはコミット・アット・モスト・ワンス ` セクションで説明されています。 bdr.is_camo_partner_connected ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ペアモードで構成されたCAMOパートナーノードの接続ステータスを確認できます。現在、Eagerレプリケーションで使用されるCAMOに相当するものはありません。 .. _概要-28: 概要 ^^^^ .. code:: sql bdr.is_camo_partner_connected() 戻り値 ^^^^^^ CAMOパートナーが現在ローカルノード上のWAL送信プロセスに接続しているため、トランザクションデータを受信し、確認を送り返すことができるかどうかを示すブール値。 bdr.is_camo_partner_ready ^^^^^^^^^^^^^^^^^^^^^^^^^ ペアモードで構成されたCAMOパートナーノードの準備状況を確認できます。その下で、これはローカルモードへの、またはローカルモードからのスイッチをトリガーします。 .. _概要-29: 概要 ^^^^ .. code:: sql bdr.is_camo_partner_ready() .. _戻り値-1: 戻り値 ^^^^^^ CAMOパートナーがタイムリーに、つまり\ ``TO ASYNC`` の\ ``timeout`` の有効期限が切れる前に、ローカルノードから発生したトランザクションを確認することが合理的に期待できるかどうかを示すブール値。 .. Note:: このファンクションは、過去または現在の状態を照会します。正の戻り値は、 CAMOパートナーが将来のトランザクションを確認できるかどうかを示しません。 bdr.get_configured_camo_partner ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ この機能は、ローカルノードのCAMOパートナーペアモードで構成を表示します。 .. _概要-30: 概要 ^^^^ .. code:: sql bdr.get_configured_camo_partner() bdr.wait_for_camo_partner_queue ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ このファンクションは、 CAMOパートナーノードを照会することがデフォルトの\ ``bdr.wait_for_apply_queue`` のラッパーです。ローカルノードがCAMOペアの一部でない場合、エラーを返します。 .. _概要-31: 概要 ^^^^ .. code:: sql bdr.wait_for_camo_partner_queue() bdr.camo_transactions_resolved ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ このファンクションは、 CAMOトランザクションが完全に解決されるまでの待機を開始します。 .. _概要-32: 概要 ^^^^ .. code:: sql bdr.camo_transactions_resolved() bdr.logical_transaction_status ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ノードに障害が発生したときにコミットされていたトランザクションのステータスを確認するには、アプリケーションがこのファンクションを使用し、トランザクションが発生したノードのノードIDと元ノードのトランザクションIDをパラメーターとして渡す必要があります。これらの値は次のとおりです .. _概要-33: 概要 ^^^^ .. code:: sql bdr.logical_transaction_status(node_id OID, xid OID, require_camo_partner boolean DEFAULT true) .. _パラメーター-16: パラメーター ^^^^^^^^^^^^ - ``node_id`` —トランザクションが発生するPGDノードのノードID。通常は、\ ``COMMIT`` の前にクライアントによって :ref:`PQ parameter ` ``bdr.local_node_id`` から取得されます。 - ``xid`` —オリジンノードのトランザクションID。通常は、\ ``COMMIT`` の前にクライアントによって :ref:`PQ parameter ` ``transaction_id`` から取得されます。 - ``require_camo_partner`` —デフォルトでtrueで、構成チェックが有効になります。これらのチェックを無効にし、 CAMOトランザクションではないトランザクションのステータスを照会するには、falseに設定します。 .. _戻り値-2: 戻り値 ^^^^^^ ファンクションは、次のいずれかの結果を返します。 - ``'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`` ではあるが、トランザクションのオリジンによって異なるオリジンノードグループとコミットスコープのルールを使用して、複数回呼び出すこともできます。 .. _概要-34: 概要 ^^^^ .. code:: sql 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`` を使用すると、コミットスコープ内のシングルオリジンノードグループの特定のルールを変更できます。 .. _概要-35: 概要 ^^^^ .. code:: sql bdr.alter_commit_scope( commit_scope_name NAME, origin_node_group NAME, rule TEXT) bdr.remove_commit_scope ^^^^^^^^^^^^^^^^^^^^^^^ コミットスコープ内の単一のルールを削除します。コミットスコープに複数のルールを定義する場合、ルールごとに1回このファンクションを呼び出して、コミットスコープ全体を完全に削除する必要があります。 .. _概要-36: 概要 ^^^^ .. code:: sql bdr.remove_commit_scope( commit_scope_name NAME, origin_node_group NAME) .. Note:: ノードグループによってデフォルトとして使用されているコミットスコープを削除することはできません。