Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/
管理
Docs Home
/
管理
Docs Home
/
管理

プライマリがないレプリカセットのトラブルシューティング

レプリカセットは、通常は選挙中に、プライマリが存在しない状態になることがあります。ただし、プライマリが長期間存在しない場合、レプリカセットは書き込みを受け入れることができません。

このページでは、長期間にわたってプライマリがないレプリカセットのトラブルシューティングのための一般的な問題と解決策が記載されています。以下のセクションを行った後に追加のサポートが必要な場合は、 テクニカル サポートにお問い合わせください。

前提条件チェック

replSetGetStatusまたはrs.status() メソッドを実行中て、配置にプライマリがないことを確認します。次の例では、プライマリがないレプリカセットに対するrs.status() メソッドの出力を示しています。

rs.status().members
[
   {
      _id: 0,
      name: 'localhost:27018',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      ...
      configVersion: 2,
      configTerm: 6,
      self: true,
      lastHeartbeatMessage: ''
   },
   {
      _id: 1,
      name: 'localhost:27019',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      ...
      configVersion: 2,
      configTerm: 6
             },
             {
      _id: 2,
      name: 'localhost:27020',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      ...
      configVersion: 2,
      configTerm: 6
             }
     ]

注意

場合によっては、rs.status() 出力に一部のノードのstateStr 値がUNKNOWN またはDOWN として表示されることがあります。

ログ メッセージの確認

配置のログメッセージで、コンポーネント（"c" ）の値がELECTION であるエントリを確認します。ここでは、 フィールドに次のメッセージとともに選挙を開始しようとする繰り返しの試行が見つかる場合があります。"msg"

メッセージ
説明

「選挙のタイムアウト期間にプライマリが見つからないため、選挙を開始します」

プライマリが降格したときに他のノードによってログに記録されます。

「投票数が不足しました」

過半数のノードが選挙リクエストに応答しなかったことを示します。ノードがダウンしているか、ネットワークパーティションが発生している可能性があります。

「セットの過半数が表示されないため、プライマリを廃止します」

ノードがダウンしているか、ネットワークパーティションが発生している可能性があります。

一般的な問題と解決策

次のセクションでは、レプリカセットで新しいプライマリの選択が困難になる可能性のある一般的な問題とその解決方法について説明します。サポートに連絡する前に、次の問題が配置でプライマリ選択を妨げているかどうかを確認してください。

ネットワークパーティション

配置にネットワークパーティションがある場合、ノードは相互に通信できなくなり、プライマリを選択できなくなります。

配置がネットワークパーティションの影響を受けているかどうかを確認するには、別のノードから メソッドまたはreplSetGetStatus rs.status()メソッドを実行します。各ノードからの出力に基づいて、どのノードがパーティションの各側にあるかを識別します。

パーティション後に接続を復元するには、次の手順に従います。

  • ノード間の通信をブロックするルールがないか、ファイアウォール構成を確認してください。

  • DNS ホスト名を確認します。

  • IPアドレスがIPアクセス リストに追加されていることを確認してください。

Tip

過半数のノードが相互に到達できると、 MongoDB は自動的にプライマリを選択し、書き込みを正常に再開します。

昇格資格のあるセカンダリがありません

メインのデータセンターに、投票権を持つノードとプライマリになる資格のあるノードの両方の定足数が含まれていることを確認します。レプリカセットのプライマリがダウンし、どのセカンダリもプライマリに選出されない場合は、残りのノードがすべての優先順位 0メンバーではないことを確認します。

各メンバーの優先順位の値を確認するには、replSetGetConfig コマンドまたはrs.conf() メソッドを実行します。

// Returns an array of documents corresponding with each member in your replica set
rs.conf().members
[
   ...
   {
      _id: 1,
      host: localhost:27019,
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 0,
      tags: {},
      secondaryDelaySecs: Long('0'),
      votes: 1
   },
   ...
]

優先順位によりプライマリになる資格のあるセカンダリがない場合は、1 つ以上のセカンダリのmembers[n].priority 値を更新します。詳細な方法については、「 自己管理型レプリカセット ノードの優先度の調整 」を参照してください。

リソース枯渇

配置に書き込み負荷の高いワークロード、インデックスが多すぎる、またはメンテナンス プロセスが大量のディスク領域を消費する場合、ノードが限界に達してノードがクラッシュする可能性があります。

ディスク領域を再利用するには、次のことを検討してください。

  • 未使用のコレクションまたはデータベースを削除します。

  • 重複するインデックスまたは未使用のインデックスを排除します。

ディスク使用量を監視するには:

  • AtlasDisk Usage では、 クラスター モニタリングで利用可能な チャートを表示できます。

  • 自己管理型配置では、dbStats コマンドまたはdb.stats() メソッドを実行します。

過半数の損失

複数の投票メンバーがダウンし、レプリカセットが過半数 を失った場合、rs.status() の出力にはすべてのメンバーが SECONDARY または RECOVERING 状態であることが表示されることがあります。次のシナリオでは、過半数の が失われる可能性があります。

ローリング メンテナンスが誤って実行された

例、3 つのノードからなるレプリカセットで、メンテナンスのために同時に 2 つのノードをダウンさせると考えられます。このシナリオでは、レプリカセットは過半数を失い、3 番目のノードがバックアップされるまで新しいプライマリを選出できなくなります。

このシナリオを回避するには、セカンダリ ノード、プライマリ ノードで終了するよう、ローリング メンテナンスを順次実行するようにします。これにより、プライマリは常に使用可能になります。レプリカセットのメンテナンスに関するガイダンスは、「 自己管理型レプリカセット メンバーのメンテナンスの実行 」を参照してください。

過プロビジョニングされたクラスター トポロジー

例、データを保持する ノードが 2 つと 非表示の投票ノードが 1 つある配置を考えてみましょう。データを保持するノードが 1 つ失敗した場合、残りのノードが過半数を形成できません。

書込み保証 (write concern)を使用するプライマリ セカンダリ アービタ（PSA）トポロジーでは、メンテナンスのためにセカンダリがダウンすると、書込みが停止します。データを保持する投票ノードが"majority" 2 つのうち 1 つしか使用できないため、プライマリは過半数の承認を得ることができません。書き込み操作に wtimeout を設定しない場合、書込みは無期限にブロックされます。これを軽減するには、以下の手順を行います。

  • 停止した書込みの量を制限するために、メンテナンスウィンドウ中に書込み操作を制限します。

  • "majority"書込み保証 (write concern)を使用する書込み操作に wtimeout パラメータを設定して、書込みが無期限にブロックされるのを防ぎます。

PSA トポロジーのパフォーマンスの問題の軽減の詳細については、「 自己管理型 PSA レプリカセットのパフォーマンスの問題の軽減 」を参照してください。

プライマリ セカンダリ セカンダリ セカンダリ アービタ（PSSSA）トポロジーでは、投票権のあるノードの過半数を単一のデータセンターまたは障害復旧（DR）サイトに配置すると、過半数が失われるリスクが生じます。そのリージョンが完全にダウンすると、残りのノードは過半数を形成できず、プライマリを選出できません。投票ノードを複数のリージョンに分散させると、単一リージョンで障害が発生しても過半数が利用可能であり、ガイダンスについては、「 データセンターの認識 」を参照してください。

解決策を確認する

配置が復元され、新しいプライマリが選択されると、rs.status() の出力は、ノードの 1 つが PRIMARY 状態であることを示します。

より多くのサポートのために収集する診断情報

問題を解決できない場合は、テクニカル サポートに次の診断情報を提供にお問い合わせください。

  • 関連するログメッセージ

  • rs.config() 出力

  • rs.status() 出力

関連する問題

詳細

戻る

頻繁に行われる選挙

次へ

Replication Lag

項目一覧