-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
Repl 2020-10-19, Repl 2020-11-02, Repl 2020-11-16, Repl 2020-11-30, Repl 2020-12-14
-
15
During recovery, we assume the oplogApplicationStartPoint (which derives from the stable timestamp)
https://github.com/mongodb/mongo/blob/2c446f3f587f406c23cdfca87f227ee5cd466fa8/src/mongo/db/repl/replication_recovery.cpp#L165
After theĀ PM-1713
Remove Stable Optime Candidates List project, this is no longer the case. If the oplogApplicationStartPoint is not present in the oplog, that's OK. In this case we must apply every entry in the oplog query (i.e. we do NOT skip the first entry)
It is also the case that the oplog query may return no oplog entries, so the check here
is also incorrect and should be replaced with a log message.
- is related to
-
SERVER-51158 Must not truncate entire oplog before truncate point
- Closed
- related to
-
SERVER-54666 Use earlier oplog entry if recovery timestamp cannot be found in oplog
- Closed