[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: |
|
| Operating System: | ALL |
| Participants: |
| Description |
|
Hi 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 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 |
| 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) { } |
| 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. |
| 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). |