[SERVER-22132] Check in logOp that we don't record out of order oplog entries Created: 11/Jan/16  Updated: 14/Apr/16  Resolved: 13/Jan/16

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Scott Hernandez (Inactive) Assignee: Scott Hernandez (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-22130 Reset applier lastAppliedOptime after... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl F (01/29/16)
Participants:

 Description   

Add check to logOp, logOps to make sure that replCoord->myLastOptime is less than the new one(s) being recorded.

This used to be checked in 2.6: https://github.com/mongodb/mongo/blob/v2.6/src/mongo/db/repl/oplog.cpp#L267



 Comments   
Comment by Scott Hernandez (Inactive) [ 13/Jan/16 ]

Since we added document level locking storage engines this is no longer a reasonable check wrt the ordering of oplog inserts related to transaction commits. Also, the performance overhead of doing this is probably too high to boot.

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