Monitoring¶

レプリケーション設定を監視することは、システムが最適に実行され、ディスク領域が不足したり、操作を停止する可能性のあるその他の障害が発生したりしないように重要です。

自動モニタリングを導入して、たとえば、レプリケーションスロットがひどく遅れ始めた場合に、管理者にアラートを送信し、プロアクティブなアクションを取れるようにすることが重要です。

EDBは、バージョン8.1からBDRをサポートするPostgres Enterprise Manager（PEM）を提供します。または、ツールまたはユーザーは、以下で説明する機能を使用してBDRに独自の呼び出しを行うことができます。

モニタリングの概要¶

BDRグループは、多くの場合ノードと呼ばれる複数のサーバーで構成されています。グループ全体の状態を確認するには、すべてのノードを監視する必要があります。

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

OK - 多くの場合、緑色で示されます
WARNING - 黄色で表示されることが多い
CRITICAL - 多くの場合、赤で示されます
および UNKNOWN - 認識されない状況の場合、多くの場合赤で示されます

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

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

bdr_superuserからbdr.run_on_all_nodes() ファンクションへのアクセスが許可されている場合は、すべてのノードを独自に呼び出すことができます。

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

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

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

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

#  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

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

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

catchup_state は次のいずれかです。

= setup
= start
= catchup
= done

レプリケーションピアの監視¶

レプリケーションアクティビティの監視には、主に2つのビューが使用されます。

発信レプリケーションを監視するための :ref:``bdr.node_slots`<bdr.node_slots>`
着信レプリケーションを監視するための :ref:``bdr.subscription_summary`<bdr.subscription_summary>`

bdr.node_slots によって提供される情報のほとんどは、標準のPostgreSQLレプリケーション監視ビュー

pg_catalog.pg_stat_replication および pg_catalog.pg_replication_slots を照会することでも取得できます。

各ノードには1つのBDRグループスロットがあります。これは接続されるべきではなく、アクティブとしてマークされることはほとんどありません。これは正常であり、何かがダウンまたは切断されていることを意味するものではありません。: BDRによって作成されたレプリケーションスロットを参照してください。

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

送信レプリケーションアクティビティの監視に使用される追加のビューがあります。

発信レプリケーションを監視するための :ref:``bdr.node_replication_rates`<bdr.node_replication_rates>`

bdr.node_replication_rates ビューは、特にピアノードのキャッチアップ推定とともに、発信レプリケーションアクティビティの全体像を提供します。

#  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 列を使用することをお勧めします。以下で説明するように、他のフィールドも bdr.node_slots ビューを介して利用できます。

注釈

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

管理者は、ローカルノードからの発信レプリケーションについてbdr.node_slots に照会できます。現在のノードで認識されているグループ内の他のすべてのノードのレプリケーションステータスと、現在のノードでBDRによって作成された追加のレプリケーションスロットに関する情報を表示します。

#  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

BDRはメッシュネットワークであるため、クラスター内のラグを完全に把握するには、このクエリを参加しているすべてのノードで実行する必要があることに注意してください。

replay_lag_bytes は、ローカルサーバーの現在のWAL書き込み位置と、ピアノードによって再生された最後の位置であるreplay_lsn とのWAL位置の差を報告します。 replay_lag_size は、人間が判読できる形式です。 WALには通常、複製されないがまだreplay_lag_bytes でカウントされる多くの書き込みが含まれていることを理解することが重要です。セットなど。したがって、ここで報告されるバイト単位のラグは、ピアノードを最新の状態にするためにネットワークで複製する必要があるデータの量ではなく、処理が必要なサーバーサイド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 | replicating
- [ RECORD 2 ]-------+----------------------------
node_group_name     | bdrgroup
origin_name         | node3
sub_enabled         | t
sub_slot_name       | bdr_postgres_bdrgroup_node1
subscription_status | replicating

LCRを使用したWAL送信者の監視¶

デコードワーカーが有効になっている場合、各WAL送信者の現在のLCR（Logical Change Record

）ファイルに関する情報は、関数 bdr.wal_sender_stats を介して監視できます。

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 になります。これは、 Decoding Workerが有効になっていない場合、またはWAL送信者がロジカルスタンバイノードを提供している場合です。

さらに、 Decoding Workerに関する情報は、ファンクション 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)

BDRレプリケーションワーカーの監視¶

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

待機の理由がBDRに関連する場合、wait_event列に拡張された情報があります。
ライタプロセスがDDLを実行している場合を除き、 BDRワーカーではquery 列は空白になります

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

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

BDRライターの監視¶

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

ライタが属するサブスクリプションを識別するsub_name
ライタプロセスのpid
ライタが進行中のストリーミングトランザクションのアプリケーションをサポートしているかどうかを知るためのstreaming_allowed
ライタが現在ストリーミングトランザクションを適用しているかどうかを知るためのis_streaming
commit_queue_position は、コミットキュー内のライタの位置を確認します。

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

グローバルロックの監視¶

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

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

DDLロック、データベース内の永続的な（一時ではない）オブジェクト（つまり、テーブル）に対するすべてのDDL操作をシリアル化するために使用されます
DMLリレーションロック、リレーション定義を変更するDDL操作中にリレーションへの書き込みをロックアウトするために使用されます

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

ローカルノードで保持されているグローバルロックは、the ``bdr.global_locks` view </pgd/latest/overview/bdr/catalogs#bdrglobal_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
relation  | [NULL]
pid       | 15534
- [ RECORD 2 ]--------------
lock_type | GLOBAL_LOCK_DML
relation  | someschema.sometable
pid       | 15534

ロックのタイミング情報を含むすべてのフィールドの詳細については、カタログのドキュメントを参照してください。

競合の監視¶

レプリケーション競合の監視は、複数のノードが互いに相互作用できる方法で同じ行に影響を与える変更を行った場合に発生する可能性があります。 BDRシステムを監視して、競合を特定し、可能であれば、アプリケーションを変更して競合を解消するか、頻度を下げる必要があります。

デフォルトでは、すべての競合は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);

外部モニタリング¶

ユーザーが指定したメタデータを保存して、監視ツールがEDB Postgres分散クラスターを理解して監視できるようにすることができます。この情報を一元化することにより、外部ツールは単一のノードにアクセスし、特定の接続のネットワークコストや警告/アラームのしきい値など、クラスター全体に関する詳細を読み取ることができます。

bdr_superuser は、これらのファンクションとテーブルに対する権限を持っています。ビュー bdr.network_monitoring は、 bdr_read_all_stats ロールでもアクセスできます。

bdr.set_node_location¶

この関数は、ノードのメタデータをbdr.node_location に挿入します

概要¶

bdr.set_node_location(
    node_group_name text,
    node_name text,
    node_region text,
    node_location text);

パラメーター¶

node_group_name - BDRグループの名前
node_name - ノードの名前
node_region - データセンターサイトまたはリージョン
node_location - サーバー名、アベイラビリティーゾーンなど

bdr.set_network_path_info¶

このファンクションは、ノード間のネットワークパスのネットワークパスメタデータをテーブルbdr.network_path_info に挿入します。

概要¶

bdr.set_network_path_info(
    node_group_name text,
    region1 text,
    region2 text,
    location1 text,
    location2 text,
    network_cost numeric,
    warning_threshold numeric,
    alarm_threshold numeric)

パラメーター¶

node_group_name - BDRグループの名前
region1 - オリジンサーバー名
region2 - リモートサーバー名
location1 - 発信元データセンター名
location2 - リモートデータセンター名
network_cost - ネットワーク転送のコストを表す抽象値
warning_threshold - しきい値を上げるべき遅延
alarm_threshold - それを超えるとアラームが発生する遅延

bdr.network_monitoringビュー¶

このビューは、ノード間のネットワークパスに関する情報を収集します。

ロギングの構成は、 bdr.alter_node_set_log_config 関数で定義されます。

統計を適用¶

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

2つのモニタリングビューがあります。サブスクリプション統計用の bdr.stat_subscription とリレーション統計用の bdr.stat_relation です。これらのビューは両方とも次を提供します。

レプリケートされたINSERT/UPDATE/DELETE/TRUNCATEの数
ブロックアクセスとキャッシュヒット率
読み取り/書き込みの合計I / O時間
ファイルにストリーミングされた進行中のトランザクションの数
ライターにストリーミングされた進行中のトランザクションの数
コミット/中止された進行中のストリーミングトランザクションの数

リレーションの場合のみ、これらの統計：

リレーションのレプリケーションの処理にかかった合計時間
リレーション（のみ）のロック（ある場合）を取得するための合計ロック待機時間

サブスクリプションの場合のみ、これらの統計：

サブスクリプションにレプリケートされたCOMMIT / DDLの数
このサブスクリプションがアップストリームに接続した回数

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

これらの出力例は次のようになります。

#  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
ninsert   | 10
ncommit   | 5
nupdate   | 0
ndelete   | 0
ntruncate | 0
nddl      | 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の更新を示すテーブルの例を考えます。新しいノードがBDRグループに参加すると、新しいノードの同じテーブルの統計には、1Mの挿入とゼロの更新が表示されます。ただし、その瞬間から、一方の変更がもう一方の側に複製されるため、アップストリームとダウンストリームのテーブル統計は同じ量で変更されます。

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

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

pg_stat_user_indexes
pg_statio_user_indexes

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

BDRバージョンの監視¶

BDRを使用すると、同じクラスター内のノード間で異なる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     | 14.1             | 4.0.0
 node2     | 14.1             | 4.0.0

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

監視のために、次のアラートレベルをお勧めします。

status=UNKNOWN、message=このノードはBDRグループの一部ではありません
status=OK、message=すべてのノードが同じBDRバージョンを実行しています
status=WARNING、message=アクセスできないノードが少なくとも1つあります
status=WARNING、message=他のノードと比較すると異なるBDRバージョンを実行しているノードがあります

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

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

ラフトコンセンサスのモニタリング¶

Raft Consensusは常にクラスター全体で動作するはずです。 Raft Consensusを動作させずにEDB Postgres分散クラスターを実行した場合の影響は次のとおりです。

BDRデータ変更のレプリケーションはまだ正常に動作している可能性があります
グローバルDDL/DMLロックは機能しません
Gallocシーケンスは最終的にチャンクを使い果たします
Eager Replicationが機能しない
クラスターのメンテナンス操作（ノードへの参加、ノードの一部、スタンバイの昇格）は引き続き許可されますが、終了しない場合があります（単にハングします）

・BDRノード間でノードの状態が正しく同期しない場合がある

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

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

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

以下の条件がすべて満たされている場合、Raft Consensusは正しく機能していると言えます。

すべてのノードで有効な状態（RAFT_LEADER またはRAFT_FOLLOWER ）が定義されています
ノードの1つだけがRAFT_LEADER
leader_id はすべての行で同じであり、state = RAFT_LEADER が含まれる行のnode_id と一致する必要があります

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

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

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

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

Raftコンセンサスがクラスター操作タスクにどのように影響するか、およびRaftコンセンサスがグループスロットを進める責任があるため、次のようにモニタリングアラートレベルを定義できます。

status=UNKNOWN、message=このノードはBDRグループの一部ではありません
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 から返されたRaftコンセンサスステータス情報を使用して、クラスター全体のRaftチェックを提供します。例：

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

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

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

アクティブなBDRピアごとに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> に従いますが、 BDRグループスロット名は規則bdr_<DATABASE>_<GROUP> に従います。これには、関数bdr.local_group_slot_name() を使用してアクセスできます。

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

対応するピアがシャットダウンされているか、アクセスできません。または
BDRのレプリケーションが壊れています。

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

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

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

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の監視¶

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

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

Monitoring¶

モニタリングの概要¶

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

レプリケーションピアの監視¶

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

着信レプリケーションの監視¶

LCRを使用したWAL送信者の監視¶

BDRレプリケーションワーカーの監視¶

BDRライターの監視¶

グローバルロックの監視¶

競合の監視¶

外部モニタリング¶

bdr.set_node_location¶

概要¶

パラメーター¶

bdr.set_network_path_info¶

概要¶

パラメーター¶

bdr.network_monitoringビュー¶

統計を適用¶

標準のPostgreSQL統計ビュー¶

BDRバージョンの監視¶

ラフトコンセンサスのモニタリング¶

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

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

前のトピックへ

次のトピックへ

目次