[SERVER-44938] Secondaries apply "applyOps" oplog entries at the wrong timestamp Created: 03/Dec/19  Updated: 29/Oct/23  Resolved: 06/Dec/19

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

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Samyukta Lanka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File server-44938.js    
Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2019-12-16
Participants:
Linked BF Score: 44

 Description   

They currently use the timestamp of the inner ops rather than the outer ops.



 Comments   
Comment by Githook User [ 06/Dec/19 ]

Author:

{'name': 'Samyukta Lanka', 'username': 'lankas', 'email': 'samy.lanka@mongodb.com'}

Message: SERVER-44938 Primaries will run applyOps with inner operations that have a 'ts' field in non-atomic mode
Branch: master
https://github.com/mongodb/mongo/commit/1f01c61ee58d82b096419d8ccf36b27e99a0f729

Comment by Lingzhi Deng [ 05/Dec/19 ]

Ok, this is the bug. We were parsing the command obj using ReplOperatio which doesn't accept a ts field. So we were throwing error AtomicityFailure for an applyOps that has the ts field and retrying in non-atomic mode. If an operation is applied in non-atomic mode, primary will only log the operation itself without the outer applyOps. But my commit changed to use OplogEntry which accepts ts fields. So in master, we apply an applyOps with ts field in atomic mode and log the whole applyOps in the oplog cause we want secondaries to also apply them atomically. So we should fail applyOps with ts field and retry in non-atomic mode to match 4.2.

Comment by Judah Schvimer [ 04/Dec/19 ]

After bisecting relevant commits, I think this was introduced in SERVER-37180 (https://github.com/mongodb/mongo/commit/102c20ab166050ae7357732070bc8262aa61749c).

Comment by Judah Schvimer [ 04/Dec/19 ]

Luckily the test passes on both 4.0 and 4.2, so it seems to just be a master branch regression.

Comment by Judah Schvimer [ 04/Dec/19 ]

Repro: server-44938.js

Generated at Thu Feb 08 05:07:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.