-
Type: New Feature
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
Sharding 18 (08/05/16), Sharding 2016-08-29, Sharding 2016-09-19
-
(copied to CRM)
-
0
For the upcoming maxStalenessMS read preference it is required that periodically there needs to be a replicated write - so it would have a new oplog entry to move forward the OpTime reported to clients.
These no-op 'n' writes should only be done on the primary when no other replicated writes have been done in the timeout period.
A side-effect of this will be that an idle replica set will no longer be idle with respect to writes, since it will internally force a write periodically. This new behavior (which also exists in master-slave replication) will show up in things like the calculation of "replication lag" never exceeding a second or two on caught up nodes – previously a lack of writes for a few minutes would immediately show a lag of that period as the new write comes in until it is replicated.
- is related to
-
SERVER-23893 Increment maxWireVersion for maxStalenessMS
- Closed
-
SERVER-4936 Server support for "maxStalenessMS" read preference option
- Closed
-
SERVER-8858 Extend `isMaster` to return opTime and writeDate
- Closed
- related to
-
SERVER-23908 MMAPv1 DurableImpl::waitUntilDurable should yield the flush lock
- Closed
-
SERVER-30339 Enabling profiling and read concern majority with a workload of reads and no writes causes accumulation of dirty data
- Closed
-
SERVER-29802 Non-atomic applyOps command should not take out a global exclusive lock
- Closed