[SERVER-27416] Fatal Assertion 34433 Created: 14/Dec/16 Updated: 13/Aug/18 Resolved: 20/Jan/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | WiredTiger |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | lakshitha weerakkody | Assignee: | Michael Cahill (Inactive) |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | wtc | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Storage 2017-01-23, Storage 2017-02-13 | ||||||||
| Participants: | |||||||||
| Description |
|
I had this error this morning on my local machine when I trying to start the DB. It says it's because of an unclean shutdown. but i'm unable to recover the DB. --repair also didn't work.
|
| Comments |
| Comment by Michael Cahill (Inactive) [ 10/Feb/17 ] |
|
YouriT, the original assertion reported in this ticket indicates metadata corruption. There can be many causes of such corruption: for example, the filesystem may have been left in an inconsistent state after the failed container shutdown. Please open a new ticket to request help getting to the bottom of this issue and we can create an upload portal for your data. In the meantime, if the node is part of a replicaset, I recommend resyncing it. If not, it is probably best to restore from a backup. |
| Comment by Youri Tolstoy [ 09/Feb/17 ] |
|
Hi, This happened to me today as well. To give a bit more background to how it happened:
If it helps, I can provide logs and tarball but I would also need to send it through a private push. Haven't seen the issue on 3.4 so far. |
| Comment by Michael Cahill (Inactive) [ 20/Jan/17 ] |
|
lakikeanu, our team has done a forensic analysis of the data you provided, thank you. We have carefully reviewed the code responsible for creating and dropping collections and indexes with WiredTiger to try to figure out how your database could have ended up in the state it is in. We have not seen these symptoms elsewhere, even with users with unreliable storage systems: our best explanation is that the repair process corrupted some of the metadata. Given that we can't reproduce this situation and it was a test project, I am going to close this ticket now. If you encounter any further problems using MongoDB, please open a new ticket with the details. |
| Comment by lakshitha weerakkody [ 22/Dec/16 ] |
|
Hi Thomas, 1. How can I get the logs? As I remember machine got automatically shutdown (for a windows update) while mongodb was running. Robomongo app was also opened and connected to the DB at that time. Thanks, |
| Comment by Kelsey Schubert [ 19/Dec/16 ] |
|
Hi lakikeanu, Thanks for the providing the files, they are very helpful. I have a couple of follow up questions as we continue our investigation of this issue.
Thanks again for your help, |
| Comment by lakshitha weerakkody [ 15/Dec/16 ] |
|
Hi Thomas, It was a test project so I have uploaded all the files there (https://10gen-httpsupload.s3.amazonaws.com/upload_forms/fadb4f0e-2c7e-4865-9f03-5759067bafc5.html) . so you can take a good look in to that. Let me know if you find anything. Thanks, |
| Comment by Kelsey Schubert [ 14/Dec/16 ] |
|
Hi lakikeanu, Thank you for reporting this issue. To help us investigate the root cause of this corruption, please upload the following:
Finally, please consider creating a backup of the current $dbpath of the affected node as we may need to examine additional files as our ing. For your convenience, I have have created a secure upload portal for you to use. Files uploaded to this portal only be visible to MongoDB employees investigating this issue and are routinely deleted after some time. My understanding is that is node is a standalone. In this case, my only reccomendation to resolve this issue would to restore from a backup. Kind regards, |