[SERVER-27974] Fatal Crash on remote query Created: 10/Feb/17 Updated: 16/Feb/17 Resolved: 16/Feb/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MMAPv1 |
| Affects Version/s: | 3.2.11 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Michael Fair | Assignee: | Kelsey Schubert |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Steps To Reproduce: | execute command: db.getCollection('declinecalls').find({}).sort({_id:-1}) |
| Participants: |
| Description |
|
Using robomongo to query collection, with a sort by id in reverse, it will cause a fatal error.
|
| Comments |
| Comment by Kelsey Schubert [ 16/Feb/17 ] |
|
Hi br8kpoint, I'm glad the issue has been resolved. Unfortunately, there are many possible causes and without a clear reproduction it is challenging to determine the root cause. While the journal allows MongoDB to recover to a consistent state following an unclean shutdown, there may have been failures on the storage layer outside of MongoDB. If you encounter this issue again, I would recommend checking the integrity of your disks. Kind regards, |
| Comment by Michael Fair [ 16/Feb/17 ] |
|
Thank you for looking into this. It turns out that the database was corrupted. I found out when running the the validate. I ran a repair and things are working again. What I don't understand is that we switched to journalling when we upgraded to 3.2. From what I read in the docs, repairs should not be needed and are discouraged when journalling is enabled. Which is why I didn't investigate database corruption earlier. Thanks for your help. |
| Comment by Kelsey Schubert [ 10/Feb/17 ] |
|
Hi br8kpoint, Thank you for reporting this issue. I have a couple questions to help us investigate.
Thanks for your help, |