|
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.
|
|
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?
|
|
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?
|
|
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.