[DOCS-1862] Page in manual needed on how to deal with a possibly corrupt database Created: 29/Aug/13 Updated: 16/Mar/15 Resolved: 04/Mar/14 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | v1.3.2, mongodb-2.6 |
| Type: | Task | Priority: | Critical - P2 |
| Reporter: | Ian Daniel | Assignee: | Bob Grabar |
| Resolution: | Done | Votes: | 0 |
| Labels: | sprint-rollover | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Days since reply: | 9 years, 50 weeks, 5 days ago | ||||||||||||||||
| Description |
|
Eliot has approved This DOCS ticket is for that page. The page should describe that, if in a replica set, it is preferable to sync the node from scratch, or perhaps to seed it from the data files of another node (if there is no evidence of corruption in that node). Or if not in a replica set, using a recent backup. It should also discuss running validate to help determine if there is evidence of corruption, and the performance hit of doing so. Also repair as a last resort. When complete, we need to edit the dochub link for the key "repair" (see |
| Comments |
| Comment by Sam Kleinman (Inactive) [ 28/Feb/14 ] |
| Comment by Githook User [ 17/Dec/13 ] |
|
Author: {u'username': u'Zackrobat', u'name': u'Zack Brown', u'email': u'zack.brown@10gen.com'}Message: Minor rewrites These need to be extracted from Signed-off-by: Sam Kleinman <samk@10gen.com> |
| Comment by Githook User [ 17/Dec/13 ] |
|
Author: {u'username': u'Zackrobat', u'name': u'Zack Brown', u'email': u'zack.brown@10gen.com'}Message: Minor rewrites These need to be extracted from Signed-off-by: Sam Kleinman <samk@10gen.com> |
| Comment by Githook User [ 05/Dec/13 ] |
|
Author: {u'username': u'tychoish', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}Message: |
| Comment by Githook User [ 05/Dec/13 ] |
|
Author: {u'username': u'tychoish', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}Message: |
| Comment by Githook User [ 05/Dec/13 ] |
|
Author: {u'username': u'Zackrobat', u'name': u'Zack Brown', u'email': u'zack.brown@10gen.com'}Message: Clean up shutdown procedures. Take this out of Signed-off-by: Sam Kleinman <samk@10gen.com> |
| Comment by Githook User [ 05/Dec/13 ] |
|
Author: {u'username': u'Zackrobat', u'name': u'Zack Brown', u'email': u'zack.brown@10gen.com'}Message: Clean up shutdown procedures. Take this out of Signed-off-by: Sam Kleinman <samk@10gen.com> |
| Comment by Ian Daniel [ 04/Sep/13 ] |
|
Hi Sam, Sorry for my delay in responding. I agree that we should use that page rather than write another, however that page will need some changes in order for it to work. The current page focusses on recovering after an unexpected shutdown, especially if journalling is not set. It would need to be generalised (including the title) to recovering from any cause of possible data corruption. If we do not change it, users referred to this page when seeing the warning message in a log file might think, "But there was no unexpected shutdown of the node, and I am running journalling, so this does not refer to me." I also think that the page needs re-ordering so that we state at the start of the page what the recovery process is if you are running in a replica set. My reasoning is that it is a simpler procedure than running repair or validate, so users should not have to wade through the complicated scary procedure to find out that the replica set procedure is much simpler. Kind regards, |
| Comment by Sam Kleinman (Inactive) [ 29/Aug/13 ] |
|
Is the document you describe not the following document: http://docs.mongodb.org/manual/tutorial/recover-data-following-unexpected-shutdown/ Include the following dochub url http://dochub.mongodb.org/core/data-recovery in the server code... Cheers, |