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ではアクセスできません。 Application use を参照
使用例
ノードステータスファンクション#
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_disable(node_group_name text DEFAULT NULL)
サーバーが再起動するか、bdr.consensus_enable
を使用して再有効化されるまで、ローカルノードのコンセンサスワーカーを無効にします。最初に発生した方。
node_group_name
パラメーターは、インターフェイスの一貫性のために受け入れられますが、現在プレースホルダーです。このファンクションは、データベース全体でコンセンサスワーカーを無効にし、渡された値に関係なく、ノード上のすべてのRaftインスタンスに影響を与えます。
警告
コンセンサスを無効にすると、PGDの一部の機能が無効になり、長時間無効になっているとEDB Postgres分散クラスターの可用性に影響します。この機能は、テクニカルサポートと協力する場合にのみ使用します。
bdr.consensus_enable#
概要#
bdr.consensus_enable(node_group_name text DEFAULT NULL)
ローカルノードで無効になったコンセンサスワーカーを再度有効にします。
node_group_name
パラメーターは、インターフェイスの一貫性のために受け入れられますが、現在プレースホルダーです。このファンクションは、データベース全体でコンセンサスワーカーを再度有効にし、渡された値に関係なく、ノード上のすべてのRaftインスタンスに影響を与えます。
bdr.consensus_proto_version#
ローカルノードが現在使用しているコンセンサスプロトコルのバージョンを返します。
PGDグループの再構成の内部メカニズムに必要です。
bdr.consensus_snapshot_export#
概要#
bdr.consensus_snapshot_export(version integer DEFAULT NULL, raft_instance_id integer DEFAULT NULL)
ローカルノードの現在コミットおよび適用された状態から新しいPGDコンセンサススナップショットを生成し、byteaとして結果ます。
デフォルトでは、サポートされている最新のRaftバージョンのスナップショットがエクスポートされます。ただし、明示的なversion
番号を渡すことにより、それをオーバーライドできます。
raft_instance_id
パラメーターは、スナップショットをエクスポートするRaftインスタンスを識別します。
NULL
デフォルトの場合、トップレベルのRaftインスタンスが使用されます。特定のノードグループのRaftインスタンスをターゲットにするには、そのインスタンスIDを渡します。これは、
bdr.raft_instances を介してルックアップできます。
エクスポートするノードは現在の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 /var/lib/postgresql/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, raft_instance_id integer DEFAULT NULL, node_name bdr.regnode DEFAULT NULL)
bdr.consensus_snapshot_export()
によって、通常は同じPGDノードグループ内の別のノードからエクスポートされたコンセンサススナップショットをインポートします。
別のノード上のbdr.local_consensus_snapshot
テーブルのsnapshot
フィールドから直接抽出されたスナップショットを使用することもできます。
この機能は、破損またはユーザーエラーが発生した場合に、PGDノードのカタログ状態を既知の良好な状態にリセットするのに役立ちます。
raft_instance_id
パラメーターは、スナップショットをインポートするRaftインスタンスを指定します。
NULL
デフォルトの場合、トップレベルのRaftインスタンスが使用されます。特定のノードグループのRaftインスタンスをターゲットにするには、そのインスタンスIDを渡します。これは、
bdr.raft_instances を介してルックアップできます。
node_name
パラメーターは、スナップショットを特定のソースノード、通常はスナップショットがエクスポートされたリーダーノードに関連付けます。
NULL デフォルトの場合、ソースノードは属性されません。
スナップショットが生成されたときに、インポートノードの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.transfer_all_leaderships#
ローカルノードが現在書き込みまたはRaftリーダーシップを保持しているすべてのグループで、書き込みおよびRaftリーダーシップをローカルノードから移転します。この機能を使用して、ノードをオフラインにする前に、ノードからすべてのリーダーシップをドレインします。
概要#
bdr.transfer_all_leaderships(writeleader_timeout interval DEFAULT 10s)
パラメーター#
Name |
Type |
Default |
Description |
|---|---|---|---|
writeleader_timeout |
interval |
'10s' |
各書き込みリーダーシップ転送のタイムアウト。書き込みリーダーは自動選択され、このタイムアウトに到達するまで再試行されます。 |
戻り値#
すべての転送が成功した場合、またはノードがリーダーシップを保持していない場合はtrue
を返し、書き込みリーダー転送がタイムアウトした場合はfalse
を返します。
書き込みリーダー転送がタイムアウトすると、ファンクションは残りの書き込みリーダーとRaft転送の処理を継続し、ベストエフォートベースで、他の転送が成功した場合でもfalse
を結果ます。 Raft転送は、 statement_timeout
構成パラメーターを尊重して、リーダーシップが変更されるか、クエリがキャンセルされるまで、無期限に再試行されます。
ファンクションはbdr.routing_leadership_transfer
およびbdr.raft_leadership_transfer
とロジックを共有し、1回の呼び出しで両方の操作を完了して、結果が速くなります。
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
なしで変更をスキップすることが可能であるため、これは便利なファンクションです。論理デコードにおけるある種のエラーをバイパスする場合がありますが、より速いスキップを行います。
この機能は、無効になっているサブスクリプションでのみ動作します。
通常の手順のシーケンスは次のとおりです。
問題のあるサブスクリプションと問題のあるコミットのLSNを特定します。
サブスクリプションを無効にします。
可能であれば、ソースノードで
pg_catalog.pg_logical_slot_peek_changesを使用してトランザクションのコピーを保存します。ターゲットノード上の
bdr.alter_subscription_skip_changes_upto。必要に応じて、修復または同等の変更をターゲットに手動で適用します。
サブスクリプションを再度有効にします。
警告
このファンクションを使用すると、問題を悪化させるのは簡単です。それが唯一のオプションであると確信できない限り、何もしないでください。
概要#
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);
bdr.connection_manager_refresh_pools#
このファンクションは、 PGD接続マネージャーに接続プールを更新するように指示します。
この機能は、他のツールとの統合、または接続プールの即時の再評価が必要な場合に役立ちます。この機能はローカルノードでのみ動作します。クラスター全体の接続マネージャーを更新するには、各ノードでファンクションを個別に実行する必要があります。実行にはbdr_superuser
ロールが必要です。コメントを展開する コメント オンラインR861解決済み
概要#
SELECT bdr.connection_manager_refresh_pools();
注釈
このファンクションは、ルーティングの変更が検出された場合たとえば、書き込みリーダーの変更、ルーティングターゲットからのノードの追加/削除、またはコンセンサスが失われた場合、既存のクライアント接続を終了する場合があります。
bdr.get_node_sub_apply_lsn#
サブスクライバーでこのファンクションを使用して、特定のオリジンから受信および適用された最後のLSNを取得できます。
概要#
bdr.get_node_sub_apply_lsn(node_name name)
パラメーター#
Parameter |
Description |
|---|---|
node_name |
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.global_lock_table#
このファンクションは、指定されたテーブルのグローバルDMLロックを取得します。 DDL locking details を参照
グローバルDMLロックの詳細については、
概要#
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
特権が必要です。
例#
pgddb=# SELECT bdr.local_group_slot_name();
local_group_slot_name
- ----------------------
bdr_pgddb_bdrgroup
bdr.group_lease_override#
ノードグループのリース所有権を手動で譲渡またはキャンセルします。通常の動作条件では、 PGDノードはリースを自動的に転送します。ただし、リース所有者がクラッシュ、停止、またはコンセンサスから切断された場合、他のノードは、現在のリースの有効期限が切れるまでリースを取得できません。このファンクションは、その待機期間をバイパスします。
危険
このファンクションは、以前のリース所有者がリソースにアクセスしていないことが確実な場合にのみ使用します。たとえば、古いリーダーがコンセンサスから切断されているがまだアクティブなときに分析リースを手動で転送すると、両方のノードが同じストアに書き込み、データの重複が発生する可能性があります。
パラメーター#
bdr.local_group_slot_name#
ローカルノードのグループスロットの名前を返します。
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.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_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.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.stat_reset#
指定されたカテゴリの統計をリセットします。このファンクションを実行すると、
bdr.stat_reconcile_commit_scope ビューのstats_reset 列の値がクリアされます。
bdr_superuser 権限が必要です。
パラメーター#
Parameter |
Description |
|---|---|
stats_tupe |
リセットする統計のカテゴリ。有効な値は`commit_scope`および`reconcile_commit_scope`です。 `NULL`の場合、ファンクションのデフォルトは`commit_scope`になります。 |
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.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.wait_node_confirm_lsn#
ノードが特定のLSNを通過するまで待機します。
この機能を使用すると、このセッションの最後の書き込みが1つまたはすべてのノードで再生されるまで待機できます。
ファンクションは、呼び出されると、ノードが特定のLSNを渡すのを待機します。
LSNが指定されない場合、現在のwal_flush_lsn
pg_current_wal_flush_lsn()
ファンクションを使用しての位置がローカルノードで使用されます。ノード名パラメーターを指定すると、そのノードがLSNを渡すのを待機するようにファンクションに指示します。ノード名がNULLを渡すことにより指定されない場合、ファンクションはすべてのノードがLSNを渡すまで待機します。
Optimizing subscriber-only groups を使用している場合、このファンクションの使用をお勧めします
bdr.wait_slot_confirm_lsn の代わりに
。
これは、最適化されたトポロジでは、すべてのノードにレプリケーションスロットがあるわけではないため、ファンクション
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_slot_confirm_lsn#
このセッションの最後の書き込みが1つまたはすべてのノードで再生されるまで待機できます。
スロットが特定のLSNを通過するまで待機します。位置が指定されない場合、現在の書き込み位置がローカルノードで使用されます。
スロット名が渡されない場合、すべてのPGDスロットがLSNを通過するまで待機します。
ファンクションは、他のノードからの変更を1000ミリ秒ごとにポーリングします。
スロットが同時にドロップされた場合、そのスロットの待機は終了します。ノードが現在ダウンしており、スロットを更新していない場合、待機は継続されます。その場合、
statement_timeout をより早く完了するように設定することができます。
Optimizing subscriber-only groups を使用している場合
、 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を使用します。 |
グローバルアドバイザリーロック#
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グループスロットを除くすべてのレプリケーションスロットを考慮したローカルチェックを提供します。
この機能は、 Optimizing subscriber-only groups が有効になっているときに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.ts_metrics#
このファンクションは、登録されたすべての時系列メトリック定義をリストします。
PGD Monitorは、このレジストリを使用して、 SQL、そのREST API、Web
UI、およびPrometheus /metrics
エンドポイント全体で同じメトリック名と説明を与えます。
概要#
bdr.ts_metrics()
出力列#
Column name |
Description |
|---|---|
metric_id |
メトリックの内部数値識別子。 |
metric_name |
メトリックの名前。同じ名前は、REST API、Web UI、およびPrometheus `/metrics`エンドポイントで使用されます。 |
kind |
メトリックの種類、gauge`または`histogram。 |
value_type |
サンプリング値の保存に使用されるタイプ int8`または`float8。 |
display_kind |
PGD Monitor Web UIチャートが、より粗い時間範囲平均、最小/最大バンドを使用した平均、最小、または最大にズームアウトしたときにメトリックを要約する方法。 |
unit |
メトリックの単位たとえば、バイト、パーセント、秒。 |
description |
メトリックの説明。 |
注#
bdr_superuser 、bdr_read_all_stats 、またはbdr_monitor
メンバーシップを持つロールによって実行可能。
Monitoring metrics reference を参照
登録されたメトリックの完全なリストの場合は、 Using the PGD Monitor それらを公開するインターフェイスの場合。
bdr.ts_latest#
このファンクションは、名前付けの時系列メトリックの最新のサンプリング値を読み取ります。
概要#
bdr.ts_latest(metric_name text)
パラメーター#
Parameter |
Description |
|---|---|
metric_name |
`bdr.ts_metrics()`からの`metric_name`値と一致する、読み取るメトリック。 |
出力列#
Column name |
Description |
|---|---|
ts |
サンプルのタイムスタンプ。 |
value_int |
メトリックの`value_type`が`int8`の場合のサンプリング値。 |
value_float |
メトリックの`value_type`が`float8`の場合のサンプリング値。 |
注#
bdr_superuser 、bdr_read_all_stats 、またはbdr_monitor
メンバーシップを持つロールによって実行可能。
bdr.ts_errors#
このファンクションは、時系列エラーリングバッファによってキャプチャされた最近のエラーを読み取ります。これは、PGD Monitor Web UIのError Logページをサポートします。
概要#
bdr.ts_errors(max_entries int DEFAULT 50)
パラメーター#
Parameter |
Description |
|---|---|
max_entries |
返されるエラーエントリの最大数。デフォルト50 |
出力列#
Column name |
Description |
|---|---|
ts |
エラーのタイムスタンプ。 |
sqlerrcode |
エラーのSQLSTATEコード。 |
message |
エラーメッセージ。 |
detail |
エラーの追加の詳細がある場合。 |
注#
bdr_superuser 、bdr_read_all_stats 、またはbdr_monitor
メンバーシップを持つロールによって実行可能。
bdr.ts_samples#
このファンクションは、モニタのバックグラウンドワーカーからIPCを介して取得された、特定のダウンサンプリング周波数レベルでメトリックの履歴時系列サンプルを読み取ります。 PGD Monitor Web UIの時系列チャートをバックアップします。
概要#
bdr.ts_samples(metric_name text, level int DEFAULT 0)
パラメーター#
Parameter |
Description |
|---|---|
metric_name |
`bdr.ts_metrics()`からの`metric_name`値と一致する、読み取るメトリック。 |
level |
0 最も細かい 4 最も粗いまでのダウンサンプリング周波数レベル。デフォルト`0` |
出力列#
Column name |
Description |
|---|---|
ts |
サンプルのタイムスタンプ。 |
value |
サンプリング値、またはダウンサンプリングされたウィンドウの平均値。 |
min |
ダウンサンプリングされたウィンドウの場合、サンプルウィンドウの最小値。 |
max |
ダウンサンプリングされたウィンドウのサンプルウィンドウの最大値。 |
注#
bdr_superuser 、bdr_read_all_stats 、またはbdr_monitor
メンバーシップを持つロールによって実行可能。
bdr.ts_histogram#
pgd_commit_latency_milliseconds
などのヒストグラム種類のメトリックの場合、このファンクションは、指定されたダウンサンプリング周波数レベルでパーセンタイルサマリーp50、p90、p99を読み取ります。
概要#
bdr.ts_histogram(metric_name text, level int DEFAULT 3)
パラメーター#
Parameter |
Description |
|---|---|
metric_name |
読み取るヒストグラムメトリック。`bdr.ts_metrics()`からの`metric_name`値と一致します。 |
level |
読み取るダウンサンプリング周波数レベル、3`から`4`まで。デフォルト`3 |
出力列#
Column name |
Description |
|---|---|
ts |
サンプルウィンドウのタイムスタンプ。 |
p50 |
ウィンドウ内の50パーセンタイル値。 |
p90 |
ウィンドウ内の90パーセンタイル値。 |
p99 |
ウィンドウ内の99パーセンタイル値。 |
count |
ウィンドウ内の観測値の数。 |
sum |
ウィンドウ内の観測値の合計。 |
overflow_count |
ヒストグラムの最大バケット境界を超えた観測値。 |
注#
bdr_superuser 、bdr_read_all_stats 、またはbdr_monitor
メンバーシップを持つロールによって実行可能。
bdr.ts_histogram_distribution#
ヒストグラム種類のメトリックの場合、このファンクションは、特定のダウンサンプリング周波数レベルですべてのサンプルにわたって集計されたバケットごとの観測数を結果ます。
概要#
bdr.ts_histogram_distribution(metric_name text, level int DEFAULT 3)
パラメーター#
Parameter |
Description |
|---|---|
metric_name |
読み取るヒストグラムメトリック。`bdr.ts_metrics()`からの`metric_name`値と一致します。 |
level |
読み取るダウンサンプリング周波数レベル、3`から`4`まで。デフォルト`3 |
出力列#
Column name |
Description |
|---|---|
bucket_upper_ms |
バケットの上限ミリ秒単位。 |
count |
バケット内の観測値の数。 |
注#
bdr_superuser 、bdr_read_all_stats 、またはbdr_monitor
メンバーシップを持つロールによって実行可能。
bdr.ts_histogram_cumulative#
ヒストグラム種類のメトリックの場合、このファンクションは、+Inf
で終わるバケット境界ごとに1行の累積以降開始バケットカウンターを結果ます。これは、Prometheusヒストグラムが公開する_bucket
、_sum 、および_count シリーズと同等のSQLです。
概要#
bdr.ts_histogram_cumulative(metric_name text)
パラメーター#
Parameter |
Description |
|---|---|
metric_name |
読み取るヒストグラムメトリック。`bdr.ts_metrics()`からの`metric_name`値と一致します。 |
出力列#
Column name |
Description |
|---|---|
bucket_le_ms |
ミリ秒単位のバケット境界バケットは、この境界以下の値をカバーします。 |
cumulative_count |
境界またはそれ以下の観測値の累積数。 |
sum_ms |
すべての観測値のミリ秒単位の合計。 |
total_count |
すべてのバケットの観測値の合計数。 |
注#
bdr_superuser 、bdr_read_all_stats 、またはbdr_monitor
メンバーシップを持つロールによって実行可能。バケットは累積モノトーンカウンターであり、PromQLで予想される規則histogram_quantile()
およびrate() と一致します。
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#
ルーティングリーダーを変更すると、ノードグループのリーダーシップが別のノードに転送されます。
leader_name がNULL
の場合、システムは書き込みリーダーの進行状況に基づいて、最も適切なノードを自動的に選択します。
概要#
bdr.routing_leadership_transfer(node_group_name text,
leader_name text DEFAULT NULL,
transfer_method text DEFAULT strict,
transfer_timeout interval DEFAULT 10s);
パラメーター#
Name |
Type |
Default |
Description |
|---|---|---|---|
node_group_name |
text |
リーダーシップの譲渡が要求されたグループの名前。 |
|
leader_name |
text |
NULL |
書き込みリーダーになるノードの名前。 NULLの場合、システムは書き込みリーダーの進行状況に基づいて、最も適切な候補を自動的に選択します。 |
transfer_method |
text |
'strict' |
転送の種類。 'fast'`またはデフォルトの'strict'`で、最大遅延をチェックします。 |
transfer_timeout |
interval |
'10s' |
リーダーシップ転送のタイムアウト。デフォルトは10秒です。自動選択を使用する場合 `leader_name`がNULLの場合、システムはタイムアウトに達するまで、最も進行しているノードの選択を再試行します。 |
注#
leader_name がNULL
の場合、ファンクションは、書き込みリーダーが最も遠いノードを特定し、適切な候補が利用できるかタイムアウトに到達するまで選択を再試行することにより、最適な候補ノードを選択します。自動選択は、手動ノード選択が必要ない自動フェイルオーバーシナリオに役立ちます。コミットスコープ種類としてクォーラムコミットを使用する場合、
leader_name にNULL
を渡して、最も適切なノードの自動選択をトリガーします。
候補者の自動選択#
自動リーダー選択時 leader_name がNULL の場合
ルートフェンスされたノード bdr.alter_node_option を介して
route_fenceが有効になっているノード は、リーダーシップ譲渡の候補とは見なされません。route_writesがfalseに設定されているノードは、リーダーシップ移行の候補とは見なされません。route_priorityオプションは自動選択に影響を与えません。選択は、適格ノード間の書き込みリーダーの進行状況にのみ基づいて行われます。
混合バージョンのクラスターでの実行#
自動リーダー選択leader_name のNULL を渡すには、PGD
6.4およびRaftプロトコルバージョン6004以上が必要です。
4より前のノードでファンクションを呼び出すと、古いファンクションシグネチャでは非
NULLleader_nameパラメーターが必要であるため、ファンクションはアクションを実行せずに終了します。4ノードでファンクションを呼び出す場合、動作はRaftプロトコルバージョンによって異なります。
Raftプロトコルバージョンが6004未満で、PGD 6.4以上のノードがRaftリーダーである場合、ファンクションは
ERROR: leadership auto transfer is supported from raft protocol version 6004 and aboveを結果ます。6.4より前のノードがRaftリーダーの場合、オペレーションはタイムアウトし、
ERROR: switchover timed outを結果ます。
信頼性の高い自動リーダー選択を行うには、クラスター内のすべてのノードがRaftプロトコルバージョン6004以上でPGD 6.4以降を実行していることを確認します。
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 を使用してください。以前は、このファンクションはノードグループからコミットスコープを削除するために使用されていました。現在は非推奨であり、将来のリリースで削除されるまで警告を発し、その時点でエラーが発生します。
エラーポリシーファンクションの適用#
これらの機能を使用すると、適用エラーポリシーによって記録されたレプリケーション障害を確認、解決、および分析できます。構成の詳細については、
bdr.alter_node_group_option()を使用したグループ構成 のapply_error_policy 、apply_error_max_retries
、apply_error_max_skips 、およびapply_error_max_record_size
オプションを参照してください。ポリシーの構成と障害を解決するためのステップバイステップガイドについては、
Handling replication apply errors を参照してください。
bdr.skip_failed_change#
bdr.pending_failed_changes
でキャプチャされた単一の変更をスキップしたとしてマーキングします。変更ステータスはskipped
に更新されますが、行は削除されません。
概要#
bdr.skip_failed_change(change_id bigint)
パラメーター#
Parameter |
Description |
|---|---|
change_id |
`bdr.pending_failed_changes`のスキップする行の主キー。 |
bdr.skip_failed_transaction#
失敗したトランザクション内のすべての保留中の変更をスキップとしてマークし、オプションでサブスクリプションを再度有効にします。
概要#
bdr.skip_failed_transaction(
subscription_name name,
remote_xid xid,
remote_commit_lsn pg_lsn,
dry_run boolean DEFAULT false,
re_enable boolean DEFAULT false
)
bdr.skip_failed_transaction(
failed_txn_id uuid,
dry_run boolean DEFAULT false,
re_enable boolean DEFAULT false
)
パラメーター#
Parameter |
Description |
|---|---|
subscription_name |
サブスクリプションの名前。 |
remote_xid |
元ノードのトランザクションID。 |
remote_commit_lsn |
元ノードで失敗したトランザクションのコミットLSN。 |
failed_txn_id |
bdr.pending_failed_changes`からの失敗したトランザクションのUUID。 `subscription_name、remote_xid、および`remote_commit_lsn`を指定するための便利な代替として使用します。 |
dry_run |
`true`の場合、何も変更せずにスキップされる変更の数を結果ます。デフォルトは`false`です。 |
re_enable |
`true`の場合、スキップした後にサブスクリプションを再度有効にします。デフォルトは`false`です。 |
戻り値#
スキップされた変更の数を返します。トランザクションが既に解決されている場合、エラーは発生しない場合、
0 を返します。
bdr.apply_failed_change#
1つのキャプチャされた変更を適用して再試行します。
概要#
bdr.apply_failed_change(change_id bigint)
パラメーター#
Parameter |
Description |
|---|---|
change_id |
適用する`bdr.pending_failed_changes`の行の主キー。 |
bdr.apply_failed_transaction#
失敗したトランザクションの保留中の変更をすべて再試行します。デフォルトでドライランモードになるため、コミットする前に結果をプレビューできます。
概要#
bdr.apply_failed_transaction(
subscription_name name,
remote_xid xid,
remote_commit_lsn pg_lsn,
dry_run boolean DEFAULT true,
re_enable boolean DEFAULT false
)
bdr.apply_failed_transaction(
failed_txn_id uuid,
dry_run boolean DEFAULT true,
re_enable boolean DEFAULT false
)
パラメーター#
Parameter |
Description |
|---|---|
subscription_name |
サブスクリプションの名前。 |
remote_xid |
元ノードのトランザクションID。 |
remote_commit_lsn |
元ノードで失敗したトランザクションのコミットLSN。 |
failed_txn_id |
bdr.pending_failed_changes`からの失敗したトランザクションのUUID。 `subscription_name、remote_xid、および`remote_commit_lsn`を指定するための便利な代替として使用します。 |
dry_run |
`true`デフォルトの場合、実際に変更を適用せずに何が起こるかを示します最後にロールバックします。 `false`を渡して実行します。 |
re_enable |
`true`および`dry_run`が`false`の場合、適用後にサブスクリプションを再度有効にします。デフォルトは`false`です。 |
戻り値#
次の列を使用して、変更ごとに1行を結果ます。
Column |
Type |
Description |
|---|---|---|
change_num |
integer |
トランザクション内の変更の順序。 |
change_id |
bigint |
`bdr.pending_failed_changes`の行の主キー。 |
operation |
text |
操作タイプ INSERT、UPDATE、DELETE、SQL、DDL、または`TRUNCATE` |
schema_name |
text |
ターゲットテーブルのスキーマ。 |
table_name |
text |
ターゲットテーブルの名前。 |
status |
text |
適用試行の結果。 Dry-runモードでは、値は`would_apply`、would_skip、または`would_error`です。実行時の値は`apply`、skip、または`error`です。 |
message |
text |
変更が失敗した場合はエラーメッセージ、成功した場合は`NULL`。 |
適用中にエラーが発生した場合、ファンクションは、失敗した変更を含むすべての変更の結果を返します。トランザクションが既に解決されている場合、ファンクションはエラーを発生させずに0行を返します。
bdr.modify_failed_change#
変更を再試行する前に、キャプチャされた単一の変更の列値を編集します。
bdr.pending_failed_changes のmodified_values
列を更新し、変更ステータスをmodified に設定します。
概要#
bdr.modify_failed_change(change_id bigint, new_values jsonb)
パラメーター#
Parameter |
Description |
|---|---|
change_id |
変更する`bdr.pending_failed_changes`の行の主キー。 |
new_values |
変更が再試行されたときに使用する更新された列値を含むJSONBオブジェクト。 |
bdr.reconstruct_change_sql#
キャプチャされた単一の変更の実行可能SQLを生成します。
bdr.pending_failed_changes_sql
ビューは、このファンクションを内部で使用します。
概要#
bdr.reconstruct_change_sql(
operation text,
schema_name name,
table_name name,
key_columns jsonb,
old_values jsonb,
new_values jsonb
)
パラメーター#
Parameter |
Description |
|---|---|
operation |
操作タイプ。有効な値は`INSERT`、UPDATE、DELETE、SQL、DDL、および`TRUNCATE`です。 |
schema_name |
ターゲットテーブルのスキーマ。 |
table_name |
ターゲットテーブルの名前。 |
key_columns |
主キー列値を含むJSONBオブジェクト。 |
old_values |
`UPDATE`および`DELETE`操作に使用される、ビフォアイメージ列値を含むJSONBオブジェクト。 |
new_values |
`INSERT`および`UPDATE`操作のafter-image列値、または`DDL`および`SQL`操作のSQLテキストを含むJSONBオブジェクト。 |
戻り値#
再構成されたSQLステートメントを含むtext
文字列を結果ます。元の実行中に検索パスが有効であった場合、 DDL操作には
SET search_path 接頭辞が含まれます。
bdr.reconstruct_failed_transaction#
失敗したトランザクションでキャプチャされたすべての変更を対象に、BEGIN
およびCOMMIT でラップされた完全なSQLスクリプトを生成します。
概要#
bdr.reconstruct_failed_transaction(
subscription_name name,
remote_xid xid,
remote_commit_lsn pg_lsn
)
bdr.reconstruct_failed_transaction(failed_txn_id uuid)
パラメーター#
Parameter |
Description |
|---|---|
subscription_name |
サブスクリプションの名前。 |
remote_xid |
元ノードのトランザクションID。 |
remote_commit_lsn |
元ノードで失敗したトランザクションのコミットLSN。 |
failed_txn_id |
bdr.pending_failed_changes`からの失敗したトランザクションのUUID。 `subscription_name、remote_xid、および`remote_commit_lsn`を指定するための便利な代替として使用します。 |
戻り値#
トランザクション内のすべての変更を含むtext
SQLスクリプトを結果ます。スクリプトを使用して、完全なトランザクションを確認または手動で再生します。
bdr.resolve_failed_transaction#
失敗したトランザクションのすべての保留中の変更を解決済みとしてマークし、失敗したトランザクションを超えてサブスクリプションのポジションを進め、オプションでサブスクリプションを再度有効にします。デフォルトでドライランモードになるため、コミットする前に結果をプレビューできます。
概要#
bdr.resolve_failed_transaction(
subscription_name name,
remote_xid xid,
remote_commit_lsn pg_lsn,
resolution text DEFAULT skipped,
re_enable boolean DEFAULT false,
dry_run boolean DEFAULT true
)
bdr.resolve_failed_transaction(
failed_txn_id uuid,
resolution text DEFAULT skipped,
re_enable boolean DEFAULT false,
dry_run boolean DEFAULT true
)
パラメーター#
Parameter |
Description |
|---|---|
subscription_name |
サブスクリプションの名前。 |
remote_xid |
元ノードのトランザクションID。 |
remote_commit_lsn |
元ノードで失敗したトランザクションのコミットLSN。 |
failed_txn_id |
bdr.pending_failed_changes`からの失敗したトランザクションのUUID。 `subscription_name、remote_xid、および`remote_commit_lsn`を指定するための便利な代替として使用します。 |
resolution |
適用する解決アクション。有効な値は`skipped`、applied、および`discarded`です。デフォルトは`skipped`です。 |
re_enable |
`true`の場合、解決後にサブスクリプションを再度有効にします。デフォルトは`false`です。 |
dry_run |
`true`デフォルトの場合、変更を加えずにオペレーションが何を行うかの詳細なプレビューを結果ます。 `false`を渡して実行します。 |
戻り値#
ドライランモードでは、計画的な変更を説明するtext
レポートを結果ます。 dry_run がfalse
の場合、適用された解像度のtext 確認を結果ます。
注#
このファンクションを呼び出すと、概要レコードがbdr.resolved_transactions
に挿入されます。解決したら、 bdr.pending_failed_changes
を切り詰めて、解決の履歴を保持しながら領域を再利用できます。
トランザクションが既に解決されている場合、ファンクションは以前の解決に関する詳細を記載したエラーを発生させます。
bdr.analyze_skip_impact#
単一のキャプチャされた変更をスキップした場合の安全性と潜在的なデータへの影響を分析します。エラータイプ、操作、およびオプションで現在のローカルデータベースの状態に基づいて、リスク評価を結果ます。
概要#
bdr.analyze_skip_impact(
change_id bigint,
verify_state boolean DEFAULT true,
include_transaction_analysis boolean DEFAULT true
)
パラメーター#
Parameter |
Description |
|---|---|
change_id |
分析する`bdr.pending_failed_changes`の行の主キー。 |
verify_state |
true`デフォルトの場合、安全性を評価する前にローカルデータベースを照会して現在の状態を確認します。エラーコードと操作タイプのみに基づいて、より高速な静的分析を行うには `false を渡します。 |
include_transaction_analysis |
`true`デフォルトの場合、同じトランザクション内の他のすべての変更を調べて、依存関係を検出し、警告を生成します。 |
戻り値#
次の列を含む行を結果ます。
Column |
Type |
Description |
|---|---|---|
skip_safety |
text |
安全性分類 safe、caution、または`risky` |
recommendation |
text |
人間が読める推奨事項。 |
explanation |
text |
エラーコンテキストと状態検証結果を含む詳細な説明。 |
data_impact |
text |
データインパクトレベル none、possible_divergence、または`certain_divergence`。 |
suggested_action |
text |
推奨されるアクション skip、apply_modified、または`manual_review`。 |
dependency_warnings |
text[] |
影響を受けるトランザクションの関連変更に関する警告の配列、またはない場合は`NULL`。 |
安全分類#
Safety |
Description |
|---|---|
safe |
変更をスキップしても、ノード間でデータの相違が発生する可能性は低いです。 |
caution |
軽微な潜在的な問題が存在します。スキップする前に変更を確認します。 |
risky |
変更をスキップすると、ノード間でデータの相違が発生する可能性があります。 |
bdr.analyze_transaction_skip_impact#
失敗したトランザクションの保留中のすべての変更のスキップ安全性を分析し、変更ごとに1行を結果ます。
概要#
bdr.analyze_transaction_skip_impact(
subscription_name name,
remote_xid xid,
remote_commit_lsn pg_lsn
)
パラメーター#
Parameter |
Description |
|---|---|
subscription_name |
サブスクリプションの名前。 |
remote_xid |
元ノードのトランザクションID。 |
remote_commit_lsn |
元ノードで失敗したトランザクションのコミットLSN。 |
戻り値#
トランザクション内の変更ごとに1行、次の列を返します。
Column |
Type |
Description |
|---|---|---|
change_seq |
integer |
トランザクション内の変更の順序。 |
operation |
text |
操作タイプ INSERT、UPDATE、DELETE、SQL、DDL、または`TRUNCATE` |
qualified_table |
text |
スキーマ修飾テーブル名。 |
skip_safety |
text |
安全性分類 safe、caution、または`risky` |
recommendation |
text |
人間が読める変更の推奨事項。 |
has_dependents |
boolean |
トランザクションの他の変更がこの変更の結果によって異なるかどうか。 |
bdr.format_skip_anarise#
キャプチャされた単一の変更のスキップセーフティのフォーマット化された人間が判読可能な分析を結果ます。
概要#
bdr.format_skip_analysis(change_id bigint)
パラメーター#
Parameter |
Description |
|---|---|
change_id |
分析する`bdr.pending_failed_changes`の行の主キー。 |
戻り値#
安全性分類、推奨事項、説明、および状態検証結果を含むtext
レポートを返します。
bdr.alter_subscription_reset_error_counters#
サブスクリプションのエラーリトライおよびスキップカウンターを初期値にリセットします。レプリケーション障害を解決した後にリセットを使用して、サブスクリプションのエラーポリシーしきい値を新しく適用できるようにします。
概要#
bdr.alter_subscription_reset_error_counters(subscription_name name)
パラメーター#
Parameter |
Description |
|---|---|
subscription_name |
サブスクリプションの名前。 |