-
Type:
Improvement
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Replication, Usability
-
Labels:
-
Minor Change
-
RPL 1 04/03/15, TIG C (11/20/15)
A healthy run of an applyOps command returns something like the following:
{ "applied" : 3, "results" : [ true, true, true ], "ok" : 1 }
However, if an error occurs, the output does not indicate which op caused the failure, and instead looks like this:
{
"errmsg" : "exception: E11000 duplicate key error index: fruit.fruit.$name_1 dup key: { : \"banana\" }",
"code" : 11000,
"ok" : 0
}
For example:
backup_test:PRIMARY> use fruit
switched to db fruit
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
}
It would useful to know that it was the 2nd op that caused the error.
- is related to
-
-
- Closed
-