[SERVER-6228] Duplicate key error causes secondaries to fassert() and crash Created: 27/Jun/12 Updated: 11/Jul/16 Resolved: 18/Dec/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 2.1.2 |
| Fix Version/s: | 2.2.0-rc0 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Bernie Hackett | Assignee: | Eric Milkie |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
Found while testing PyMongo against 2.1.2. I'm still trying to track down the actual sequence of events that causes this. Here's the traceback running log level 5:
I can reproduce this consistently running PyMongo's test_collection module, although running tests individually doesn't seem to cause it. I'll attach full logs from each replica set member shortly. |
| Comments |
| Comment by Gianfranco Palumbo [ 18/Dec/12 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
scotthernandez Sure I'll create another ticket. Just wondering, I would expect that it shutdowns gracefully instead showing a stacktrace or to stop the replication and log the assertion, though a shutdown might be a better signal to alert of this issue. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Scott Hernandez (Inactive) [ 18/Dec/12 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Gianfranco, please open a new issue for new scenarios like this. This is not the same scenario nor cause as described in this issue. What would you expect it to do? You broke replication by creating an index on the secondary which was more restrictive than the primary. We can change the error message but shutting down is a safe action if you chose to manually break replication like this – there is no way to automatically recover other than to drop the indexes not on the primary. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Gianfranco Palumbo [ 18/Dec/12 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Tested in 2.2.0 and 2.2.2 - This still causes a crash. The way to replicate this is: mongod 2.2.2
mongod 2.2.0
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 28/Jun/12 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'date': u'2012-06-28T12:56:20-07:00', u'email': u'milkie@10gen.com', u'name': u'Eric Milkie'}Message: Index builds are not replicated as a 'c' op (command) but instead | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bernie Hackett [ 27/Jun/12 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Logs for replica set members. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Bernie Hackett [ 27/Jun/12 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Also, the secondaries can't be restarted. They just crash again trying to replay the oplog. |