-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Fully Compatible
-
ALL
-
v4.2, v4.0
-
Repl 2018-06-18, Repl 2018-07-02, Repl 2018-07-16, Repl 2018-07-30, Repl 2019-11-18, Repl 2019-12-02, Repl 2020-01-27
-
52
It is possible to decide to roll back against a sync source that is behind the rollback node (due to receiving an empty batch), then resolve the common point when that same source is ahead. This leads to the rollback node crashing during oplog truncation, as there are no entries after the common point.
- is related to
-
SERVER-46050 Use getLastAppliedOpTime rather than getHeartbeatAppliedOpTime for checking primary's position
- Closed
- related to
-
SERVER-33812 First initial sync oplog read batch fetched may be empty; do not treat as an error.
- Closed