[SERVER-21922] MMAPv1: Invariant failure after mongod restart Created: 16/Dec/15 Updated: 23/Dec/15 Resolved: 23/Dec/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MMAPv1, Storage |
| Affects Version/s: | 3.2.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | imun Mikecin | Assignee: | Kelsey Schubert |
| Resolution: | Incomplete | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Operating System: | ALL |
| Steps To Reproduce: | You need MMAPv1 database storage with some data created by MongoDB 3.0 on CentOS 6 64-bit. |
| Participants: |
| Description |
|
I have a MMAPv1 database storage that was created with MongoDB 3.0 on CentOS 6 64-bit and later upgraded to MongoDB 3.2.
|
| Comments |
| Comment by Kelsey Schubert [ 23/Dec/15 ] |
|
Hi sime, Thank you for the information. Unfortunately, without a reproduction or the affected data files, we are unable to identify the cause of this issue. If you experience this invariant failure again please keep the data files, and we will reopen this ticket. You may be interested in following a similar issue, Regards, |
| Comment by imun Mikecin [ 17/Dec/15 ] |
|
As far as I can see there were no I/O or block device errors reported in the logs. |
| Comment by imun Mikecin [ 16/Dec/15 ] |
|
1. There was no problem with MongoDB. I restarted because I was debugging reconnection feature of another application that connects to MongoDB database. There were no system restarts and there were no operating system or MongoDB configuration changes. All what was done is that there were many people/applications using (read, write, mapReduce, creating short lived collections, etc.) that database at the time I restarted it (it is used as a development database). 2. Database storage is a local XFS filesystem (with access time updates disabled) dedicated just for a MongoDB on a CentOS 6 64-bit Virtual Machine. Journal is enabled and is not on a separate partition. There were no operations (copy, move, rename, backup or anything alike) on the database files before this issue. 3. I will check this tomorrow and report as soon as I have any info. I don't know if this info is of any help, but few days ago partial and text indexes were added. |
| Comment by Kelsey Schubert [ 16/Dec/15 ] |
|
Hi sime, Thank you for the report. To help us better understand your system and your issue, could you please provide answers to the following questions about your deployment and environment:
Thanks for your help! Regards, |
| Comment by imun Mikecin [ 16/Dec/15 ] |
|
Log above shows unclean shutdown because I pasted the log that was after several attempts to start mongod service. Every attempt kept mongod.lock file. Maybe these lines have something to do with this problem: |
| Comment by Ramon Fernandez Marina [ 16/Dec/15 ] |
|
The log snippet above seems to indicate there was an unclean shutdown before this restart, which may have caused data inconsistencies that now prevent mongod from starting. Can you provide further details on how was mongod shut down before this restart? Can you provide full logs for this node? Also, have you tried running {{validate(full} on your data? |