-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication, Storage
-
None
-
Fully Compatible
-
Repl 2018-12-03, Repl 2018-12-17
-
66
InĀ SERVER-37227, we reintroduced the enableMajorityReadConcern:false parameter on the master branch. When majority read concern is disabled, we turn on logging for data files and take unstable checkpoints. This is incompatible with causally consistent sharded cluster backup, which requires us to be able to replay the oplog to a particular point in time. We must do the following to disable table logging for data files when enableMajorityReadConcern=false:
- Disable table logging for data files, which was enabled here.
- Take stable checkpoints. In addition to setting the oldest timestamp in the WiredTigerOplogManager, we will set the stable timestamp. In the WiredTigerCheckpointThread, we will take a stable checkpoint instead of taking a full checkpoint. Since we are no longer taking full checkpoints, we may need to pin oplog. Since the stable timestamp is now ahead of the majority commit point, we still must use rollback-via-refetch instead of recover-to-stable-timestamp.
- is depended on by
-
SERVER-38041 Test single shard transactions with arbiters and enableMajorityReadConcern:false replica sets with lag
- Closed
- is related to
-
SERVER-38925 Rollback via refetch can cause _id duplication when enableMajorityReadConcern:false
- Closed
-
SERVER-37728 Disabling majority reads negates some goals of filesystem backups
- Closed