レプリカセットの各ノードにはそれぞれ状態があります。
| 番号 | 名前 | 状態の説明 | 
|---|---|---|
| 0 | まだどのセットのアクティブなメンバーでもない。 すべてのノードがこの状態で起動します。 は | |
| 1 | ステートプライマリのノードは、書込み操作を受け付けることができる唯一のノードです。これらのノードには、投票資格があります。 | |
| 2 | 状態セカンダリのノードは、データ ストアをレプリケートします。これらのノードには、投票資格があります。 | |
| 3 | ||
| 5 | ノードは最初の同期を実行中です。 レプリカセットに新しく追加された場合を除き、投票資格があります。 | |
| 6 | セットの別のノードから見て、ノードの状態はまだわかりません。 | |
| 7 | アービタはデータをレプリケートせず、選挙に参加するためだけに存在します。これらのノードには、投票資格があります。 | |
| 8 | セット内の別のノードから見て、そのノードは到達不可能です。 | |
| 9 | ||
| 10 | このノードはかつてレプリカセットに含まれていましたが、その後削除されました。 | 
状態
コア状態
- PRIMARY
- PRIMARY状態のノードは書込み操作を受け入れます。レプリカセットには、一度に最大 1 つのプライマリが含まれます。[ 1 ]- SECONDARYノードは選挙後にプライマリになります。- PRIMARY状態のノードには投票資格があります。
- SECONDARY
- SECONDARY状態のノードはプライマリのデータセットをレプリケートし、読み取り操作を受け入れるように構成できます。予備選挙では投票資格があり、予備選挙が利用できなくなった場合には- PRIMARYステートに選出される可能性があります。
- ARBITER
- ARBITER状態のメンバーは、データを複製したり、書込み操作を受け入れたりしません。 これらは投票資格があり、選挙中に均衡を破るためにのみ存在します。 レプリカセットでは、セットに偶数の投票ノードがあり、関連する選挙が発生する可能性がある場合にのみ、- ARBITER状態のノードが必要です。 レプリカセットには最大で 1 つのアービタのみを構成する必要があります。 アービタを使用する際の考慮事項については、「レプリカセット アービタ 」を参照してください。
コア状態について詳しくは、「レプリカセット ノード」を参照してください。
その他の状態
- STARTUP
- レプリカセットの各ノードは、 - STARTUP状態で起動します。次に、- mongodはそのノードのレプリカセット構成を読み込み、ノードの状態を- STARTUP2または- ARBITERに移行します。- STARTUPのノードは、どのレプリカセットでも認識されたノードではないため、投票する資格がありません。
- STARTUP2
- バージョン 5.0 での変更。 - レプリカセットの各データを保持するノードは、 がそのノードの構成の読み込みを完了するとすぐに - STARTUP2- mongod状態になります。- 次に、メンバーは最初の同期を実行するかどうかを決定します。 メンバーが最初の同期を開始した場合、すべてのデータがコピーされ、すべてのインデックスが構築されるまで、そのメンバーは - STARTUP2に残ります。 その後、メンバーは- RECOVERINGに移行します。- STARTUP2に新しく追加されたノードには投票資格がなく、投票できません。初期同期プロセス中に選択されます。MongoDB 5.0 より以前のバージョンでは、- STARTUP2のノードには投票資格がありました。
- RECOVERING
- レプリカセットのノードは、読み取りを受け入れる準備ができていない場合、 - RECOVERING状態になります。- RECOVERING状態は通常の操作中に発生する可能性があり、必ずしもエラー状態を反映しているわけではありません。- RECOVERING状態のノードは選挙で投票する資格がありますが、- PRIMARY状態になる資格はありません。- ノードは、クライアント読み取りのデータの一貫したビューを保証するために十分なデータをレプリケートした後、 - RECOVERINGから- SECONDARYに移行します。- RECOVERING状態と- SECONDARY状態の唯一の違いは、- RECOVERINGではクライアントの読み取りが禁止される一方で、- SECONDARYでは許可されることです。- SECONDARY状態は、プライマリに関するデータの古さについては何も保証しません。- 過負荷のため、セカンダリがレプリカセットの他のノードより大幅に遅れる可能性があり、セットの残りの部分と再同期する必要がある場合があります。このような状況が発生すると、ノードは - RECOVERING状態になり、手動による介入が必要になります。
エラー状態
エラー状態のノードは投票できません。
- UNKNOWN
- レプリカセットにステータス情報を通信したことがないノードは - UNKNOWN状態です。
- DOWN
- レプリカセットへの接続を失ったノードは、セットの残りのノードからは - DOWNと認識されます。
- REMOVED
- レプリカセットから削除されたノードは、 - REMOVED状態になります。ノードが- REMOVED状態になると、ログにはこのイベントが- replSet REMOVEDメッセージ エントリでマークされます。
| [1] | 状況によっては、 replica set内の 2 つのノードが一時的に自分たちがプライマリであると認識することがありますが、最大でそのうちの 1 つが { w:
"majority" }書き込み懸念で書き込みを完了できます。{ w: "majority" }書き込みを完了できるノードは現在のプライマリであり、もう一方のノードは、通常はネットワークパーティションが原因で降格をまだ認識していない以前のプライマリです。これが発生すると、以前のプライマリに接続するクライアントは、読み取り設定primaryを要求したにもかかわらず、古いデータを検出する可能性があり、以前のプライマリへの新しい書き込みは最終的にロールバックされます。 |