Navigation
This version of the documentation is archived and no longer supported.

Replica Set Protocol Versions

MongoDB provides replica set protocol version 0 (pv0) and replica set protocol version 1 (pv1).

Note

pv1 is the default for all new replica sets created with MongoDB 3.2 or later.

The following outlines some differences between pv0 and pv1.

Preservation of Writes

w:1 Writes

pv0 prioritizes preservation of w:1 writes

pv1 increases the likelihood of w:1 rollbacks compared to pv0 for the following versions:

  • MongoDB 3.4.1
  • MongoDB 3.4.0
  • MongoDB 3.2.11 or earlier

However, for pv1 in MongoDB 3.4+, you can configure catchUpTimeoutMillis to prioritize preservation of w:1 writes.

w: "majority" Writes

pv0 can lose confirmed w: "majority" writes.

pv1 guarantees the preservation of confirmed w: "majority" writes.

Availability

  • pv0 is available in all MongoDB versions.
  • pv1 is available in MongoDB version 3.2 or later and is the default for all new replica sets created with version 3.2 or later.
MongoDB Versions pv0 pv1
3.2+ ✓ ✓
< 3.2 ✓  

Read Concern

Read Concern pv0 pv1
"local" ✓ ✓
"majority"   ✓
"linearizable" ✓ ✓

Arbiters

For the following MongoDB versions, pv1 increases the likelihood of w:1 rollbacks compared to pv0 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 does not increase the likelihood of w:1 rollbacks for replica sets with arbiters.

Priorities

For the following MongoDB versions, pv1 increases the likelihood of w:1 rollbacks compared to pv0 for replica sets with different members[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 does not increase the likelihood of w:1 rollbacks for replica sets with different members[n].priority settings.

Vetoes

pv0 allows members to veto elections based on member’s optime and priority values.

pv1 does not use vetoes. Individual members can vote for or against a 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 set may transiently believe that they are the primary, but at most, one of them will be able to complete writes with { w: "majority" } write concern. The node that can complete { w: "majority" } writes is the current primary, and the other node is a former primary that has not yet recognized its demotion, typically due to a network partition. When this occurs, clients that connect to the former primary may observe stale data despite having requested read preference primary, and new writes to the former primary will eventually roll back.

pv0 relies on clock synchronization to disambiguate when two members both think they are primary.

Warning

Reliance on clock synchronization can lead to the loss of confirmed w: "majority" writes.

pv1 uses the concept of term instead of clock synchronization. This allows for a faster detection of simultaneous primaries and for multiple successful elections in a short period of time.

Back to Back Elections

pv0 includes a 30 seconds buffer between back-to-back elections as a precaution against poor clock synchronization. This buffer helps reduce the number of back to back elections. However, pv0 can leave a replica set with no primary if multiple elections are needed in a short period of time.

pv1 makes a “best-effort” attempt to have the secondary with the highest priority available call an election. This could lead to back-to-back elections as eligible members with higher priority can call an election.

However, for MongoDB 3.4.2+ and 3.2.12+:

  • Priority elections have been limited to occur only if the higher priority node is within 10 seconds of the current primary.
  • Arbiters in pv1 will vote no in elections if they detect a healthy primary of equal or greater priority to the candidate.

For MongoDB 3.4+, you can also reduce the likelihood of rollback of w:1 writes with pv1 by increasing the catchUpTimeoutMillis setting.

Double Voting

pv1 prevents double voting in one member’s call for election. This is achieved through its use of terms.

pv0 lessens the likelihood of double-voting via the 30-second buffer, but cannot guarantee that a member will not double vote if an election exceeds 30-seconds.

Modify Replica Set Protocol Version

Before changing the protocol version, ensure that at least one oplog entry (generated from the current protocol version) has replicated from the primary to all secondaries. To verify, on each secondary, check the optimes.lastCommittedOpTime.t field returned from rs.status(). For example, connect a mongo shell to each secondary and run:

copy 
rs.status().optimes.lastCommittedOpTime.t
  • If the current replica set protocol version is 0, the t is equal to -1.
  • If the current replica set protocol version is 1, the t is greater than -1.

Once you have verified that at least one oplog entry (using the current protocol version) has replicated to all the secondaries, you can change the protocol version.

To change the replica set protocol version, reconfigure (rs.reconfig) the replica set with the new protocolVersion. For example, to upgrade to pv1, connect a mongo shell to the current primary and perform the following sequence of operations:

copy 
cfg = rs.conf();
cfg.protocolVersion=1;
rs.reconfig(cfg);

To reduce the likelihood of w:1 rollbacks, you can also reconfigure the replica set to a higher settings.catchUpTimeoutMillis setting.

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.