[SERVER-1386] Auto-repair for packaged build Created: 09/Jul/10 Updated: 28/Feb/12 Resolved: 28/Feb/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 1.4.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Roger Binns | Assignee: | Unassigned |
| Resolution: | Incomplete | Votes: | 7 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
10gen stable build for Ubuntu 10.4 |
||
| Operating System: | ALL |
| Participants: |
| Description |
|
If the database was not cleanly shutdown then the next start attempt outputs a message to the mongo log and mongodb does not start. This would typically happen in the system boot after the unclean shutdown. A subsequent attempt to start mongodb will start just fine but nothing has changed and the repair really should be run. Trying to do a repair manually is a pain. For example doing it via the shell requires that you 'use' every db and then call repair on that database when you actually want repair to be run on everything. Trying to use the command line 'mongod --repair' means working out how to supply the parameter for the config file, and then afterwards discovering that the repaired database files are now all owned by root. Sure combining sudo, su etc could just about pull it off but is very fiddly. A bigger picture question is "are there any circumstances where you would not want to do a repair"? I suspect maybe some slaving scenarios where the local data is not trusted on startup anyway. I propose there be a key in the config file defaulting to true (except for previous paragraph answers) that automatically runs --repair with the correct parameters and users on restart if there was an unclean shutdown. |
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 28/Feb/12 ] |
|
2.0+ has journalling enabled by default which recovers automatically after a restart. |
| Comment by Aleksander Adamowski [ 28/Feb/12 ] |
|
@Roger: OK, as I understand this has happened somewhen after version 1.8 (which I'm using)? |
| Comment by Roger Binns [ 28/Feb/12 ] |
|
@Aleksander: this ticket should really just be closed as overcome by events. Since this ticket was added almost two years ago, MongoDB has gained journalling functionality which is on by default. Consequently no matter what happened to a machine involving inadvertent power off, MongoDB will still start and function correctly without the need for any repair. |
| Comment by Aleksander Adamowski [ 28/Feb/12 ] |
|
I fully support the idea of autorepair. Moreover, I am of the opinion that this should be enabled by default, and could be disabled in the mongodb.conf file for specific deployments (clusters? high importance production environments?) where standard autorepair might not cut the mustard and a custom solution is deployed. Why would anyone anywhere want to run without some form of autorepair (be it high load production environment, or experimental development environment on a laptop) and be forced to handle things manually each time - is beyond me. |
| Comment by David Backeus [ 11/Nov/10 ] |
|
Agree with this one. A config option for automatic repair in case of a stale lock file seems like a no brainer. We've had some problems with our cloud provider causing 3 hard reboots in the past few month and every time it would cause problems as I was waiting to be notified and be able to remote the server and manually restart mongodb. I never even dared to run the repair as I didn't want to run it from outside the init script. Also I wasn't sure how it would affect my replica sets and there was some scary warning about running repair on MongoDB 1.6 (the note said it would be fixed on 1.6.1 and we're running 1.6.4 but I was still confused enough about the actual workings of repair to do it). |
| Comment by Roger Binns [ 10/Jul/10 ] |
|
You should definitely make doing the actual repair a lot easier with the packaged version. Currently trying to string together the right set of sudo, su, some random mongo binary and its parameters is too hard. My use case is a development environment where the user couldn't care less about Mongo, losing data doesn't matter and each of these steps is an annoying hurdle: Finding out that mongo is not running, finding out why, fixing whatever it is, and starting it up again. You should try explaining any of that over the phone! |
| Comment by Eliot Horowitz (Inactive) [ 10/Jul/10 ] |
|
not sure this makes sense since a repair could theoretically remove data... have to think about it |
| Comment by Roger Binns [ 09/Jul/10 ] |
|
To make life easier can you also add a repair option to the init file? That way I can 'sudo service mongodb repair' rather than having to work out the various parameters, user, config file etc. If I do 'service mongodb start' and it won't start because of the repair issue then I really should be told about it. For example I killed the running monogod with kill -9. $ sudo service mongodb start In this case only doing the grep tells me that mongo failed to start and I have to grovel in the log file to find out the repair message. |
| Comment by auto [ 09/Jul/10 ] |
|
Author: {'login': 'kreuter', 'name': 'Richard Kreuter', 'email': 'richard@10gen.com'}Message: Don't mutilate lock file until lock acquired. Part of |