[SERVER-27820] Improve storage engine logging at startup to include additional failure information Created: 26/Jan/17 Updated: 09/Jul/18 Resolved: 09/Jul/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | WiredTiger |
| Affects Version/s: | 3.2.10 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Nick Judson | Assignee: | Xiangyu Yao (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Sprint: | Storage NYC 2018-07-02, Storage NYC 2018-07-16 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
I've encountered the following in on a test system running 3.2.10 on Windows:
All the folders listed exist and are writeable, and none are locked. Clearly there has been an "unclean shutdown" which has caused some corruption - but it's difficult to know what the proper action would be in this case: Restore from backup, clear mongo.lock etc. If possible, additional logging information here would be appreciated. |
| Comments |
| Comment by Xiangyu Yao (Inactive) [ 09/Jul/18 ] |
|
I am closing this ticket as a dup of |
| Comment by Alexander Gorrod [ 28/Jun/18 ] |
|
I believe what is being asked for here is a log message indicating a way forward from the error - which needs to be owned by MongoDB. i.e: Should the user then attempt to start with --repair, or remove the data and re-sync from another node in a replica set, or something else. Maybe ideally there could be a documentation page describing what to do in case of on-disk corruption which we could link to in a message before exiting? Maybe a generalized version of this page https://docs.mongodb.com/manual/tutorial/recover-data-following-unexpected-shutdown/ |
| Comment by Eric Milkie [ 18/Apr/18 ] |
|
I believe the work for this will involve enhancing the WiredTiger code for situations where wiredtiger_open() can return ENOENT, as it did in the example in the Description. We should log an informational message with context at those points prior to returning ENOENT. |
| Comment by Alexander Gorrod [ 07/Mar/17 ] |
|
Thanks Nick - happily it looks like we will be able to improve the error message, since we now understand better where it originates from. |
| Comment by Nick Judson [ 07/Mar/17 ] |
|
@Alexander - Sorry - it's long gone. |
| Comment by Alexander Gorrod [ 07/Mar/17 ] |
|
nick@innsenroute.com Another user has encountered a similar symptom - see |
| Comment by Nick Judson [ 21/Feb/17 ] |
|
It just took me a while to digest the error message and I figured that if I found it confusing, other people probably will too. I think the big thing was the filename of '2'. Maybe a fully qualified path or putting it in quotes? Generally I think verbosity can be a good thing for major errors (especially those that stop the application from running)... |
| Comment by Alexander Gorrod [ 21/Feb/17 ] |
|
nickj Thanks for the report. The error message reported is generally more useful than is shown here. The database is attempting to open a file called 2 that doesn't exist, which makes the error messages confusing. It isn't a failure mode I've seen before, and MongoDB doesn't generally create files with numerical names - is that something we need to investigate, or are you only asking about the verbosity of the error message? |
| Comment by Nick Judson [ 26/Jan/17 ] |
|
I'm of mixed opinion here actually. On the one hand it does state that mongo.lock isn't empty, and perhaps that is enough information. What might be nice to see is something like this: ... |