BDR System Functions¶
BDR管理は、主にSQL呼び出し可能な関数を介して実行されます。
BDRのすべての機能はbdr
スキーマで公開されています。これらの関数への呼び出しは、 search_path
にbdr を置くのではなく、スキーマ修飾する必要があります。
このページには、文書の他のセクションで説明されていない追加のシステム機能が含まれています。
バージョン情報Functions¶
bdr.bdr_version¶
このファンクションは、現在使用されているBDRバージョンのテキスト表現形式を取得します。
bdr.bdr_version_num¶
このファンクションは、現在使用されているBDRバージョンの数値表現形式を取得します。バージョン番号は単調に増加するため、この値を小なりと大なりの比較に使用できます。
次の式は、メジャーバージョン、マイナーバージョン、およびパッチリリースで構成されるバージョン番号を単一の数値に変換するために使用されます。
MAJOR_VERSION * 10000 + MINOR_VERSION * 100 + PATCH_RELEASE
システム情報Functions¶
bdr.get_relation_stats¶
リレーション情報を返します。
bdr.get_subscription_stats¶
現在のサブスクリプション統計を返します。
システムと進行状況の情報パラメーター¶
BDRは、 psql のSHOW
を介して、またはクライアントアプリケーションからPQparameterStatus
(または同等の)を使用して照会できるいくつかのパラメーターを公開します。このセクションでは、
BDRがレポートするそのようなすべてのパラメータをリストします。
bdr.local_node_id¶
セッションの初期化時に、これはクライアントが接続されているノードIDに設定されます。これにより、アプリケーションは透過プロキシの背後でも接続されているノードを把握できます。
- また、CAMOと組み合わせて使用されます。
Connection pools and proxies セクションを参照してください。
bdr.last_committed_lsn¶
非同期トランザクションの各 COMMIT
の後、このパラメータは更新されて、オリジンノードのコミットレコードの最後をポイントします。
bdr.wait_for_apply_queue
と組み合わせて、これにより、アプリケーションはマルチプルのノードにわたって因果読み取りを実行できます。つまり、トランザクションがリモートで可視になるまで待機できます。
transaction_id¶
CAMOが有効になっている場合、 PostgresがトランザクションIDを割り当てるとすぐにこのパラメータが更新され、割り当てられたトランザクションIDが表示されます。
コンセンサスファンクション¶
bdr.consensus_disable¶
サーバーをリスタートするまで、または bdr.consensus_enable
を使用して再度有効にするまで(どちらか早い方)、ローカルノードのコンセンサスワーカーを無効にします。
警告
コンセンサスを無効にするとBDRの一部の機能が無効になり、長期間無効のままにすると最終的にBDRクラスターの可用性にインパクトを与えます。このファンクションは、テクニカルサポートと連携してのみ使用してください。
bdr.consensus_enable¶
ローカルノードで無効になっているコンセンサスワーカーを再度有効にします。
bdr.consensus_proto_version¶
ローカルノードで現在使用されているコンセンサスプロトコルバージョンを返します。
BDRグループの再構成の内部メカニズムで必要です。
bdr.consensus_snapshot_export¶
概要¶
bdr.consensus_snapshot_export(version integer DEFAULT NULL)
ローカルノードの現在コミットして適用された状態から新しいBDRコンセンサスsnapshotを生成し、byteaとして結果ます。
デフォルトでは、サポートされている最も高いRaftバージョンのsnapshotがエクスポートされます。ただし、明示的な
version 番号を渡すことでオーバーライドできます。
エクスポートするノードは現在のRaftリーダーである必要はなく、リーダーの最新の状態で完全に最新である必要もありません。ただし、そのようなsnapshotはbdr.consensus_snapshot_import()
によって受け入れられない場合があります(以下を参照)。
新しいsnapshotは、ローカルノードのbdr.local_consensus_snapshot
テーブルに自動的に保存されません。呼び出し元にのみ返されます。
生成されたsnapshotは、エクスポートノードのログ位置の後ろにある同じBDRノードグループ内の他のノードのbdr.consensus_snapshot_import()
に渡すことができます。
このファンクションを動作させるには、ローカルBDRコンセンサスワーカーを無効にする必要があります。典型的な使用法は次のとおりです。
SELECT bdr.bdr_consensus_disable();
\copy (SELECT * FROM bdr.consensus_snapshot_export()) TO my_node_consensus_snapshot.data
SELECT bdr.bdr_consensus_enable();
BDRコンセンサスワーカーが無効になっている間、ノードでのDDLロックの試行は失敗するかタイムアウトになり、gallocシーケンスは新しい値を取得せず、EagerおよびCAMOトランザクションは一時停止またはERRORになり、分散コンセンサスシステムをニーズとする他の機能が中断されます。必要なダウンタイムは一般的に非常に短いです。
ユースケースによっては、 bdr.local_consensus_snapshot
テーブルのsnapshot
フィールドから既に存在するsnapshotを抽出して、代わりに使用する方が実用的な場合があります。これを行うために、コンセンサスワーカーを停止する必要はありません。
bdr.consensus_snapshot_import¶
概要¶
bdr.consensus_snapshot_import(IN snapshot bytea)
通常は同じBDRノードグループ内の別のノードから、
bdr.consensus_snapshot_export()
によってエクスポートされたコンセンサスsnapshotをインポートします。
別のノードにある bdr.local_consensus_snapshot テーブルの
snapshot
フィールドから直接抽出したsnapshotを使用することもできます。
このファンクションは、破損またはユーザの間違いが発生した場合に、 BDRノードのカタログの状態を既知の良好な状態にリセットするのに役立ちます。
snapshotsnapshotが生成された時点でインポートノードのapply_index
がスナップショットをエクスポートするノードのcommit_index
以下である場合、スナップショットをインポートできます。
bdr.get_raft_status()
を参照してください。ログが既に先にあるためにsnapshotを受け入れることができないノードは、
ERROR
を発生させます。snapshotがインポートされると、ノードは現在のリーダーから残りの変更をフェッチするため、インポートされたsnapshotショットは完全に最新である必要はありません。
このファンクションを動作させるには、インポートするノードでBDRコンセンサスワーカーを無効にする必要があります。詳細については、
bdr.consensus_snapshot_export() のノートを参照してください。
次を実行して、これを使用してローカルノードに新しいRaftsnapshotを生成させることができます。
SELECT bdr.consensus_snapshot_import(bdr.consensus_snapshot_export());
これにより、現在適用されているログ位置までRaftログが切り捨てられる場合があります。
bdr.consensus_snapshot_verify¶
概要¶
bdr.consensus_snapshot_verify(IN snapshot bytea)
bdr.consensus_snapshot_export()
によってエクスポートされた指定されたコンセンサスsnapshotを確認します。snapshotヘッダーには、
が生成されたバージョンが含まれており、ノードは同じバージョンに対して検証しようとします。
snapshotは、同じノードまたはクラスター内の他のノードでエクスポートされた可能性があります。snapshotを検証するノードがエクスポートされたsnapshotのバージョンをサポートしていない場合、エラーが発生します。
bdr.get_consensus_status¶
現在のコンセンサス(Raft)ワーカーに関するステータス情報を返します。
bdr.get_raft_status¶
現在のコンセンサス(Raft)ワーカーに関するステータス情報を返します。
bdr.get_consensus_status のエイリアス。
bdr.raft_leadership_transfer¶
概要¶
bdr.raft_leadership_transfer(IN node_name text, IN wait_for_completion boolean)
node_name
で識別されるノードをRaftリーダーとして要求します。要求は任意のBDRノードから開始でき、指定されたノードにリーダーシップを転送するために現在のリーダーに内部的に転送されます。指定されたノードは、アクティブなBDRノードであり、完全な投票権を持つ必要があります。
wait_for_completion
がfalseの場合、要求はベストエフォートで処理されます。
bdr.raft_election_timeout
期間内にノードがリーダーになれない場合、他の有能なノードが再びリーダーになります。また、リーダーシップは
Raft プロトコルごとに期間にわたって変わる可能性があります。
trueが結果れる結果は、要求が正常に送信されたことのみを示します。
wait_for_completion がtrue
の場合、ファンクションは指定されたノードが新しいリーダーになるまで待機し、要求されたノードがRaftリーダーにならない場合(ネットワークの問題などにより)無限に待機します。したがって、無限ループを防ぐには、常にwait_for_completion
と組み合わせてstatement_timeout を設定することをお勧めします。
ユーティリティFunctions¶
bdr.wait_slot_confirm_lsn¶
ユーザは、このセッションの最後の書き込みが1つまたはすべてのノードで再生されるまで待機できます。
スロットが特定のLSNを渡すまで待機します。位置が指定されていない場合、ローカルノードで現在の書き込み位置が使用されます。
スロット名前が渡されない場合、すべてのBDRスロットがLSNを渡すまで待機します。
このファンクションは、他のノードからの変更を1000ミリ秒ごとにポーリングします。
スロットが同時にドロップされた場合、そのスロットの待機は終了します。ノードが現在ダウンしており、そのスロットを更新していない場合、待機は続行されます。その場合、
statement_timeout
をより早く完了するように設定することをお勧めします。
概要¶
bdr.wait_slot_confirm_lsn(slot_name text DEFAULT NULL, target_lsn pg_lsn DEFAULT NULL)
パラメーター¶
slot_name-レプリケーションスロットの名前、またはNULLの場合、すべてのBDRスロット(のみ)target_lsn-待機するLSN、またはNULLの場合はローカルノードで現在の書き込みLSNを使用します
bdr.wait_for_apply_queue¶
ファンクションbdr.wait_for_apply_queue を使用すると、
BDRノードは、特定のBDRノードから発生する特定のトランザクションのローカルアプリケーションを待機できます。その同等なからのすべてのトランザクションがローカルに適用された後にのみ結果れノード。アプリケーションまたはプロキシは、このファンクションを使用して、古い読み取りを防ぐことができます。
便宜上、 BDRは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)
パラメーター¶
ノード着信トランザクションがキューに入れられ、待機する必要がある同等なの名前。 NULLの場合、すべての同等なの適用キューが消費されるのを待ちます。
ノード - 待機する同等なからのレプリケーションストリーム内のLSN。通常、同等なから
bdr.last_committed_lsnを介して学習されノード。
bdr.get_node_sub_receive_lsn¶
このファンクションをサブスクライバーで使用して、指定されたオリジンから受信した最後のLSNを取得できます。適用するトランザクションに関連するLSNインクリメントのみをアカウントに入れるようにフィルター処理するか、フィルター処理しません。
このファンクションの出力と bdr.get_node_sub_apply_lsn()
の出力の差が、対応する適用キューのサイズを測定します。
概要¶
bdr.get_node_sub_receive_lsn(node_name name, committed bool default true)
パラメーター¶
node_name- LSNを取得するレプリケーションストリームのソースであるノードの名前/committed-デフォルト(true)では、このファンクションは最後のLSN全体ではなく、受信したトランザクションのコミットのみをアカウントします。サブスクライバーノードに影響を与えないアクションを含みます。
bdr.get_node_sub_apply_lsn¶
このファンクションをサブスクライバーで使用して、指定されたオリジンから受信および適用された最後のLSNを取得できます。
概要¶
bdr.get_node_sub_apply_lsn(node_name name)
パラメーター¶
node_name- LSNを取得するレプリケーションストリームのソースであるノードの名前。
bdr.run_on_all_nodes¶
すべてのノードでクエリーを実行するファンクション。
警告
このファンクションは、ノードのDSNで指定されたノード間接続に使用されるユーザの権限を使用して、リモートノードで任意のクエリーを実行します。このファンクションに権限を付与する場合は注意がニーズです。
概要¶
bdr.run_on_all_nodes(query text)
パラメーター¶
query- 実行される任意のクエリー。
注意事項¶
このファンクションは他のノードに接続してクエリーを実行し、各ノードからの結果をjsonフォーマットで返します。各ノードから複数の行が返され、json配列としてエンコードされます。ノードがダウンしているため接続できないなどのエラーが応答フィールドに表示されます。明示的な statement_timeout またはその他のランタイムパラメーターは設定されていないため、デフォルトが使用されます。
このファンクションは通常のレプリケーションを実行しません。既知のすべてのノードへの直接クライアント接続を使用します。デフォルトでは、コマンドは既にクラスター内のすべてのノードに送信されているため、 bdr.ddl_replication = offで接続が作成されます。
レプリケーションが中断され、ノード間の一貫性が失われるリスクがあるため、このファンクションを使用するときは注意してください。透過的なDDLレプリケーションまたは
bdr.replicate_ddl_command() を使用してDDLをレプリケートします。
DDLは将来のリリースでブロックされる可能性があります。
例¶
例、次のクエリーで、このファンクションをモニタリングで使用すると便利です。
SELECT bdr.run_on_all_nodes($$
SELECT local_slot_name, origin_name, target_name, replay_lag_size
FROM bdr.node_slots
WHERE origin_name IS NOT NULL
$$);
…2ノードクラスターでは次のようなものが結果れます。
[
{
"dsn": "host=node1 port=5432 dbname=bdrdb user=postgres ",
"node_id": "2232128708",
"response": {
"command_status": "SELECT 1",
"command_tuples": [
{
"origin_name": "node1",
"target_name": "node2",
"local_slot_name": "bdr_bdrdb_bdrgroup_node2",
"replay_lag_size": "0 bytes"
}
]
},
"node_name": "node1"
},
{
"dsn": "host=node2 port=5432 dbname=bdrdb user=postgres ",
"node_id": "2058684375",
"response": {
"command_status": "SELECT 1",
"command_tuples": [
{
"origin_name": "node2",
"target_name": "node1",
"local_slot_name": "bdr_bdrdb_bdrgroup_node1",
"replay_lag_size": "0 bytes"
}
]
},
"node_name": "node2"
}
]
bdr.run_on_nodes¶
指定されたノードのリストでクエリーを実行するファンクション。
警告
このファンクションは、ノードのDSNで指定されたノード間接続に使用されるユーザの権限を使用して、リモートノードで任意のクエリーを実行します。このファンクションに権限を付与する場合は注意がニーズです。
概要¶
bdr.run_on_nodes(node_names text[], query text)
パラメーター¶
node_names- textクエリーが実行されるノード名の配列。query- 実行される任意のクエリー。
注意事項¶
このファンクションは他のノードに接続してクエリーを実行し、各ノードからの結果をjsonフォーマットで返します。各ノードから複数の行が返され、json配列としてエンコードされます。ノードがダウンしているため接続できないなどのエラーが応答フィールドに表示されます。明示的な statement_timeout またはその他のランタイムパラメーターは設定されていないため、デフォルトが使用されます。
このファンクションは通常のレプリケーションを実行しません。既知のすべてのノードへの直接クライアント接続を使用します。デフォルトでは、コマンドは既にクラスター内のすべてのノードに送信されているため、 bdr.ddl_replication = offで接続が作成されます。
レプリケーションが中断され、ノード間の一貫性が失われるリスクがあるため、このファンクションを使用するときは注意してください。透過的なDDLレプリケーションまたは
bdr.replicate_ddl_command() を使用してDDLをレプリケートします。
DDLは将来のリリースでブロックされる可能性があります。
bdr.run_on_group¶
ノードのグループでクエリーを実行するファンクション。
警告
このファンクションは、ノードのDSNで指定されたノード間接続に使用されるユーザの特権で、リモートノードで任意のクエリーを実行します。このファンクションに権限を付与する場合は注意がニーズです。
概要¶
bdr.run_on_group(node_group_name text, query text)
パラメーター¶
node_group_name-クエリーが実行されるノードグループの名前。query- 実行される任意のクエリー。
注意事項¶
このファンクションは他のノードに接続してクエリーを実行し、各ノードからの結果をjsonフォーマットで返します。各ノードから複数の行が返され、json配列としてエンコードされます。ノードがダウンしているため接続できないなどのエラーが応答フィールドに表示されます。明示的な statement_timeout またはその他のランタイムパラメーターは設定されていないため、デフォルトが使用されます。
このファンクションは通常のレプリケーションを実行しません。既知のすべてのノードへの直接クライアント接続を使用します。デフォルトでは、コマンドは既にクラスター内のすべてのノードに送信されているため、 bdr.ddl_replication = offで接続が作成されます。
レプリケーションが中断され、ノード間の一貫性が失われるリスクがあるため、このファンクションを使用するときは注意してください。透過的なDDLレプリケーションまたは
bdr.replicate_ddl_command() を使用してDDLをレプリケートします。
DDLは将来のリリースでブロックされる可能性があります。
bdr.global_lock_table¶
- このファンクションは、指定されたテーブルのグローバルDMLロックを取得します。グローバルDMLロックについては、
DDLロックの詳細 を参照してください。
概要¶
bdr.global_lock_table(relation regclass)
パラメーター¶
relation- ロックされるリレーションの名前またはOID。
注意事項¶
このファンクションは、 ddl_locking
設定とは無関係にグローバルDMLロックを取得します。
bdr.global_lock_table ファンクションには、
bdr.backwards_compatibility
が30618以下に設定されている場合を除き、ロックされたrelation
に対するUPDATE 、DELETE 、またはTRUNCATE
権限が必要です。
bdr.wait_for_xid_progress¶
このファンクションを使用して、特定のノード(ノードIDで識別)で発生した特定のトランザクション(XIDで識別)がクラスターで十分に進行makeまで待機できます。進行状況は、ノードに適用されているトランザクションとして定義され、このノードはトランザクションが適用される前に行われた他のすべてのレプリケーション変更を確認します。
概要¶
bdr.wait_for_xid_progress(origin_node_id oid, origin_topxid int4, allnodes boolean DEFAULT true)
パラメーター¶
origin_node_id-トランザクションが発生したノードのノードID。origin_topxid-トランザクションのXID。allnodes-trueの場合、すべてのノードでトランザクションが進行するのを待ちます。それ以外の場合は、現在のノードのみを待ちます。
注意事項¶
現在、これらのトランザクションのみが追跡されているため、このファンクションはDDLコマンドをレプリケートしたトランザクションにのみ使用できます。間違った
origin_node_id または origin_topxid
が指定された場合、ファンクションは永久に、または statement_timeout
に到達するまで待機する場合があります。
bdr.local_group_slot_name¶
ローカルノードのグループスロットの名前を返します。
例¶
bdrdb=# SELECT bdr.local_group_slot_name();
local_group_slot_name
- ----------------------
bdr_bdrdb_bdrgroup
bdr.node_group_type¶
指定されたノードグループのタイプを返します。戻り値は、ノードグループの作成時にbdr.create_node_group()
に渡された値と同じですが、グループの作成時にnode_group_type
がNULLとして渡された場合にnormal が返されます。
例¶
bdrdb=# SELECT bdr.node_group_type(bdrgroup);
node_group_type
- ----------------
normal
グローバルアドバイザリロック¶
BDRは、グローバル勧告ロックをサポートしています。これらのロックは、 BDRがサポートする勧告ロックが本質的にグローバルであることを除いて、 PostgreSQLで利用可能な勧告ロックに非常に似ています。これらは、 DDLロックと同様のセマンティクスに従います。したがって、アドバイザリロックは多数決コンセンサスによって取得されるため、すべてのノードの過半数が連携できる限り、1つ以上のノードがダウンまたは遅れている場合でも使用できます。
現在、 EXCLUSIVE ロックのみをサポートしています。そのため、同じノード上の別のノードまたは別のバックエンドがオブジェクトのアドバイザリロックを既に取得している場合、他のノードまたはバックエンドはロックが解放されるまで待機する必要があります。
アドバイザリロックは本質的にトランザクションです。したがって、ロックはトランザクションの終了前に明示的に解放されない限り、トランザクションが終了すると自動的に解放されます。その場合、解放されるとすぐに利用できます。セッションレベルのアドバイザリロックは現在サポートされていません。
グローバル勧告ロックはリエントラントです。したがって、同じリソースが3回ロックされている場合、他のセッションで使用できるように解放するには3回アンロックする必要があります。
bdr.global_advisory_lock¶
このファンクションは、指定されたオブジェクトの
EXCLUSIVEロックを取得します。ロックが利用できない場合、ロックが利用可能になるか、
bdr.global_lock_timeout に到達するまで待機しロック。
概要¶
bdr.global_advisory_lock(key bigint)
パラメーター¶
key-アドバイザリロックが取得されるオブジェクト。
概要¶
bdr.global_advisory_lock(key1 integer, key2 integer)
パラメーター¶
key1-複合キーの最初のパート。key2- 複合キーの2番目のパート。
bdr.global_advisory_unlock¶
このファンクションは、アプリケーション定義のソースで以前に取得したロックを解放します。ロックは、アプリケーションによって同じトランザクションで以前に取得されている必要があります。そうでない場合、ERRORが発生します。
概要¶
bdr.global_advisory_unlock(key bigint)
パラメーター¶
key-アドバイザリロックが取得されるオブジェクト。
概要¶
bdr.global_advisory_unlock(key1 integer, key2 integer)
パラメーター¶
key1-複合キーの最初のパート。key2- 複合キーの2番目のパート。
モニタリングFunctions¶
bdr.monitor_group_versions¶
クラスタ全体のバージョンチェックを提供するために、このファンクションはビューbdr.group_version_details
から返されるBDRバージョン情報を使用します。
概要¶
bdr.monitor_group_versions()
注意事項¶
モニタリングとロギング で説明されているように、このファンクションは、フィールド
status およびmessage を持つレコードを返します。
このファンクションはbdr.run_on_all_nodes() を呼び出します。
bdr.monitor_group_raft¶
クラスタ全体のRaftチェックを提供するために、このファンクションはビューbdr.group_raft_details
から返されたBDR Raft情報を使用します。
概要¶
bdr.monitor_group_raft()
注意事項¶
このファンクションは、 モニタリングとロギング で説明されているように、フィールド
status およびレコードを返します。
このファンクションはbdr.run_on_all_nodes() を呼び出します。
bdr.monitor_local_replslots¶
このファンクションは、ビューpg_replication_slots
(スロットアクティブまたは非アクティブ)から返されたレプリケーションスロットステータス情報を使用して、
BDRグループスロットを除くすべてのレプリケーションスロットを考慮したローカルチェックを提供します。
概要¶
bdr.monitor_local_replslots()
注意事項¶
このファンクションは、 Monitoring Replication Slots で説明されているように、フィールド
status およびレコードを返します。
bdr.wal_sender_stats¶
デコードワーカー が有効になっている場合、このファンクションは、各WAL送信者が読み取っているデコーダースロットと現在のLCR(
Logical Change Record
)セグメントファイルに関する情報を表示します。
概要¶
bdr.wal_sender_stats() → setof record (pid integer, is_using_lcr boolean, decoder_slot_name TEXT, lcr_file_name TEXT)
出力列¶
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¶
デコードワーカー が有効になっている場合、このファンクションは現在のデータベースに関連付けられたDecoding
Workerの状態に関する情報を表示します。これは、 pg_replication_slots
を介して利用できるよりも詳細なDecoding
Workerの進行状況に関する情報も提供します。
概要¶
bdr.get_decoding_worker_stat() → setof record (pid integer, decoded_upto_lsn pg_lsn, waiting BOOL, waiting_for_lsn pg_lsn)
出力列¶
pid- Decoding WorkerのPID(pg_replication_slotsのactive_pid列に対応)decoded_upto_lsn- Decoding Workerがトランザクションログを読み取ったLSNwaiting- Decoding Workerが新しいWALを待っているかどうかwaiting_for_lsn- 次に予想されるWALのLSN
注意事項¶
詳細については、 Monitoring WAL senders using LCR を参照してください。
bdr.lag_control¶
ラグ制御 が有効になっている場合、このファンクションは、コミット遅延と、ローカルノードと現在のデータベースに構成されているラグメジャーに準拠するノードの数に関する情報を表示します。
概要¶
bdr.lag_control()
出力列¶
commit_delay- ミリ秒単位の現在のランタイムのコミット遅延commit_delay_maximum- ミリ秒単位で構成された最大コミット遅延commit_delay_adjustment-ミリ秒単位のサンプルインターバル中に可能なランタイムコミット遅延への変更conforming_nodes- ラグメジャーに準拠するノードの現在のランタイム数conforming_nodes_minimum- ラグメジャーに準拠するために必要なノードの構成された最小数、それ以下ではコミット遅延調整が適用されますlag_bytes_threshold-コミット遅延が適用されるラグサイズ(キロバイト)lag_bytes_maximum-構成された最大ラグサイズ(キロバイト)lag_time_threshold-コミット遅延が適用される遅延時間(ミリ秒)lag_time_maximum-ミリ秒単位の構成された最大遅延時間sample_interval-遅延サンプル間の構成された最小時間とミリ秒単位の可能なコミット遅延調整
内部Functions¶
BDRメッセージペイロードFunctions¶
bdr.decode_message_response_payload および bdr.decode_message_payload
これらの関数は、コンセンサスペイロードをより人間が読みやすい出力にデコードします。
主に bdr.global_consensus_journal_details
デバッグビューによって使用されます。
bdr.get_global_locks¶
このファンクションは、ローカルノードで保持されているグローバルロックに関する情報を表示します。
bdr.global_locks
ビューを実装して、ロックのより詳細な概要を提供するために使用されます。
bdr.get_slot_flush_timestamp¶
指定されたレプリケーションスロットの最後のフラッシュ位置確認のタイムスタンプを取得します。
bdr.node_slots ビューを実装するために内部で使用されます。
BDR内部ファンクションレプリケーションFunctions¶
bdr.internal_alter_sequence_set_kind、internal_replication_set_add_table、internal_replication_set_remove_table
さまざまなファンクション呼び出しのレプリケーションのために内部で使用されるFunctions。
BDRの現在のバージョンでは使用されなくなりました。ローリングアップグレード中の下位互換性のためにのみ存在します。
bdr.internal_submit_join_request¶
新しいノードに参加するためのコンセンサスリクエストを送信します。
BDRグループの再構成の内部メカニズムで必要です。
bdr.isolation_test_session_is_blocked¶
グローバルロックのブロックの追加チェックを使用してオリジナルのpg_isolation_test_session_is_blocked
を拡張(および実際に呼び出し)するヘルパファンクション。
分離/並行性テストに使用されます。
bdr.local_node_info¶
このファンクションは、 BDRグループの再構成の内部メカニズムが必要とするローカルノードの情報を表示します。
ビューbdr.local_node_summary
は、ユーザが使用するのに役立つ同様の情報を提供します。
bdr.msgb_connect¶
コンセンサスプロトコルによって使用される、別のノードのコネクションプーラに接続するためのファンクション。
bdr.msgb_deliver_message¶
コンセンサスプロトコルによって使用される、別のノードのコネクションプーラにメッセージを送信するためのファンクション。
bdr.peer_state_name¶
このファンクションは、ノードの状態(node_state
)をテキスト表現形式に変換し、主に bdr.node_summary
ビューを実装するために使用されます。
bdr.request_replay_progress_update¶
「リプレイ進行状況の更新」Raftメッセージの即時書き込みを要求します。これは主にテスト目的で使用されますが、コンセンサスメカニズムが機能しているかどうかをテストするために使用することもできます。
bdr.seq_nextval¶
シーケンスインクリメントの内部実装。
このファンクションは、 BDRグローバルシーケンス と対話するクエリで標準の
nextval の代わりに使用されます。
注意事項¶
以下も内部BDRシーケンス操作関数です。 bdr.seq_currval
とbdr.sql_lastval は自動的に使用されます。
bdr.show_subscription_status¶
サブスクリプションのステータスに関する情報を取得し、主に
bdr.subscription_summary ビューを実装するために使用されます。
bdr.conflict_resolution_to_string¶
競合解決をoidからテキストに変換します。
ビューbdr.conflict_history_summary
はこれを使用して、競合解決のためのユーザフレンドリ情報を提供します。
bdr.conflict_type_to_string¶
競合タイプをoidからテキストに変換します。
ビューbdr.conflict_history_summary
はこれを使用して、競合解決のためのユーザフレンドリ情報を提供します。
bdr.get_node_conflict_resolvers¶
ローカルノード上のすべての競合リゾルバーのテキスト文字列を表示します。
bdr.reset_subscription_stats¶
bdr.stat_subscriptionで表示されるように、サブスクリプションによって作成された統計をリセットした後、ブール値を返します。
bdr.reset_relation_stats¶
bdr.stat_relationで表示されるように、リレーションの統計をリセットした後、ブール値を返します。
bdr.pg_xact_origin¶
指定されたトランザクションのオリジンIDを返します。
概要¶
bdr.pg_xact_origin(xmin xid)
パラメーター¶
xid-オリジンを返すトランザクションID
bdr.difference_fix_origin_create¶
引数として渡された名前でレプリケーションオリジンを作成しますが、
bdr_
プレフィックスを追加します。オリジンの内部IDを返します。これは、postgresのスーパーユーザ権限ではなくbdr_superuser
が必要であることを除いて、 pg_replication_origin_create()
と同じ機能を実行します。
概要¶
bdr.difference_fix_session_setup¶
現在のセッションを現在のオリジンから再生していることを示します。このファンクションは、
セッションに対して事前に作成された bdr_local_only_origin
ローカルレプリケーションオリジンを暗黙的に使用します。リプレイの進行状況を報告できます。
void を返します。これはpg_replication_origin_session_setup()
と同じ機能を実行しますが、これにはpostgresのスーパーユーザ権限ではなくbdr_superuser
が必要です。ファンクションの以前のフォーム:
bdr.difference_fix_session_setup(text)
は非推奨であり、今後のリリースで削除されることに注意してください。
概要¶
bdr.difference_fix_session_setup()
bdr.difference_fix_session_reset¶
現在のセッションをオリジンから再生していないものとしてマークし、基本的に
bdr.difference_fix_session_setup() の効果をリセットします。 void
を返します。これはpg_replication_origin_session_reset()
と同じ機能を実行しますが、これにはpostgresのスーパーユーザ権限ではなくbdr_superuser
が必要です。
概要¶
bdr.difference_fix_session_reset()
bdr.difference_fix_xact_set_avoid_conflict¶
LSN
’0/0’およびタイムスタンプ’2000-01-01’でコミットされたトランザクションを再生するものとして、現在のトランザクションをマークします。これは、postgresのスーパーユーザ権限ではなくbdr_superuser
が必要であることを除いて、
pg_replication_origin_xact_setup('0/0', '2000-01-01')
と同じ機能を実行します。
概要¶
bdr.difference_fix_xact_set_avoid_conflict()
bdr.resynchronous_table_from_node(node_name 名前、リレーションregclass)¶
リモートノードからリレーションを再同期します。
概要¶
bdr.resynchronize_table_from_node(node_name name, relation regclass)
パラメーター¶
node_name-リレーションデータのコピー/再同期元のノード。relation-リモートノードからコピーされるリレーション。
注意事項¶
これにより、リレーションのグローバルDMLロックが取得され、ローカルでリレーションが切り捨てられ、リモートノードからリレーションにデータがコピーされます。
リレーションは、同じ名前と定義で両方のノードに存在する必要があります。
同じパーティション定義を持つテーブルパーティションの再同期、パーティションテーブルから非パーティションテーブルへの再同期、および外部キーコンストレインを一時的に削除して再作成することによる被参照テーブルの再同期はすべてサポートされています。
被参照されるテーブルでファンクションを実行した後、被参照される列のデータが参照する列の値と一致しない場合、エラーがスローされ、参照テーブルデータを再同期した後にファンクションを再実行する必要があります。
さらに、リモートノードからデータをコピーした後、生成された列の値をローカルで計算することにより、生成された列を含むテーブルの再同期をサポートします。
現在、row_filtersはこのファンクションでは無視されます。
bdr.resynchronize_table_from_node
ファンクションは、テーブルの所有者がbdr_superuser権限を持っている場合にのみ実行できます。
bdr.consensus_kv_store¶
一貫したKVストアに値を保存します。
値の有効期限のタイムスタンプを返します。これはttl に依存します。
ttl がNULL の場合、これはinfinity
を結果ます値が削除された場合は-infinity を結果ます。
概要¶
bdr.consensus_kv_store(key text, value jsonb,
prev_value jsonb DEFAULT NULL, ttl int DEFAULT NULL)
パラメーター¶
key- 挿入、更新、または削除するための任意の一意のキー。value-保存するjson値、NULLの場合、既存のレコードは削除されますprev_value- 設定すると、現在の値がprev_valueと等しい場合にのみ書き込みオペレーションが実行されます。ttl- 新しい値の存続時間(ミリ秒)。
注意事項¶
これは内部ファンクションであり、主にHARPによって使用されます。
警告
このファンクションは、ユーザアプリケーションでは使用しないでください。
bdr.consensus_kv_fetch¶
一貫したKVストアからjsonフォーマットで値を取得します。
概要¶
bdr.consensus_kv_fetch(IN key text) RETURNS jsonb
パラメーター¶
key-フェッチする任意のキー。
注意事項¶
これは内部ファンクションであり、主にHARPによって使用されます。
警告
このファンクションは、ユーザアプリケーションでは使用しないでください。
bdr.alter_subscription_skip_changes_upto¶
ロジカルレプリケーションはバージョン間でレプリケートできますが、ロールのようなグローバル変更をレプリケートせず、選択的にレプリケートできるため、ロジカルレプリケーションの適用プロセスでエラーが発生し、変更の適用が停止する場合があります。
このような問題は、可能な限りターゲット側に変更を加えて修正する必要があります。レプリケーションをブロックしている欠落しているテーブル、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
);
例¶
トランザクションの適用がERRORで失敗し、ターゲット側での変更などの影響の少ない修正ではこの問題を解決しないと判断しました。あなたは、トランザクションをスキップする必要があると判断しました。
この人工的な例のように、エラーログで、スキップするコミットレコード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
ingして、そのレコードを保存することを強くお勧めします。
\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
は複数行のコマンドをサポートしていないため、1行で発行する必要があることに注意してください。
上記の「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);