[SERVER-10826] Assert in the secondary Created: 19/Sep/13 Updated: 27/Sep/13 Resolved: 27/Sep/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Dharshan Rangegowda | Assignee: | Joanna Cheng |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
AWS, M1.Large replica set |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
Assert on the secondary of a brand new cluster. The user claims to only have typed "use <dbname>" which caused an assert in the secondary. I have attached the full logs for you. Tue Sep 17 19:36:19.657 [conn10402] authenticate db: local { authenticate: 1, nonce: "420a32d3262a1deb", user: "__system", key: "332123ac38f870a9457839370b92c152" }Tue Sep 17 19:36:27.128 [conn10401] end connection 10.190.206.142:39617 (7 connections now open) Tue Sep 17 19:36:29.083 [repl prefetch worker] warning database /mongodb_data edspringPROD could not be opened } ***aborting after fassert() failure Tue Sep 17 19:36:29.087 Got signal: 6 (Aborted). Tue Sep 17 19:36:29.090 Backtrace: |
| Comments |
| Comment by Joanna Cheng [ 27/Sep/13 ] | ||||||
|
Hi Dharshan, I'm going to close this ticket as I've not heard back from you, and I believe MongoDB is working as designed here. Thanks for your feedback, and have a great weekend! Kind regards, | ||||||
| Comment by Joanna Cheng [ 24/Sep/13 ] | ||||||
|
Hi Dharshan, Thanks for the reply and details. From mongod's perspective, at this point the primary and secondary are in inconsistent states (specifically, with respect to database names). Note at this stage we cannot continue further in the oplog as we are no longer consistent with the primary. In this state, to preserve the integrity of the replica set, the inconsistent secondary is taken down, as it cannot keep up with the rest of the replica set. Kind regards, | ||||||
| Comment by Dharshan Rangegowda [ 23/Sep/13 ] | ||||||
|
Hi - the user was futzing around the console with "use dbname" command. So they might have created two dbs and then deleted them. I am not sure. However it would be good if this can be handled without a crash. | ||||||
| Comment by Joanna Cheng [ 23/Sep/13 ] | ||||||
|
Hi Dharshan, Looking at the log snippet you provided:
It shows the replication thread trying to replicate a command on the secondary, to drop the database edSpringPROD Could you shed any light as to how the inconsistency in database names could have happened? This case has highlighted that our documentation could be clarified, with regards to how cases in database names are handled; I will raise this with our documentation team. Kind regards, |