[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: |
|
||||||||
| 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. |