-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 3.0.15, 3.2.16
-
Component/s: Replication, Storage
-
None
-
Fully Compatible
-
ALL
-
Storage 2017-09-11
When initial sync starts, the node reads the last oplog entry "A" from its sync source and uses that as its starting point when it applies operations in a later phase. Because such a read is not subject to oplog visibility rules (because it uses a reverse scanning cursor instead of a forward cursor), there could be uncommitted operations prior to "A" that affect documents after initial sync has already passed such documents by in its collection scan phase. Such changes would never be applied to the initial-syncing node.
- causes
-
SERVER-38425 Oplog Visibility Query is a collection scan in 3.2.21
- Closed
- is related to
-
SERVER-30927 Use readConcern afterClusterTime for initsync oplog queries
- Closed
- related to
-
SERVER-37408 Add afterClusterTime to initial sync collection scans
- Closed
-
SERVER-37468 Problem with initial sync when adding an member in a rs in 3.2.21
- Closed