[SERVER-23326] applyOps should use a single WriteUnitOfWork where possible Created: 23/Mar/16  Updated: 08/Oct/17  Resolved: 04/Jun/16

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

Type: Bug Priority: Blocker - P1
Reporter: Mathias Stearn Assignee: Geert Bosch
Resolution: Done Votes: 0
Labels: RF, bkp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
related to SERVER-30049 applyOperation_inlock() allows except... Closed
related to SERVER-21345 applyOps returns wrong error code whe... Closed
related to SERVER-29802 Non-atomic applyOps command should no... Closed
is related to SERVER-19768 Failed applyOps command does not crea... Closed
is related to SERVER-27246 Running applyOps with an op on a none... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.2
Sprint: Integrate+Tuning 14 (05/13/16), Integrate+Tuning 15 (06/03/16), Integrate+Tuning 16 (06/24/16)
Participants:

 Description   

Currently we break some guarantees of atomicity by using separate WUOWs for each op and for the final logOp. This can result in a server performing the modification but not adding it to its oplog if the server is shut down in the middle of an applyOps.

We can't use a single WUOW in the general case because applyOps needs to support operations like building an index that are illegal inside of a WUOW. However, it should be possible to detect if all ops are simple single-document CRUD ops and use a single WUOW in that case. This would cover all uses of applyOps that are used when writing to the config servers.



 Comments   
Comment by Geert Bosch [ 20/Dec/16 ]

Given that backup relies on applyOps being non-atomic, this change would break OpsManager. It is too big of a change to backport in a general fashion, IMO. We could consider doing this only for config servers, or similar.

Comment by Githook User [ 04/Jun/16 ]

Author:

{u'username': u'GeertBosch', u'name': u'Geert Bosch', u'email': u'geert@mongodb.com'}

Message: SERVER-23326 Commit applyOps as single WUOW where possible
Branch: master
https://github.com/mongodb/mongo/commit/e533634d86aae9385d9bdd94e15d992c4c8de622

Comment by Martin Bligh [ 28/Mar/16 ]

If we want to make this more consistent, it'd seem to make sense to make a hard rule (controlled by a bool flag) - ie we either do it in one WUOW or fail the command if we can't do that?

Comment by Scott Hernandez (Inactive) [ 24/Mar/16 ]

We have a mechanism in replication to address this as we store the batch boundaries (in the minvalid document), which indicates the operations being applied in the batch. Is there some reason this is not sufficient?

Or are you really suggesting some optimization for the applyOps command (which is used by sharding), not replication related?

Comment by Mathias Stearn [ 23/Mar/16 ]

geert.bosch I put this on the sharding backlog for prioritization since that is the main use case that will benefit, but this will probably end up being implemented by the Integration team.

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