[SERVER-85391] Do oplog version check in OplogFetcher instead of OplogBatcher Created: 18/Jan/24  Updated: 02/Feb/24  Resolved: 02/Feb/24

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 8.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Wenbin Zhu Assignee: Brad Cater
Resolution: Fixed Votes: 0
Labels: PM-3489-Milestone-OplogWriter-CP
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-85598 [Milestone] OplogWriter Checkpoint In Progress
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Sprint: Repl 2024-02-19
Participants:

 Description   

Move oplog version check logic from OplogBatcher to OplogFetcher during document validation.

We should probably feature flag gate this since doing in OplogFetcher would need to parse the version from the oplog BSONObject which cause some overhead, while in OplogBatcher the entire oplog entry is already parsed so getting the version is trivial.

Since we will have an OplogWriter in front of OplogApplier, we should do the version check early - that is, before we write to the oplog - but we want the OplogWriter to be efficient (i.e. we don’t want to iterate through the oplog entries in the batch and parse the version). Therefore, we can check the version in the OplogFetcher where we already iterate and parse the OpTime field for validation.

AC: The OplogFetcher validates the version, and neither the OplogWriter nor the OplogApplier check the version.



 Comments   
Comment by Githook User [ 02/Feb/24 ]

Author:

{'name': 'Brad Cater', 'email': '152920274+brad-cater-mongodb@users.noreply.github.com', 'username': 'brad-cater-mongodb'}

Message: SERVER-85391 Check the oplog version in the OplogFetcher instead of in the OplogBatcher. (#18502)

GitOrigin-RevId: 880fe14342bea7a7ec4a6c86d0cd4b96491b5de8
Branch: master
https://github.com/mongodb/mongo/commit/f3366610bdad5c036730b425b8a912d570dea4d7

Generated at Thu Feb 08 06:57:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.