Monitoring¶

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

例、レプリケーションスロットが大幅に遅れスタートた場合に管理者に警告が発せられ、事前に対策を講じることが保証に、自動モニタリングを実施することが重要です。

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

監視の概要¶

BDRグループは、多くの場合ノードと呼ばれるマルチプルのサーバーで構成されます。グループ全体の健全性を保証には、すべてのノードを監視する必要があります。

bdr_monitorロールは、bdr.monitor関数を実行して、3つのレベルのいずれかを使用してBDRの健全性の評価を提供します。

OK-しばしば緑と表示される
WARNING-しばしば黄色として表示される
CRITICAL-しばしば赤と表示される
UNKNOWNと同様に-認識されない状況の場合、多くの場合赤と表示されます

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

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

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

ノードの参加と削除の監視¶

デフォルトでは、ノード管理機能は、結合またはパート操作が完了するまで待機します。これは、それぞれの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

また、テーブル`bdr.node_catchup_info <catalogs>`__は、キャッチアップ状態に関する情報を提供します。これは、ノードの結合またはノードの分離に関連する可能性があります。

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

catchup_stateは次のいずれかです。

= setup
= start
= catchup
= done

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

レプリケーションアクティビティのモニタリングに使用される2つの主なビューがあります。

発信レプリケーションをモニタリングするための`bdr.node_slots <catalogs>`__
着信レプリケーションをモニタリングするための`bdr.subscription_summary <catalogs>`__

bdr.node_slotsによって提供される情報のほとんどは、標準のPostgreSQLレプリケーションモニタリングビューへのクエリによっても取得できます。

各ノードにはBDRグループスロットが1つありますが、これには接続しないでください。また、アクティブとしてマークされることはほとんどありません。これは正常であり、何かがダウンしたり切断されたりすることを意味するものではありません。 `Replication Slots created by BDR <nodes>`__を参照してください。

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

発信レプリケーションアクティビティのモニタリングに使用される追加のビューがあります。

発信レプリケーションをモニタリングするための`bdr.node_replication_rates <catalogs>`__

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秒あたりのバイト数のレートを示します。それは同等ながローカルノードからデータを消費しているrateatです。ノードがクラスターに再接続するときのreplay_lagはすぐにゼロに設定されます。この情報の修正に取り組んでいます。回避策として、同等ながローカルノードデータに追いつくのに必要な時間を参照するcatchup_intervalcolumnを使用することをお勧めしノード。以下に説明するように、他のフィールドもbdr.node_slotsviewを介して利用できます。

!!! Note * このカタログは、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には通常、複製されないが、VACUUMアクティビティ、インデックスの変更、同じノード上の他のデータベースに関連付けられた書き込み、レプリケーションセットのパートではないテーブルの書き込みなど、replay_lag_bytesでカウントされる書き込みが多数含まれることを理解することが重要ですしたがって、ここで報告されるバイトの遅れは、同等なを最新のノードにするためにワイヤ上で複製する必要があるデータの量ではなく、処理する必要があるサーバサイドのWALの量のみです。

同様に、ノードは、同等ながキャッチアップするのにかかる時間、またはbdr.node_slotsが照会されたときに現在の位置から書き込み位置にリプレイするのにかかる時間の測定値ではありません。同等なが最新のコミットと現在の壁時計時間を確認したときの遅延を測定します。 bdr.node_replication_ratesのreplay_lag_bytesおよびreplay_lag_sizeまたはcatchup_intervalをモニタことをお勧めします。これは、ノードが再接続した直後にこの列がゼロに設定されるためです。

ロジカルレプリケーションがトランザクションをストリーミングしている間、バイトと時間の両方の遅れは進みません。コミットがレプリケートされるときにのみ変更されます。そのため、遅延は「鋸歯状」になる傾向があり、トランザクションがストリーミングされると上昇し、同等ながコミットしてフラッシュし、確認をノードすると再び下降します。報告されたLSN位置は、同様の理由でスムーズに進むのではなく「階段状」になります。

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

注：restart_lsnが他のノード列の背後にあるのは正常です。これは、レプリケーションまたは同等なの遅延の問題を示すものではありません。 restart_lsnは、PostgreSQLの内部ロジカルデコーディングが中断された場合にWALを読み取る必要がある位置であり、通常、まだ複製およびフラッシュされていない最も古いトランザクションの位置を反映します。非常に古いmakeは、切断後のレプリケーションのリスタートを遅くし、望ましい以上のWALを保持することができますが、そうでなければ無害になります。

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

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

#  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（）ファイルに関する情報は、ファンクションを介して監視できます。例：

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送信者が[ロジカルスタンバイ] （nodes.md＃Logical Standby Nodes）を提供している場合です。

さらに、デコードワーカーに関する情報は、functionbdr.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ワーカーは、bdr.stat_activityと同じ列と情報コンテンツを持つシステムビューbdr.stat_activityに表示されます。したがって、このビューはBDRシステムの状態に関するこれらの洞察を提供します。

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

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

ビューbdr.worker_errorsは、作業の継続に問題があるワーカーによって報告されたエラー（ある場合）を示します。このビューではアクティブなエラーのみが可視されるため、ワーカーに一時的な問題があったが回復した場合、ビューは空になります。

BDRライターの監視¶

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

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

BDRは、オリジンに追加された同じコミットオーダーに従うことにより、コミット順序付けを尊重します。並列ライターの場合、マルチプルのライターが異なるトランザクションを同時に適用する必要があります。 commit_queue_positionは、コミットオーダーを示します。値0は、ライタが最初にコミットを意味します。値-1は、コミット位置がまだ不明であることを意味します。これは、ストリーミングトランザクションまたはライタがその時点でトランザクションを適用していない場合に発生する可能性があります。

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

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

現在、グローバルロックには2つのタイプがあります。

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

DDLオペレーションのタイプとbdr.ddl_locking設定の値に応じて、同じトランザクションに対してどちらかまたは両方のエントリータイプを作成できます。

ローカルノードで保持されているグローバルロックは、に可視されます。このビューには、ロックのタイプが表示されます。関係ロックは、どのリレーションがロックされているか、ロックを保持しているPID（ローカルの場合）、およびロックがグローバルに許可されているかどうかを示します。グローバルアドバイザリロックの場合、列はロックが取得されるアドバイザリキーを示しキー。

以下は、bdr.ddl_locking = onでanALTER 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

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

競合の監視¶

レプリケーションconflictsは、マルチプルのノードが相互に対話できる方法で同じ行に影響を与える変更を行う場合に発生する可能性があります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');

外部モニタリング¶

ユーザーが提供したメタデータを保存して、モニタリングツールがBDRクラスターを理解およびモニタできるようにすることができます。この情報を集中化することにより、externaltoolsは任意の単一ノードにアクセスし、特定の接続のネットワークコストやワーニング/アラームしきい値など、クラスター全体に関する詳細を読み取ることができます。

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 GUCsbdr.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統計Views¶

テーブルおよびインデックスの使用に関する統計は、通常、downstreammasterによって更新されます。これは、autovacuumの正しいファンクションに不可欠です。ダウンストリームマスタにローカル書き込みがなく、統計がリセットされていない場合、これらの2つのビューはアップストリームとダウンストリームの対応する結果を表示する必要があります。

pg_stat_user_tables
pg_statio_user_tables

!!! Note * アップストリームテーブルの統計がダウンストリーム統計と同様であるとは必ずしも期待していません。同じ量だけ変化することを期待しています。統計が1Mの挿入と1Mの更新を示すテーブルの例を考えてください。新しいノードがBDRグループに参加すると、新しいノードの同じテーブルの統計には1Mの挿入とゼロの更新が表示されます。ただし、その瞬間から、アップストリームとダウンストリームのテーブル統計は同じ量だけ変化します。一方の側のすべての変更が他方の側に複製されるためです。

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

ビルトインのインデックスモニタリングビューは次のとおりです。

pg_stat_user_indexes
pg_statio_user_indexes

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

BDRバージョンの監視¶

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

ビューbdr.group_versions_detailsはfunctionbdr.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、メッセージ=このノードはBDRグループのパートではありません
status = OK、メッセージ=すべてのノードが同じBDRバージョンを実行しています
status = WARNING、メッセージ=アクセスできないノードが少なくとも1つあります
status = WARNING、メッセージ =異なるBDRバージョンを実行しているノードがあります他のノードと比較した場合

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

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

ラフトコンセンサスの監視¶

Raft Consensusは常にクラスタ全体で機能する必要があります。 Raft Consensusが機能しない状態でBDRクラスターを実行した場合の影響は次のとおりです。

BDRデータ変更のレプリケーションはまだ正常に機能している可能性があります - グローバルDDL/ DMLロックは機能しません - Gallocシーケンスは最終的にチャンクを使い果たします - Eager Replicationは機能しません - クラスターメンテナンス操作（結合ノード、パートノード、スタンバイのプロモート）まだ許可されていますが、終了しない可能性があります（単にハングします） BDRノード間でノードステータスが正しく同期されない場合があります BDRグループレプリケーションスロットはLSNを進めないため、WALファイルを保持しますディスク

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

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_LEADERまたはRAFT_FOLLOWER）が定義されていますノード
ノードの1つだけがRAFT_LEADERです
leader_idはすべての行で同じであり、node_idとマッチする必要があります state = RAFT_LEADERがある行の

Raft Consensusは、随時、新しい選挙をスタートして、新しいRAFT_LEADERを定義します。選挙中に、RAFT_LEADERが存在せず、一部のノードが自分自身をRAFT_CANDIDATEと見なす仲介者がいる場合があります。選挙全体がbdr.raft_election_timeoutより長くかかることはありません（デフォルトでは6秒に設定されています）。上記のクエリーで選挙中のシチュエーションが返された場合は、edbdr.raft_election_timeoutを待ってから再度クエリーを実行します。 afterbdr.raft_election_timeoutが過ぎても上記の条件のいくつかがまだ満たされていない場合、Raft Consensusは機能していません。

Raft Consensusは、単一のノードでのみ正常に動作しない場合があります。例、ノードの1つが現在のリーダーを認識せず、自分自身をRAFT_CANDIDATEと見なします。この場合、次のことを確認することが重要です。

すべてのBDRノードは、通常およびレプリケーション接続（ファイルpg_hba.confを確認） BDRバージョンはすべてのノードで同じです
bdr.raft_election_timeoutはすべてのノードで同じです

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

Raft Consensusがクラスターの運用タスクにどのように影響し、asRaft Consensusがグループスロットを進める責任があるかを考えると、モニタリングアラートレベルを次のように定義できます。

status = UNKNOWN、メッセージ=このノードはBDRグループのパートではありません
status = OK、メッセージ= Raft Consensusは正常に機能しています
status = WARNING、メッセージ=アクセスできないノードが少なくとも1つあります
status = WARNING、メッセージ= RAFT_CANDIDATEとしてノードがあり、選挙が進行中の可能性があります
status = WARNING、メッセージ= RAFT_LEADERはありません。選挙は進行中
status = CRITICAL、メッセージ= Raft Consensusに単一のノードがあります
status = CRITICAL、メッセージ= RAFT_CANDIDATEとしてノードがありますが、 RAFT_LEADERが定義されています
status = CRITICAL、メッセージ=異なるリーダーに続くノードがあります RAFT_LEADERとしてノードセットよりも

説明した動作は、bdr.group_raft_detailsビューから返されたRaftコンセンサスステータス情報を使用してクラスタ全体のRaftチェックを提供するfunctionbdr.monitor_group_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グループスロット名前はfunctionbdr.local_group_slot_name()を使用してアクセスできるConventionbdr_<DATABASE>_<GROUP>に従います。

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

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

ERRORまたはFATALのログファイルをGrepし、すべてのノードでbdr.worker_errorsも確認します。ルート原因は、例、ノードの1つで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

トランザクションのコミットの監視¶

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

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

Monitoring¶

監視の概要¶

ノードの参加と削除の監視¶

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

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

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

LCRを使用してWAL送信者を監視する¶

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

BDRライターの監視¶

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

競合の監視¶

外部モニタリング¶

bdr.set_node_location¶

あらすじ¶

パラメーター¶

bdr.set_network_path_info¶

あらすじ¶

パラメーター¶

bdr.network_monitoringビュー¶

統計を適用する¶

標準のPostgreSQL統計Views¶

BDRバージョンの監視¶

ラフトコンセンサスの監視¶

レプリケーションスロットの監視¶

トランザクションのコミットの監視¶

前のトピックへ

次のトピックへ

目次