[SERVER-22262] Do not truncate the last applied oplog entry during batch recovery Created: 21/Jan/16  Updated: 31/Jan/17  Resolved: 08/Feb/16

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 3.2.0, 3.3.1
Fix Version/s: 3.3.2

Type: Improvement Priority: Major - P3
Reporter: Scott Hernandez (Inactive) Assignee: Siyuan Zhou
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Duplicate
is duplicated by SERVER-22263 Duplicated application of last applie... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.2
Participants:

 Description   

Make the truncation of the oplog non-inclusive with minvalid.start (last applied oplog entry).



 Comments   
Comment by Mathias Stearn [ 31/Jan/17 ]

siyuan.zhou, it isn't actually reverted. We should never delete any applied ops from the oplog (that would be corruption). That commit changes it from deleting > lastApplied, to deleting >= oplogDeletePoint which is itself guaranteed to be > lastApplied.

Comment by Siyuan Zhou [ 31/Jan/17 ]

The logic was reverted by redbeard0531 in SERVER-7200 Write oplog entries on secondaries before applying (34c6c691). redbeard0531, when truncating the oplog, do we keep the last applied op in oplog on purpose now?

Comment by Spencer Brody (Inactive) [ 31/Jan/17 ]

siyuan.zhou, trying to decide whether to backport this to 3.2, but I don't really understand the implications of leaving it unfixed, nor how risky a change it is to make, can you weigh in on that?

Comment by Githook User [ 08/Feb/16 ]

Author:

{u'username': u'visualzhou', u'name': u'Siyuan Zhou', u'email': u'siyuan.zhou@mongodb.com'}

Message: SERVER-22262 Do not truncate the last applied oplog entry during batch recovery
Branch: master
https://github.com/mongodb/mongo/commit/6935119d85848bde5b189c2c0ccf49b1ce10f0ed

Generated at Thu Feb 08 03:59:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.