-
Type:
Task
-
Resolution: Fixed
-
Priority:
Critical - P2
-
Affects Version/s: 3.6.0
-
Component/s: Replication, Storage
-
Fully Compatible
-
v3.6
-
Repl 2017-12-18
-
(copied to CRM)
Currently, the oldest_timestamp only tracks the stable timestamp, which tracks applied optimes as they commit. However, applied optimes only become stable timestamp candidates if the consistency mode of the node is "Consistent". During initial sync, the consistency mode of the node is not "Consistent", and thus we do not add any new stable timestamp candidates while in the oplog replay phase. This results in the oldest_timestamp not moving, which can quickly fill up cache with timestamp data during the oplog replay phase of initial sync.
- is related to
-
-
- Closed
-
- related to
-
SERVER-32185 Freshly synced secondaries respond to queries before their "sync time"
-
- Closed
-
-
-
- Closed
-