Replica Set Protocol Version
Starting in version 4.0, MongoDB only supports replica set protocolversion 1 (pv1
). pv1
is the default forall new replica sets created with MongoDB 3.2 or later.
Preservation of Writes
w:1 Writes
With pv1
, you can usecatchUpTimeoutMillis
to prioritize between fasterfailovers and preservation of w:1
writes.
w: "majority" Writes
pv1
guarantees the preservation of confirmed w:"majority"
writes.
Availability
pv1
is available in MongoDB version 3.2 or later and is the defaultfor all new replica sets created with version 3.2 or later.
Arbiters
For the following MongoDB versions, pv1
increases the likelihoodof w:1
rollbacks compared to pv0
(no longer supported in MongoDB 4.0+) for replica sets with arbiters:
- MongoDB 3.4.1
- MongoDB 3.4.0
- MongoDB 3.2.11 or earlier
For the other versions of MongoDB that support pv1
, pv1
doesnot increase the likelihood of w:1
rollbacks forreplica sets with arbiters.
Priorities
For the following MongoDB versions, pv1
increases the likelihoodof w:1
rollbacks compared to pv0
(no longer supported in MongoDB 4.0+) for replica sets with differentmembers[n].priority
settings:
- MongoDB 3.4.1
- MongoDB 3.4.0
- MongoDB 3.2.11 or earlier
For the other versions of MongoDB that support pv1
, pv1
doesnot increase the likelihood of w:1
rollbacks forreplica sets with different members[n].priority
settings.
Vetoes
pv1
does not use vetoes. Individual members can vote for or againsta candidate in a particular election, but cannot individually veto (abort)an election unilaterally.
Detection of Simultaneous Primaries
In some circumstances, two nodes in a replica setmay transiently believe that they are the primary, but at most, oneof them will be able to complete writes with { w:"majority" }
write concern. The node that can complete{ w: "majority" }
writes is the currentprimary, and the other node is a former primary that has not yetrecognized its demotion, typically due to a network partition.When this occurs, clients that connect to the former primary mayobserve stale data despite having requested read preferenceprimary
, and new writes to the former primary willeventually roll back.
pv1
uses the concept of term. This allows for a fasterdetection of simultaneous primaries and for multiple successfulelections in a short period of time.
Back to Back Elections
pv1
makes a “best-effort” attempt to have the secondary with thehighest priority
available call an election. Thiscould lead to back-to-back elections as eligible members withhigher priority can call an election.
However, in MongoDB 3.6+ (as well as MongoDB 3.4.2+ and 3.2.12+), for pv1
:
- Priority elections have been limited to occur only if the higherpriority node is within 10 seconds of the current primary.
- Arbiters will vote no in elections if they detect a healthy primaryof equal or greater priority to the candidate.
Double Voting
pv1
prevents double voting in one member’s call for election. Thisis achieved through its use of terms.
Modify Replica Set Protocol Version
Starting in version 4.0, MongoDB only supports replica set protocolversion 1 (pv1
).
However, MongoDB 3.2 through MongoDB 3.6 support replica set protocolversion 1
and protocol version 0
.
Before changing the protocol version for MongoDB 3.2 through MongoDB3.6, ensure that at least one oplog entry (generated from the currentprotocol version) has replicated from the primary to all secondaries.To check, on each secondary, check the optimes.lastCommittedOpTime.t
field returned fromrs.status()
. For example, connect a mongo
shell to each secondary and run:
- rs.status().optimes.lastCommittedOpTime.t
- If the current replica set protocol version is
0
, thet
is equalto-1
. - If the current replica set protocol version is
1
, thet
is greaterthan-1
.
Once you have verified that at least one oplog entry (using the currentprotocol version) has replicated to all the secondaries, you can changethe protocol version.
To change the replica set protocol version, reconfigure(rs.reconfig
) the replica set with the newprotocolVersion
. For example, to upgrade to pv1
, connecta mongo
shell to the current primary and perform thefollowing sequence of operations:
- cfg = rs.conf();
- cfg.protocolVersion=1;
- rs.reconfig(cfg);
You can use catchUpTimeoutMillis
to prioritizebetween faster failovers and preservation of w:1
writes.