[SERVER-10772] Add option to applyOps to allow continuing on error Created: 15/Sep/13  Updated: 06/Dec/22  Resolved: 09/Jan/18

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

Type: Improvement Priority: Major - P3
Reporter: Cailin Nelson Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: brs
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-10771 If applyOps encounters an error, indi... Closed
Assigned Teams:
Replication
Participants:

 Description   

Continuing on from SERVER-10771, it would also be nice if applyOps could continue on error, while returning details about the errors it encountered.

For example in ....

backup_test:PRIMARY> db.fruit.ensureIndex({name:1},{unique:true})
backup_test:PRIMARY> db.fruit.insert({name: 'cherry'})
backup_test:PRIMARY> db.fruit.insert({name: 'banana'})
backup_test:PRIMARY> db.fruit.insert({name: 'pear'})
backup_test:PRIMARY> db.fruit.remove({name: 'banana'})
backup_test:PRIMARY> db.fruit.insert({name: 'banana'})
backup_test:PRIMARY> use local
switched to db local
backup_test:PRIMARY> var ops = []; db.oplog.rs.find().sort({$natural:-1}).limit(5).forEach( function(opDoc) {ops.push(opDoc)});
backup_test:PRIMARY> db.runCommand({applyOps: ops})
{
	"errmsg" : "exception: E11000 duplicate key error index: fruit.fruit.$name_1  dup key: { : \"banana\" }",
	"code" : 11000,
	"ok" : 0
}

... the server fails on the 2nd op. It would be nice to have the option to have it continue on and finish the batch, while returning an array of responses indicating whether or not each op succeeded, and error messages for any ops that failed.



 Comments   
Comment by David Dana [ 09/Jan/18 ]

Backup Backlog Grooming Note

  • We haven't seen this pop up in awhile. The real concern is SERVER-12508 which we will keep an eye on.
Comment by Andy Schwerin [ 15/Sep/13 ]

I'm pretty sure Eric is right, here. Once you skip one operation on a document, you must skip all subsequent operations on that document, or you may corrupt data (even ignoring unique constraint violation).

Comment by Cailin Nelson [ 15/Sep/13 ]

This would only be used when we are in a situation where we are replaying oplogs. Duplicate key errors can happen when replaying oplogs. We can ignore them in a heavyweight way by using the functionality in SERVER-10773. However, this ticket combined with SERVER-10771 would allow for a more elegant solution then flipping the server in and out of "ignore all unique constraints" mode.

Comment by Eric Milkie [ 15/Sep/13 ]

I don't see the use case for this. The logic for guaranteeing idempotency of operations requires that ops be applied in order. Skipping over operations will likely result in corrupt data.

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