-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
Fully Compatible
-
v4.4
-
Repl 2020-05-04
After a reconfig, we drop snapshots, since the definition of majority-committed can change. However, all this does is set _currentCommittedSnapshot to none. It does not change the
_lastCommittedOpTimeAndWallTime in the TopologyCoordinator. This means that the next time we set _currentCommittedSnapshot, either due to the JournalFlusher or replSetUpdatePosition, we will refuse to set _lastCommittedOpTimeAndWallTime backward, so _currentCommittedSnapshot can be set to its previous value from before the reconfig. This means that dropping snapshots after reconfig doesn’t accomplish anything.
The safe reconfig protocol guarantees that operations committed in the old config will never roll back, so we can stop dropping snapshots after a safe reconfig that does not change writeConcernMajorityJournalDefault.
- is depended on by
-
SERVER-47142 Check primary before writing replset config and no-op
- Closed
- is related to
-
SERVER-47206 Majority commit point is not set backward after force reconfig or reconfig that changes writeConcernMajorityJournalDefault
- Backlog
- related to
-
SERVER-46516 Majority write concern is blocked by dropping snapshot on reconfig
- Closed
-
SERVER-47142 Check primary before writing replset config and no-op
- Closed
-
SERVER-40649 Drop snapshots for reconfig via heartbeat.
- Backlog
-
SERVER-83092 Eliminate the unnecessary majority check in wait for write concern
- Closed