レプリカセットノードの状態

レプリカセットの各ノードにはそれぞれ状態があります。

番号	名前	状態の説明
0	`STARTUP`	まだどのセットのアクティブなメンバーでもない。すべてのノードがこの状態で起動します。 `mongod`は `STARTUP` にあるときにレプリカセット構成ドキュメントを解析します
1	`PRIMARY`	ステートプライマリのノードは、書込み操作を受け付けることができる唯一のノードです。これらのノードには、投票資格があります。
2	`SECONDARY`	状態セカンダリのノードは、データストアをレプリケートします。これらのノードには、投票資格があります。
3	`RECOVERING`	ノードは、起動時のセルフチェックを実行するか、ロールバックまたは再同期の完了から移行します。このノードからの読み取りにはデータを使用できません。これらのノードには、投票資格があります。
5	`STARTUP2`	ノードは最初の同期を実行中です。レプリカセットに新しく追加された場合を除き、投票資格があります。
6	`UNKNOWN`	セットの別のノードから見て、ノードの状態はまだわかりません。
7	`ARBITER`	アービタはデータをレプリケートせず、選挙に参加するためだけに存在します。これらのノードには、投票資格があります。
8	`DOWN`	セット内の別のノードから見て、そのノードは到達不可能です。
9	`ROLLBACK`	このノードはロールバックを積極的に実行します。これらのノードには、投票資格があります。このノードからの読み取りにはデータを使用できません。バージョン4.2以降、 MongoDB は、ノードが`ROLLBACK`状態になると、進行中のすべてのユーザー操作を強制終了します。
10	`REMOVED`	このノードはかつてレプリカセットに含まれていましたが、その後削除されました。

状態

コア状態

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 状態になり、手動による介入が必要になります。

ROLLBACK

レプリカセットが選挙でプライマリを置き換えるたびに、古いプライマリにはセカンダリメンバーに複製されなかったドキュメントが含まれる可能性があります。この場合、古いプライマリノードはそれらの書込みを元に戻します。ロールバック中、ノードはROLLBACK状態になります。 ROLLBACK状態のメンバーは選挙で投票する資格があります。

バージョン4.2以降、 MongoDB は、ノードがROLLBACK状態になると、進行中のすべてのユーザー操作を強制終了します。

エラー状態

エラー状態のノードは投票できません。

UNKNOWN: レプリカセットにステータス情報を通信したことがないノードはUNKNOWN状態です。

DOWN: レプリカセットへの接続を失ったノードは、セットの残りのノードからは DOWN と認識されます。

REMOVED: レプリカセットから削除されたノードは、REMOVED 状態になります。ノードが REMOVED 状態になると、ログにはこのイベントが replSet REMOVED メッセージエントリでマークされます。

[1] 状況によっては、 replica set内の 2 つのノードが一時的に自分たちがプライマリであると認識することがありますが、最大でそのうちの 1 つが{ w: "majority" }書き込み懸念で書き込みを完了できます。 { w: "majority" }書き込みを完了できるノードは現在のプライマリであり、もう一方のノードは、通常はネットワークパーティションが原因で降格をまだ認識していない以前のプライマリです。これが発生すると、以前のプライマリに接続するクライアントは、読み取り設定primaryを要求したにもかかわらず、古いデータを検出する可能性があり、以前のプライマリへの新しい書き込みは最終的にロールバックされます。

戻る

プロトコルバージョン

自己管理型シャーディングされたクラスターの配置と管理