Monitoring through SQL

EDB Postgres Distributedは、その分散性に固有のいくつかのモニタリングおよび統計ビューを提供します。標準のPostgresモニタリングは、 EDB Postgres Distributedのモニタリングにも役立ちます。

モニタリングの概要

PGDグループは、ノードと呼ばれることが多い複数のサーバーで構成されています。すべてのノードを監視して、グループ全体の状態を確認します。

bdr_monitorロールは、 bdr.monitor ファンクションを実行して、3つのレベルのいずれかを使用してPGDの健全性を評価できます。

• OK —多くの場合、緑色で示されます。

• WARNING —黄色で表示されることが多いです。

• CRITICAL —赤く表示されることが多いです。

• UNKNOWN —認識されない状況の場合、多くの場合赤で示されます。

PGDは、さまざまな内部メトリックの瞬間的な状態を表示する動的カタログビューも提供します。また、構成のデフォルトとユーザーが要求する構成の変更を格納するメタデータカタログも提供します。これらのビューとテーブルの一部は、bdr_monitorまたはbdr_read_all_statsでアクセスできますが、一部には、より高いセキュリティ要件を持つユーザーまたは内部情報が含まれています。

PGDを使用すると、各ノードを個別に監視したり、単一のノードにアクセスしてグループ全体を監視したりできます。各ノードを個別に監視したい場合は、各ノードに接続して監視要求を発行します。単一のノードからグループを監視する場合は、 bdr.group で始まるビューを使用してください。これらの要求は他のノードを呼び出してグループレベルの情報セットを組み立てるためです。

bdr_superuserによってbdr.run_on_all_nodes() ファンクションへのアクセスが許可された場合、すべてのノードに対して独自の呼び出しを行うことができます。

モニタリングノードの参加と削除

デフォルトでは、ノード管理機能は結合または部分操作が完了するまで待機します。それぞれのwait_for_completion 関数引数を使用して、待機をオフにできます。待機がオフになっている場合、結合または部分操作がいつ終了するかを確認するには、 bdr.node_summary およびbdr.event_summary を使用して間接的にノードの状態を確認します。

呼び出されると、ヘルパー関数bdr.wait_for_join_completion() は、すべての未処理のノード参加操作領域が完了するまでPostgreSQLセッションを一時停止します。

この例は、 bdr.node_summary からのSELECT クエリの出力を示しています。これは、2つのノードがアクティブで、別のノードが参加していることを示しています。

# SELECT node_name, interface_connstr, peer_state_name,
#     node_seq_id, node_local_dbname
# FROM bdr.node_summary;
-[ RECORD 1 ]-----+-----------------------------------------
node_name         | node1
interface_connstr | host=localhost dbname=postgres port=7432
peer_state_name   | ACTIVE
node_seq_id       | 1
node_local_dbname | postgres
-[ RECORD 2 ]-----+-----------------------------------------
node_name         | node2
interface_connstr | host=localhost dbname=postgres port=7433
peer_state_name   | ACTIVE
node_seq_id       | 2
node_local_dbname | postgres
-[ RECORD 3 ]-----+-----------------------------------------
node_name         | node3
interface_connstr | host=localhost dbname=postgres port=7434
peer_state_name   | JOINING
node_seq_id       | 3
node_local_dbname | postgres

また、テーブル bdr.node_catchup_info は、キャッチアップ状態に関する情報を提供します。これは、ノードの参加またはノードの分離に関連します。

ノードが分離されると、クラスター内の一部のノードがその分離ノードからすべてのデータを受信しない場合があります。したがって、ノードを分割すると、そのデータをすでに受信して転送できるノードから一時的なスロットが作成されます。

catchup_state は、次のいずれかになります。

10 = setup
20 = start
30 = catchup
40 = done

レプリケーションピアのモニタリング

レプリケーションアクティビティの監視には、2つのメインビューを使用します。

• 発信レプリケーションを監視するための FROM bdr.node_slots;

• 着信レプリケーションを監視するための FROM bdr.subscription_summary;

標準のPostgreSQLレプリケーションモニタリングビュー

pg_catalog.pg_stat_replication を照会することにより、 bdr.node_slots

が提供する情報のほとんどを取得することもできます

そして pg_catalog.pg_replication_slots 。

各ノードには1つのPGDグループスロットがあります。これは決して接続してはならず、アクティブとしてマークされることはめったにありません。これは正常であり、何かがダウンまたは切断されていることを意味するものではありません。

Replication slots created by PGD <Node management>` を参照してください。

発信レプリケーションのモニタリング

送信レプリケーションアクティビティの監視には、別のビューを使用できます。

• 発信レプリケーションを監視するための SELECT * FROM bdr.node_replication_rates;

:ref:` <User visible catalogs and views>` ビューは、特にピアノードのキャッチアップ推定とともに、発信レプリケーションアクティビティの全体像を提供します。

# SELECT * FROM bdr.node_replication_rates;
-[ RECORD 1 ]----+-----------
peer_node_id     | 112898766
target_name      | node1
sent_lsn         | 0/28AF99C8
replay_lsn       | 0/28AF99C8
replay_lag       | 00:00:00
replay_lag_bytes | 0
replay_lag_size  | 0 bytes
apply_rate       | 822
catchup_interval | 00:00:00
-[ RECORD 2 ]----+-----------
peer_node_id     | 312494765
target_name      | node3
sent_lsn         | 0/28AF99C8
replay_lsn       | 0/28AF99C8
replay_lag       | 00:00:00
replay_lag_bytes | 0
replay_lag_size  | 0 bytes
apply_rate       | 853
catchup_interval | 00:00:00

apply_rate は、1秒あたりのバイト単位の速度を指します。これは、ピアがローカルノードからのデータを消費しているレートです。ノードがクラスターに再接続したときのreplay_lag は、すぐにゼロに設定されます。この情報は、将来のリリースで修正される予定です。回避策として、ピアノードがローカルノードのデータに追いつくために必要な時間を参照するcatchup_interval 列を使用することをお勧めします。他のフィールドも FROM bdr.node_slots; から利用できます

ビュー。

注釈

このカタログは、 bdr-enterprise拡張機能がインストールされている場合にのみ存在します。

管理者は、ローカルノードからの送信レプリケーションについて`

FROM bdr.node_slots; にクエリを実行できます。現在のノードで認識されているグループ内の他のすべてのノードのレプリケーションステータスと、現在のノードでPGDによって作成された追加のレプリケーションスロットに関する情報を表示します。

# SELECT node_group_name, target_dbname, target_name, slot_name, active_pid,
#     catalog_xmin, client_addr, sent_lsn, replay_lsn, replay_lag,
#     replay_lag_bytes, replay_lag_size
# FROM bdr.node_slots;

-[ RECORD 1 ]---+----------------------------
node_group_name | bdrgroup
target_dbname   | postgres
target_name     | node3
slot_name       | bdr_postgres_bdrgroup_node3
active_pid      | 15089
catalog_xmin    | 691
client_addr     | 127.0.0.1
sent_lsn        | 0/23F7B70
replay_lsn      | 0/23F7B70
replay_lag      | [NULL]
replay_lag_bytes| 120
replay_lag_size | 120 bytes
-[ RECORD 2 ]---+----------------------------
node_group_name | bdrgroup
target_dbname   | postgres
target_name     | node2
slot_name       | bdr_postgres_bdrgroup_node2
active_pid      | 15031
catalog_xmin    | 691
client_addr     | 127.0.0.1
sent_lsn        | 0/23F7B70
replay_lsn      | 0/23F7B70
replay_lag      | [NULL]
replay_lag_bytes| 84211
replay_lag_size | 82 kB

PGDはメッシュネットワークであるため、クラスター内のラグの完全なビューを取得するには、参加しているすべてのノードでこのクエリを実行する必要があります。

replay_lag_bytes は、ローカルサーバーの現在のWAL書き込み位置と、ピアノードによって確認された最後の位置であるreplay_lsn とのWAL位置の差を報告します。 replay_lag_size は、人間が読める形式のものです。 WALには通常、複製されないがreplay_lag_bytes でカウントされる多くの書き込みが含まれることを理解することが重要です。例：

• VACUUM アクティビティ

• インデックスの変更

• 同じノード上の他のデータベースに関連付けられた書き込み

• レプリケーションセットの一部ではないテーブルへの書き込み

したがって、ここで報告されるバイト単位のラグは、ピアノードを最新の状態にするためにネットワークで複製する必要があるデータの量ではなく、処理する必要があるサーバーサイドWALの量のみです。

同様に、 replay_lag は、ピアノードが追いつくまでにかかる時間や、 bdr.node_slots が照会されたときの現在の位置から書き込み位置まで再生するのにかかる時間の尺度ではありません。ピアが最新のコミットを確認してから現在の実時間までの遅延を測定します。ノードが再接続した直後にこの列がゼロに設定されるため、replay_lag_bytes およびbdr.node_replication_rates のreplay_lag_size またはcatchup_interval を監視することをお勧めします。

論理レプリケーションがトランザクションをストリーミングしている間、バイトと時間の両方のラグは進行しません。コミットがレプリケートされる場合にのみ変更されます。したがって、ラグは「のこぎり」になる傾向があり、トランザクションがストリーミングされると上昇し、ピアノードがコミットしてフラッシュし、確認を送信すると再び低下します。報告されたLSNは、同様の理由で、スムーズに進むのではなく「階段」の位置にあります。

レプリケーションが切断されると（active = 'f' ）、 active_pid 列はNULL になり、client_addr およびアクティブな接続でのみ意味を持つ他のフィールドも同様です。 state フィールドは'disconnected' です。 _lsn フィールドはconfirmed_flush_lsn と同じです。これは、クライアントが再生および保存したことが確実にわかっている最後の位置であるためです。 _lag フィールドは、クライアントで確認された最新のフラッシュと現在時刻の間の経過時間を示します。 _lag_size および_lag_bytes フィールドは、 confirmed_flush_lsn とローカルサーバーの現在のWAL挿入位置との間の距離を報告します。

注釈

restart_lsn が他の`lsn` 列の後ろにあるのは正常です。これは、レプリケーションの問題やピアノードの遅延を示しているわけではありません。 restart_lsn は、PostgreSQLの内部論理デコードが中断された場合にWALを読み取っていなければならない位置です。通常、まだレプリケートおよびフラッシュされていない最も古いトランザクションの位置を反映します。非常に古い`restart_lsn` は、切断後のレプリケーションの再開を遅くし、必要以上のWALの保持を強制する可能性がありますが、それ以外は無害です。心配な場合は、非常に長時間実行されるトランザクションと忘れられた準備済みトランザクションを探してください。

着信レプリケーションのモニタリング

bdr.subscription_summary ビューを照会することにより、着信レプリケーション（サブスクリプションとも呼ばれます）を監視できます。このクエリは、 EDB Postgres分散クラスター内の他のノードへの既知のサブスクリプションのリストとレプリケーションワーカーの状態を表示します。

SELECT node_group_name, origin_name, sub_enabled, sub_slot_name,

subscription_status

FROM bdr.subscription_summary;

• [ RECORD 1 ]——-+—————————- node_group_name | bdrgroup origin_name | node2 sub_enabled | t sub_slot_name | bdr_postgres_bdrgroup_node1 subscription_status | bdr_postgres_bdrgroup_node1複製 -[ RECORD 2 ]——-+—————————- node_group_name | bdrgroup origin_name | node3 sub_enabled | t sub_slot_name | bdr_postgres_bdrgroup_node1 subscription_status | bdr_postgres_bdrgroup_node1複製する

デコードワーカー が有効になっている場合、関数 bdr.wal_sender_stats()

を使用して、WAL送信者ごとの現在の論理変更レコード（LCR）ファイルに関する情報をモニタできます。例：

postgres=# SELECT * FROM bdr.wal_sender_stats();
   pid   | is_using_lcr |       decoder_slot_name       |              lcr_file_name
- --------+--------------+-------------------------------+------------------------------------------
 2059904 | f            |                               |
 2059909 | t            | bdr_postgres_bdrgroup_decoder | 0000000000000000000000140000000000000000
 2059916 | t            | bdr_postgres_bdrgroup_decoder | 0000000000000000000000140000000000000000
(3 rows)

is_using_lcr がFALSE の場合、decoder_slot_name /lcr_file_name はNULL です。これは、デコードワーカーが有効になっていない場合、またはWAL送信者が

ロジカルスタンバイノード を提供している場合です。

また、関数 bdr.get_decoding_worker_stat() を使用して、デコードワーカーに関する情報をモニタできます。例：

postgres=# SELECT * FROM bdr.get_decoding_worker_stat();
   pid   | decoded_upto_lsn | waiting | waiting_for_lsn
- --------+------------------+---------+-----------------
 1153091 | 0/1E5EEE8        | t       | 0/1E5EF00
(1 row)

PGDレプリケーションワーカーのモニタリング

すべてのPGDワーカーは、システムビュー bdr.stat_activity に表示されます。これには、 pg_stat_activity と同じ列と情報コンテンツがあります。したがって、このビューは、PGDシステムの状態に関する次の洞察を提供します。

• 待機の理由がPGDに関連する場合、wait_event列の情報が強化されました。

• ライタプロセスがDDLを実行している場合を除き、PGDワーカーの query 列は空白です。

bdr.workers ビューには、 bdr.stat_activity から利用できないPGDワーカー固有の詳細が表示されます。

ビューbdr.event_summary は、作業の続行に問題があるワーカーによって報告された最後のエラー（ある場合）を示します。この情報は永続的であるため、エラーの存在だけでなく、エラーの時刻に注意することが重要です。ほとんどのエラーは一時的なものであり、PGDワーカーは失敗した操作を再試行します。

PGDライターの監視

別のシステムビューであるbdr.writers は、ライタのアクティビティを監視します。このビューには、ライタワーカーの現在のステータスのみが表示されます。それには以下が含まれます：

• ライタが属するサブスクリプションを識別するsub_name

• ライタプロセスのpid

• ライタが進行中のストリーミングトランザクションの適用をサポートしているかどうかを知るためのstreaming_allowed

• ライタが現在ストリーミングトランザクションを適用しているかどうかを知るためのis_streaming

• commit_queue_position は、コミットキュー内のライタの位置を確認します

PGDは、オリジンで発生したのと同じコミットオーダーに従うことにより、コミットオーダーを尊重します。並列ライターの場合、複数のライターが同時に異なるトランザクションを適用する場合があります。 commit_queue_position は、コミットする順序を示しています。値0 は、ライタが最初にコミットすることを意味します。値-1 は、コミット位置がまだわかっていないことを意味します。これは、ストリーミングトランザクション、またはライタが現在トランザクションを適用していないときに発生する可能性があります。

グローバルロックの監視

現在DDLレプリケーションにのみ使用されているグローバルロックは、PGDグループ全体に存在する重量ロックです。

現在、2種類のグローバルロックがあります。

• DDLロック、データベース内の永続的な（一時ではない）オブジェクト（つまり、テーブル）に対するすべてのDDL操作をシリアル化するために使用されます

• DMLリレーションロック、リレーション定義を変更するDDL操作中にリレーションへの書き込みをロックアウトするために使用されます

DDL操作のタイプと bdr.ddl_locking 設定の値に応じて、同じトランザクションに対していずれかまたは両方のエントリタイプを作成できます。

ローカルノードで保持されているグローバルロックは、

SELECT lock_type、relation、pid FROM bdr.global_locks; ビューで表示されます。このビューは、ロックの種類を示しています。リレーションロックの場合、ロックされているリレーション、ロックを保持しているPID（ローカルの場合）、およびロックがグローバルに付与されたかどうかを示します。グローバルなアドバイザリーロックの場合、

lock_type 列はGLOBAL_LOCK_ADVISORY を示し、 relation 列はロックが取得されるアドバイザリーキーを示します。

この例は、bdr.ddl_locking = on でALTER TABLE ステートメントを実行中のbdr.global_locks の出力を示しています。

SELECT lock_type、relation、pid FROM bdr.global_locks;

• [ RECORD 1 ]————– lock_type | GLOBAL_LOCK_DDLリレーション | [NULL] pid | 15534 -[ RECORD 2 ]————– lock_type | GLOBAL_LOCK_DMLリレーション| someschema.sometable pid | 15534

ロックタイミング情報を含むすべてのフィールドの詳細については、

Internal catalogs and views を参照してください。

競合の監視

レプリケーション CRDTデータ型を使用した列の競合の処理 は、複数のノードが互いに相互作用できる方法で同じ行に影響を与える変更を加えた場合に発生する可能性があります。 PGDシステムを監視して競合を特定し、可能な場合は、アプリケーションを変更して競合を排除するか、競合の頻度を減らします。

デフォルトでは、すべての競合はbdr.conflict_history に記録されます。このログには競合するデータの完全な詳細が含まれているため、行は行レベルのセキュリティによって保護され、レプリケートテーブルの所有者のみが参照できるようにします。所有者は、競合を予想し、競合を分析して、解決すべき問題と見なされる可能性のある問題を確認する必要があります。

モニタリングには、ユーザーデータを含まないbdr.conflict_history_summary を使用します。この例は、効率的なクエリプランを使用して、当日に発生した競合の数をカウントするクエリを示しています。

SELECT count(*)
FROM bdr.conflict_history_summary
WHERE local_time > date_trunc(day, current_timestamp)
  AND local_time < date_trunc(day, current_timestamp + 1 day);

統計を適用する

PGDは、サブスクリプションごととテーブルごとの両方について、レプリケーションの適用に関する統計を収集します。

2つのモニタリングビューが存在します。サブスクリプション統計用の bdr.stat_subscription とリレーション統計用の bdr.stat_relation です。これらのビューはどちらも以下を提供します。

• レプリケートされたINSERT / UPDATE / DELETE / TRUNCATEの数

• ブロックアクセスとキャッシュヒット率

• 読み取り/書き込みの合計I / O時間

• ファイルにストリーミングされた進行中のトランザクションの数

• ライターにストリーミングされた進行中のトランザクションの数

• コミット/中止された進行中のストリーミングトランザクションの数

リレーションの場合のみ、 bdr.stat_relation には以下も含まれます。

• リレーションのレプリケーションの処理にかかった合計時間

• リレーション（のみ）のロック（ある場合）を取得するための合計ロック待機時間

サブスクリプションの場合のみ、 bdr.stat_subscription には以下が含まれます。

• サブスクリプションにレプリケートされたCOMMIT / DDLの数

• このサブスクリプションがアップストリームに接続した回数

これらの統計の追跡は、それぞれPGD GUC bdr.track_subscription_apply およびbdr.track_relation_apply によって制御されます。

次に、これらからの出力例を示します。

sql # SELECT sub_name、nconnect、ninsert、ncommit、nupdate、ndelete、ntruncate、nddl

FROM bdr.stat_subscription; -[ RECORD 1 ]———————————- sub_name | bdr_regression_bdrgroup_node1_node2 nconnect | 3 n挿入 | 10 ncommit | 5 nupdate | 0 ndelete | 0 トランケート | 0nddl | 2

この場合、サブスクリプションはアップストリームに3回接続し、10行を挿入し、5つのトランザクション内で2つのDDLコマンドを実行しました。

関数bdr.reset_subscription_stats およびbdr.reset_relation_stats を使用して、これらのビューの統計カウンターをゼロにリセットできます。

標準のPostgreSQL統計ビュー

テーブルとインデックスの使用に関する統計は、通常、ダウンストリームマスターによって更新されます。これは、

autovacuum

の正しい機能に不可欠です。ダウンストリームマスターにローカル書き込みがなく、統計がリセットされていない場合、次の2つのビューには、アップストリームとダウンストリームの間で対応する結果が表示されます。

• pg_stat_user_tables

• pg_statio_user_tables

注釈

上流のテーブル統計が必ずしも下流のものと*似ている*とは限りません。私たちはそれらが同じ量だけ*変化*することを期待しています。統計が1Mの挿入と1Mの更新を示すテーブルの例を考えます。新しいノードがPGDグループに参加すると、新しいノードの同じテーブルの統計には、1Mの挿入とゼロの更新が表示されます。ただし、その瞬間から、片側でのすべての変更が反対側にレプリケートされるため、アップストリームとダウンストリームのテーブル統計は同じ量だけ変化します。

インデックスは変更を適用するために使用されるため、ダウンストリーム側の識別インデックスは、非識別インデックスよりもUPDATE およびDELETE を実行するワークロードで頻繁に使用されるように見える場合があります。

組み込みのインデックス監視ビューは次のとおりです。

• pg_stat_user_indexes

• pg_statio_user_indexes

これらすべてのビューについては、 PostgreSQL documentation on the statistics views で詳細に説明されています。

PGDバージョンの監視

PGDを使用すると、同じクラスター内のノード間で異なるPostgresバージョンと異なるBDR拡張バージョンを実行できます。この機能は、アップグレードに役立ちます。

ビューbdr.group_versions_details は、ファンクションbdr.run_on_all_nodes() を使用して、すべてのノードからPostgresおよびBDR拡張機能バージョンを同時に取得します。例：

bdrdb=# SELECT node_name, postgres_version, bdr_version
        FROM bdr.group_versions_details;
 node_name | postgres_version | bdr_version
- ----------+------------------+-------------
 node1     | 15.2.0           | 5.0.0
 node2     | 15.2.0           | 5.0.0

推奨されるセットアップは、すべてのノードで同じ（および最新の）バージョンをできるだけ早く実行することです。クラスターで異なるバージョンのBDR拡張機能を長時間実行しないことをお勧めします。

モニタリングのために、次のアラートレベルをお勧めします。

• status=UNKNOWN、message=このノードはPGDグループの一部ではありません

• status = OK、message =すべてのノードは同じPGDバージョンを実行しています

• status=WARNING、message=アクセスできないノードが少なくとも1つあります

• status=WARNING、message=他のノードと比較すると、異なるPGDバージョンを実行しているノードがあります

説明されている動作は関数bdr.monitor_group_versions() で実装されています。関数はbdr.group_version_details ビューから返されたPGDバージョン情報を使用して、クラスター全体のバージョンチェックを提供します。例：

bdrdb=# SELECT * FROM bdr.monitor_group_versions();
 status |                message
- -------+-----------------------------------------
 OK     | All nodes are running same BDR versions

Raftコンセンサスのモニタリング

Raftコンセンサスは、常にクラスター全体で機能している必要があります。 Raftコンセンサスを機能させずにEDB Postgres分散クラスターを実行した場合の影響は次のとおりです。

• PGDデータ変更のレプリケーションは、引き続き正常に動作する場合があります。

• グローバルDDL/ DMLロックが機能しません。

• Gallocシーケンスは最終的にチャンクを使い果たします。

• Eager Replicationが機能しません。

• クラスターのメンテナンス操作（ノードに参加、ノードの一部、スタンバイの昇格）は引き続き許可されますが、完了しない（代わりにハングする）場合があります。

• PGDノード間でノードのステータスが正しく同期されない場合がある。

• PGDグループレプリケーションスロットはLSNを進めないため、WALファイルをディスク上に保持します。

ビューbdr.group_raft_details は、関数bdr.run_on_all_nodes() およびbdr.get_raft_status() を使用して、すべてのノードから同時にRaftコンセンサスステータスを取得します。例：

bdrdb=# SELECT node_id, node_name, state, leader_id
FROM bdr.group_raft_details;
  node_id   | node_name | node_group_name |     state     | leader_id
- -----------+-----------+-----------------+---------------+------------
 1148549230 | node1     | top_group       | RAFT_LEADER   | 1148549230
 3367056606 | node2     | top_group       | RAFT_FOLLOWER | 1148549230

これらの条件がすべて満たされている場合、Raftコンセンサスは正しく機能しています。

• すべてのノードで有効な状態（RAFT_LEADER またはRAFT_FOLLOWER ）が定義されています。

• ノードのうち1つだけがRAFT_LEADER です。

• leader_id はすべての行で同じであり、state = RAFT_LEADER が含まれる行のnode_id と一致する必要があります。

時々、Raftコンセンサスは、新しいRAFT_LEADER を定義するための新しい選挙を開始します。選挙中に、RAFT_LEADER がなく、一部のノードが自分自身をRAFT_CANDIDATE であると考える中間状況が発生する可能性があります。選択全体はbdr.raft_election_timeout より長くかかることはありません（デフォルトでは6秒に設定されています）。上記のクエリで選挙中の状況が返された場合、 bdr.raft_election_timeout を待って、クエリを再度実行します。 bdr.raft_election_timeout が合格した後、リストされている条件の一部がまだ満たされていない場合、Raftコンセンサスは機能していません。

Raftコンセンサスは、単一のノードでのみ正しく機能しない場合があります。たとえば、ノードの1つが現在のリーダーを認識せず、自分自身をRAFT_CANDIDATE と見なします。この場合、次のことを確認することが重要です。

• すべてのPGDノードは、通常接続とレプリケーション接続の両方を介して互いにアクセスできます（ファイルpg_hba.conf を確認してください）。

• PGDバージョンはすべてのノードで同じです。

• bdr.raft_election_timeout はすべてのノードで同じです。

場合によっては、特にノードが地理的に離れている場合、またはネットワークの待機時間が長い場合、デフォルト値のbdr.raft_election_timeout （6秒）では十分でない場合があります。すべてが正しいことを確認してもRaftコンセンサスがまだ機能しない場合は、すべてのノードでbdr.raft_election_timeout を30秒に増やすことを検討してください。 PGD 3.6.11以降の場合、 bdr.raft_election_timeout を設定するにはサーバーのリロードのみが必要です。

Raftコンセンサスがクラスター運用タスクにどのように影響するか、およびRaftコンセンサスがグループスロットを進めることに直接責任があることを考えると、モニタリングアラートレベルは次のように定義されます。

• status=UNKNOWN、message=このノードはPGDグループの一部ではありません

• status=OK、message=Raft Consensusは正しく機能しています

• status=WARNING、message=アクセスできないノードが少なくとも1つあります

• status=WARNING、message=RAFT_CANDIDATEのノードがあります。選挙が進行中の可能性があります

• status=WARNING, message=RAFT_LEADERはありません。選挙が進行中の可能性があります

• status=CRITICAL、message=Raft Consensusには単一のノードがあります

• status=CRITICAL、message=RAFT_LEADERが定義されているときにRAFT_CANDIDATEとしてノードがあります

• status=CRITICAL、message=RAFT_LEADERとして設定されたノードとは異なるリーダーをフォローしているノードがあります

説明されている動作は関数bdr.monitor_group_raft() に実装されています。関数bdr.group_raft_details はビューbdr.group_raft_details から返されたRaftコンセンサスステータス情報を使用して、クラスター全体のRaftチェックを提供します。例：

bdrdb=# SELECT * FROM bdr.monitor_group_raft();
node_group_name | status |               message
- ---------------|--------+-------------------------------------
myroup          | OK     | Raft Consensus is working correctly

レプリケーションスロットのモニタリング

各PGDノードは以下を保持します。

• アクティブなPGDピアごとに1つの複製スロット

• 1つのグループレプリケーションスロット

例：

bdrdb=# SELECT slot_name, database, active, confirmed_flush_lsn
FROM pg_replication_slots ORDER BY slot_name;
        slot_name         | database | active | confirmed_flush_lsn
- -------------------------+----------+--------+---------------------
 bdr_bdrdb_bdrgroup       | bdrdb    | f      | 0/3110A08
 bdr_bdrdb_bdrgroup_node2 | bdrdb    | t      | 0/31F4670
 bdr_bdrdb_bdrgroup_node3 | bdrdb    | t      | 0/31F4670
 bdr_bdrdb_bdrgroup_node4 | bdrdb    | t      | 0/31F4670

ピアスロット名は規則bdr_<DATABASE>_<GROUP>_<PEER> に従いますが、PGDグループスロット名は規則bdr_<DATABASE>_<GROUP> に従います。関数bdr.local_group_slot_name() を使用して、グループスロットにアクセスできます。

ピアレプリケーションスロットは、すべてのノードで常にアクティブである必要があります。ピアレプリケーションスロットがアクティブでない場合、次のいずれかを意味する可能性があります。

• 対応するピアがシャットダウンされているか、アクセスできません。

• PGDレプリケーションが壊れています。

ERROR またはFATAL のログファイルをgrepし、すべてのノードでbdr.event_summary も確認します。根本的な原因は、たとえば、ノードの1つでDDLレプリケーションを無効にして互換性のないDDLが実行されたことが考えられます。

ただし、 PGDグループレプリケーションスロットは、ほとんどの場合非アクティブです。 PGDはこのスロットを維持し、他のすべてのピアが対応するトランザクションをすでに消費しているときにLSNを進めます。したがって、グループスロットのステータスを監視する必要はありません。

関数bdr.monitor_local_replslots() は、すべてのPGDノードレプリケーションスロットが期待どおりに機能しているかどうかのサマリーを提供します。例：

bdrdb=# SELECT * FROM bdr.monitor_local_replslots();
 status |                    message
- -------+-------------------------------------------------
 OK     | All BDR replication slots are working correctly

次のステータス概要のいずれかが返されます。

• 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

トランザクションのCOMMITの監視

デフォルトでは、PGDトランザクションはローカルノードでのみコミットします。その場合、トランザクションCOMMIT は迅速に処理されます。

標準のPostgreSQL同期レプリケーションでPGDを使用できます。 PGDは、2つの新しいトランザクションコミットモード、 CAMOとeagerレプリケーションも提供します。これらの各モードは堅牢性機能を追加しますが、 COMMIT での追加のレイテンシーを犠牲にします。 bdr.stat_activity カタログを使用して、COMMIT での追加時間を動的に監視できます。プロセスはさまざまなwait_event 状態を報告します。 1つ以上の同期スタンバイからの確認を待っているCOMMIT のトランザクションはSyncRep 待機イベントを報告しますが、2つの新しいモードはEagerRep を報告します。