レプリカセットの各ノードにはそれぞれ状態があります。
番号 | 名前 | 状態の説明 |
|---|---|---|
0 | Not yet an active member of any set. All members start up in this state. The | |
1 | ステートプライマリのノードは、書込み操作を受け付けることができる唯一のノードです。これらのノードには、投票資格があります。 | |
2 | 状態セカンダリのノードは、データ ストアをレプリケートします。これらのノードには、投票資格があります。 | |
3 | ||
5 | ノードは最初の同期を実行中です。 レプリカセットに新しく追加された場合を除き、投票資格があります。 | |
6 | セットの別のノードから見て、ノードの状態はまだわかりません。 | |
7 | アービタはデータをレプリケートせず、選挙に参加するためだけに存在します。これらのノードには、投票資格があります。 | |
8 | セット内の別のノードから見て、そのノードは到達不可能です。 | |
9 | ||
10 | このノードはかつてレプリカセットに含まれていましたが、その後削除されました。 |
状態
コア状態
PRIMARYPRIMARY状態のメンバーは書込み操作を受け入れます。レプリカセットには、一度に最大 1 つのプライマリが含まれます。 []1SECONDARYメンバーは選挙後にプライマリになります。PRIMARY状態のメンバーには投票資格があります。
SECONDARYMembers in
SECONDARYstate replicate the primary's data set and can be configured to accept read operations. Secondaries are eligible to vote in elections, and may be elected to thePRIMARYstate if the primary becomes unavailable.
ARBITERMembers in
ARBITERstate do not replicate data or accept write operations. They are eligible to vote, and exist solely to break a tie during elections. Replica sets should only have a member in theARBITERstate if the set would otherwise have an even number of voting members, and could suffer from tied elections. There should only be at most one arbiter configured in any replica set. For considerations when using an arbiter, see Replica Set Arbiter.
コア状態について詳しくは、「レプリカセット ノード」を参照してください。
その他の状態
STARTUPEach member of a replica set starts up in
STARTUPstate.mongodthen loads that member's replica set configuration, and transitions the member's state toSTARTUP2orARBITER. Members inSTARTUPare not eligible to vote, as they are not yet a recognized member of any replica set.
STARTUP2バージョン5.0で変更。
Each data-bearing member of a replica set enters the
STARTUP2state as soon asmongodfinishes loading that member's configuration.The member then decides whether or not to undertake an initial sync. If a member begins an initial sync, the member remains in
STARTUP2until all data is copied and all indexes are built. Afterwards, the member transitions toRECOVERING.に新しく追加されたメンバーには投票資格がなく、投票できません。最初の同期プロセス中に選択されます。
STARTUP2MongoDB.5 0より前は、STARTUP2のメンバーには投票資格がありました。
RECOVERINGA member of a replica set enters
RECOVERINGstate when it is not ready to accept reads. TheRECOVERINGstate can occur during normal operation, and doesn't necessarily reflect an error condition. Members in theRECOVERINGstate are eligible to vote in elections, but are not eligible to enter thePRIMARYstate.A member transitions from
RECOVERINGtoSECONDARYafter replicating enough data to guarantee a consistent view of the data for client reads. The only difference betweenRECOVERINGandSECONDARYstates is thatRECOVERINGprohibits client reads andSECONDARYpermits them.SECONDARYstate does not guarantee anything about the staleness of the data with respect to the primary.Due to overload, a secondary may fall far enough behind the other members of the replica set such that it may need to resync with the rest of the set. When this happens, the member enters the
RECOVERINGstate and requires manual intervention.
ROLLBACKWhenever the replica set replaces a primary in an election, the old primary may contain documents that did not replicate to the secondary members. In this case, the old primary member reverts those writes. During rollback, the member will have
ROLLBACKstate. Members in theROLLBACKstate are eligible to vote in elections.Starting in version 4.2, MongoDB kills all in-progress user operations when a member enters the
ROLLBACKstate.
エラー状態
エラー状態のノードは投票できません。
UNKNOWNMembers that have never communicated status information to the replica set are in the
UNKNOWNstate.
DOWNMembers that lose their connection to the replica set are seen as
DOWNby the remaining members of the set.
REMOVEDMembers that are removed from the replica set enter the
REMOVEDstate. When members enter theREMOVEDstate, the logs will mark this event with areplSet REMOVEDmessage entry.
| [1] | 状況によっては、 replica set内の 2 つのノードが一時的に自分たちがプライマリであると認識することがありますが、最大でそのうちの 1 つが |