レプリカセットでは、プライマリが降格したり使用できなくなったりすると、時々 の選挙が実行されます。選挙中 、レプリカセットは新しいプライマリを正常に選択するまで書き込みを受け付けませんが、構成されている場合はほとんどの読み取りはセカンダリで続行できます。
頻度が低いフェイルオーバーや計画的なメンテナンス中にこの動作が発生することが予想されます。ただし、頻繁に選挙で使用されると、プライマリが 通常の操作中に頻繁に変更されるため、繰り返しの書込み中断が発生し、場合によってはコミットされていないデータのロールバックが発生します。
このページには、高速診断を提供し、アプリケーションの書込み中断を回避するために、一般的な問題と解決策が含まれています。次のセクションを確認した後に追加のサポートが必要な場合は、テクニカル サポートにお問い合わせください。
前提条件チェック
正常なクラスターでは、頻度が低く、期待どおりのイベントが発生している間のみ選挙が行われます。選挙は通常、次のシナリオで行われます。
初期設定
メンテナンス操作（
rs.stepDown()やrs.reconfig()など）による新しいノードの追加
rs.add()設定された
timeoutよりも長時間プライマリが使用できないようになりました（デフォルトは 10 秒）
replSetGetStatusrs.status()これらのシナリオ以外で、 メソッドまたは メソッドを 1 時間以内または 1 日中などの設定された期間にわたって複数回実行中、配置で頻繁に選挙が発生していることを確認します。報告されたプライマリの_id 値を毎回比較して、プライマリノードが変更された場合といつ変更されるかを追跡します。これは選挙が発生したことを意味します。
注意
MongoDB Ops Manager で TOO_MANY_ELECTIONSアラートが表示されている場合は、頻繁に選挙が行われている可能性があります。
ログ メッセージの確認
また、コンポーネント（"c" ）の値がELECTION であるエントリについては、配置のログメッセージを参照することもできます。ログに次のメッセージが短い間隔で複数回表示される場合（1 時間ごとの複数回、または計画的なメンテナンスがない日に複数回表示される場合）、これは通常、ネットワーク不安定、正常でないホスト、または誤った構成が原因でレプリカセットが正常ではないことを示します。
メッセージ | 説明 |
|---|---|
「選挙のタイムアウト期間にプライマリが見つからないため、選挙を開始します」 | プライマリが降格したときに他のノードによってログに記録されます。 |
「セカンダリからプライマリへの移行」 | 新しいプライマリが引き継ぎます。 |
「セットの過半数が表示されないため、プライマリを廃止します」 | 以前のプライマリはセカンダリになります。 |
一般的な問題と解決策
次のセクションでは、レプリカセットが予期せず頻繁に選挙を実行する可能性がある一般的な問題について説明します。サポートに連絡する前に、次の結果、 レプリカセットで頻繁に選挙が行われているかどうかを確認してください。
リソース枯渇
集中的なクエリ、大規模な集計、インデックスのビルドやバックアップなどのバックグラウンドのタスクは、高 CPU 使用率、ディスクレイテンシや障害、メモリ負荷につながる可能性があります。リソースが枯渇すると、プライマリが応答しないか、時間内にハートビートを処理できなくなる可能性があるため、頻繁に選挙が発生する可能性があります。
非効率的なクエリ
以下の方法で、非効率的なクエリによってリソースが枯渇しているかどうかを確認します。
ログでコンポーネント（"c"）の値が
COMMANDであるエントリを探します。各エントリについて、
bytesReadフィールドは特定の コマンドが読み取ったバイト数を示します。bytesReadの値が大きいコマンドに注意します。非効率的なクエリのタイムスタンプが複数の選挙のタイムスタンプに近い場合、非効率的なクエリによって頻繁に選挙が行われる可能性があります。
次のリソースを使用して、クエリを最適化します。
ESR ガイドラインを確認して新しいインデックスを作成します。
Atlas では、最新のワークロードに基づいてインデックスの提案について、 Performance Advisor を定期的に確認してください。
レプリカセットの誤構成
ノードの優先順位
レプリカセットは、最も優先順位が高いノードを選出するまで、継続的に選挙を呼び出します。ノードの優先順位を適切に設定しないと、選挙がより頻繁に行われ、予期しないノードがプライマリになる可能性があります。
各メンバーの優先順位の値を確認するには、 コマンドまたは メソッドを実行します。次の例は、優先順位が誤って構成されたレプリカセットに対するreplSetGetConfig rs.conf()メソッドの出力を示しています。rs.conf()
rs.conf().members
[ { _id: 0, host: "rs0-0.example.net:27017", arbiterOnly: false, buildIndexes: true, hidden: false, priority: 1, tags: { dc: "primaryDC" }, secondaryDelaySecs: Long(0), votes: 1 }, { _id: 1, host: "rs0-1.example.net:27017", arbiterOnly: false, buildIndexes: true, hidden: false, priority: 10, tags: { dc: "remoteDC1" }, secondaryDelaySecs: Long(0), votes: 1 }, { _id: 2, host: "rs0-2.example.net:27017", arbiterOnly: false, buildIndexes: true, hidden: false, priority: 9, tags: { dc: "remoteDC2" }, secondaryDelaySecs: Long(0), votes: 1 }, { _id: 3, host: "rs0-3.example.net:27017", arbiterOnly: false, buildIndexes: true, hidden: false, priority: 8, tags: { dc: "analyticsDC" }, secondaryDelaySecs: Long(0), votes: 1 } ]
上記の例では 、現在のプライマリは他の 3 つのノードよりも優先順位が低くなります。優先順位の高いセカンダリが正常で、セカンダリ 状態にある場合は、選挙をトリガーして 、プライマリを引き継ぐことができます。
レプリカセットノードの優先順位が適切に構成されていることを確認します。
一貫してプライマリとして機能するサーバーに最も優先順位を割り当てます
プライマリになる可能性を減らすために、他のノードにデフォルト以下の優先順位を割り当てます
優先順位の高いレプリケーションラグの高いノードを割り当てる
レプリカセット設定
レプリカセットの構成設定を確認するには、replSetGetConfig コマンドまたはrs.conf() メソッドを実行します。次の例では、electionTimeoutMillis が低すぎるように構成されているレプリカセットを示しています。
rs.conf().settings
{ chainingAllowed: true, heartbeatIntervalMillis: 2000, heartbeatTimeoutSecs: 10, electionTimeoutMillis: 1500, // lower than a single heartbeat cycle catchUpTimeoutMillis: 2000, getLastErrorModes: { }, getLastErrorDefaults: { w: 1, wtimeout: 0 }, replicaSetId: ObjectId("58858acc1f5609ed986b641b") }
settings.electionTimeoutMillisの値が低すぎないことを確認します。上記の例では 、settings.electionTimeoutMillis の値はsettings.heartbeatIntervalMillis より小さいです。つまり、ノードは完全なハートビート間隔が完了する前にプライマリの「ダウン」を宣言し、不要な選挙が発生します。
ネットワークのパーティショニングまたはレイテンシ
配置でネットワークパーティションが発生したり、ノードでハートビート メッセージが遅延したりすると、セカンダリはプライマリを使用できないと誤って表示し、選挙を開始する可能性があります。
ネットワーク パーティションが発生していることを確認するには、以下の手順を実行します。
ログで次のメッセージがよく表示されているかどうかを確認してください。
メッセージ説明「選挙のタイムアウト期間にプライマリが見つからないため、選挙を開始します」
セカンダリ は、設定された タイムアウトウィンドウ内にプライマリからハートビートを受信しなかったため選挙を開始しました。
「セットの過半数が表示されないため、プライマリを廃止します」
プライマリが降格したのは、投票権のあるセカンダリの過半数と通信できないためです。
rs.status()異なるノードからreplSetGetStatusまたは を実行すると、アクセス可能なノードの異なるビューが表示されます。これは、ノードのサブセット間で分裂ことを示します。
パーティション後に接続を復元するには、次の手順に従います。
ノード間の通信をブロックする可能性のあるルールがないか、ファイアウォールの構成を確認してください。
DNS ホスト名を確認します。
IPアドレスがIPアクセス リストに追加されていることを確認してください。
解決策を確認する
原因に対処した後、rs.status() を再実行して、頻繁に選挙が行われなくなることを確認します。出力には、プライマリ状態のメンバーが 1 つだけ表示され、プライマリが通常の観察ウィンドウにわたって安定した状態であり、計画されていない変更がないことが示されます。
配置ログを参照することもできます。配置ログで上記のログメッセージを調べて、選挙が短い間隔で複数回発生しないことを確認してください。
より多くのサポートのために収集する診断情報
まだ問題を解決できない場合は、テクニカル サポートに次の診断情報を提供にお問い合わせください。
影響を受ける期間に関する関連するログメッセージ
rs.config()出力rs.status()出力