-
Type: Improvement
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
Sharding 2017-01-02
ReplicationCoordinatorImpl consults the storage engine's isDurable flag for two purposes:
- To choose whether to present the durable or applied optime when standing for election in pv1
- To decide how to interpret w:majority without an explicit j field when waiting for write concern.
In the first case, it is unnecessary to choose which optime to apply based on the isDurable flag. It is always safe and correct to present the applied optime, because if the node presenting it wins election, it will attempt to commit that applied optime. That means that voters may safely vote for that node.
In the second case, using the value of the local node's storage engine's isDurable flag to adjust the meaning of w:majority is out of spec. Whether w:majority writes wait for journaling is a function only of the writeConcernMajorityJournalDefault flag when a write concern omits the "j" field.
Further, the ReplCoordTestFixture and ReplicationCoordinatorImpl test-only constructor are more complex than necessary, and offer unused flexibility. This task also removes the unused behaviors and narrows the presented interface in order to make future enhancement easier.
- related to
-
SERVER-28376 ReplSetTest.initiate() should call awaitReplication before requesting node 0 to step up as primary
- Closed