[SERVER-6589] Pretouch throws "11000:E11000 duplicate key error index" on every update Created: 25/Jul/12  Updated: 11/Jul/16  Resolved: 26/Jul/12

Status: Closed
Project: Core Server
Component/s: Write Ops
Affects Version/s: 2.2.0-rc0
Fix Version/s: 2.2.0-rc1

Type: Bug Priority: Major - P3
Reporter: Jason Chuong Assignee: Kristina Chodorow (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux el5 x64


Attachments: Text File daemon.log     Text File daemon.log    
Operating System: ALL
Participants:

 Description   

Hi
I notice that every "update" operation using the _id causes "11000:E11000 duplicate key error index" on the secondary log.

primary:

Tue Jul 24 09:45:17 [conn5] getmore local.oplog.rs query: { ts:

{ $gte: new Date(5766220961858716081) }

} cursorid:7344324393376596819 ntoreturn:0 keyUpdates:0 locks(micros) r:64 nreturned:1 reslen:146 0ms
Tue Jul 24 09:45:17 [conn2590] update r1.Attribute query:

{ _id: ObjectId('4ff62387e4b072a042eee906') }

update: { $set:

{ typeId: 1 }

} idhack:1 nmoved:1 nupdated:1 keyUpdates:0 locks(micros) w:385 0ms

secondary:

Tue Jul 24 09:45:17 [repl prefetch worker] User Assertion: 11000:E11000 duplicate key error index: r1.Attribute.$id dup key: { : ObjectId('4ff62387e4b072a042eee906') }



 Comments   
Comment by Kristina Chodorow (Inactive) [ 26/Jul/12 ]

Thanks for the report, please keep banging on it!

Comment by auto [ 26/Jul/12 ]

Author:

{u'date': u'2012-07-25T11:35:07-07:00', u'email': u'kristina@10gen.com', u'name': u'Kristina'}

Message: Make prefetch not throw any exceptions SERVER-6589
Branch: master
https://github.com/mongodb/mongo/commit/f7fe1378882ddc992ccf9eff8be245336a97c4c3

Comment by Kristina Chodorow (Inactive) [ 25/Jul/12 ]

Thanks! I think this is a bug in some code that's supposed to touch indexes before replicating data. Other than being slow, it shouldn't affect functionality. Looking into it...

Comment by Jason Chuong [ 25/Jul/12 ]

Here's a php test scripts that i used to run the test. interate thru the collection and update the modDate and verify that update get replicated to secondary

cursor = $collection->find()->limit($limit);

foreach ($cursor as $doc) {
$filter = array('_id' => $doc["_id"]);
$update = array('$set' => array("date.modDate" => new MongoDate()));
$collection->update($filter,$update);
echo $doc["_id"] . "\n";;

}

Comment by Kristina Chodorow (Inactive) [ 25/Jul/12 ]

Can you attach the log from starting up with 2.2.0 through the error?

Comment by Jason Chuong [ 25/Jul/12 ]

No it wasn't. I upgraded our dev environment from 2.0.4 --> 2.2.0.
Verify the resultset and ran our test when we notice it in the log.

Comment by Kristina Chodorow (Inactive) [ 25/Jul/12 ]

Was this on initial sync?

Comment by Jason Chuong [ 25/Jul/12 ]

The replication didn't get stuck and i've verify that the update operation did get populate to the secondary

Comment by Kristina Chodorow (Inactive) [ 25/Jul/12 ]

That means that replication is stuck. Can you attach the log from the secondary?

Do you have a clean backup you can restore from? If not, you'll have to resync the secondary from scratch (shut down, delete data files, start it back up again).

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