-
Type: Bug
-
Resolution: Fixed
-
Priority: Critical - P2
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
ALL
-
v3.6, v3.4
-
-
Repl 2018-04-23
-
52
Currently we depend on an initial sync not receiving an initial batch that is empty. However, this is a possibility, depending on timing in the _oplogJournalThreadLoop. The fix for SERVER-31679 exacerbates this issue, blocking its backport to 3.6. So, currently this issue is blocking the backport of that ticket.
- is related to
-
SERVER-30927 Use readConcern afterClusterTime for initsync oplog queries
- Closed
-
SERVER-30977 Need to sign cluster times for unsharded replica sets
- Closed
-
SERVER-31007 Calculate rollback time limit correctly
- Closed
-
SERVER-34768 Rollback can fail if run against a lagged node that catches up
- Closed
-
SERVER-35256 Do not treat it as an error if the first batch returned by an oplog query comes back empty in master-slave
- Closed
-
SERVER-42910 Oplog query with higher timestamp but lower term than the sync source shouldn't time out due to afterClusterTime
- Closed
-
SERVER-29213 Have KVWiredTigerEngine implement StorageEngine::recoverToStableTimestamp
- Closed
- related to
-
SERVER-31679 Increase in disk i/o for writes to replica set
- Closed