From 12b177e1cb674fdf7caff2596bca2743fc395d95 Mon Sep 17 00:00:00 2001 From: barrie Date: Fri, 4 May 2012 18:50:16 -0400 Subject: [PATCH] edits to recovery document --- ...ver-data-following-unexpected-shutdown.txt | 20 ++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/aspiration/tutorial/recover-data-following-unexpected-shutdown.txt b/aspiration/tutorial/recover-data-following-unexpected-shutdown.txt index 2939c20c566..48e8a3f5eab 100644 --- a/aspiration/tutorial/recover-data-following-unexpected-shutdown.txt +++ b/aspiration/tutorial/recover-data-following-unexpected-shutdown.txt @@ -6,13 +6,13 @@ Recover MongoDB Data following Unexpected Shutdown If MongoDB does not shutdown cleanly [#clean-shutdown]_ the on-disk representation of the data files will likely reflect an inconsistent -state which leads to data corruption. +state which could lead to data corruption. To prevent data inconsistency and corruption, always shut down the database cleanly, and use the :ref:`durability journaling `. The journal writes data to disk every 100 -milliseconds by default, and ensurers that MongoDB will be able to -recover a constant state even in the case of a unclean shutdown due to +milliseconds by default, and ensures that MongoDB will be able to +recover a constant state even in the case of an unclean shutdown due to power loss or other system failure. If you do not have journaling enabled, use the following procedure to @@ -34,7 +34,7 @@ Indications ~~~~~~~~~~~ When you are aware of a :program:`mongod` instance running without -journaling that stops unexpectedly you should always run the repair +journaling that stops unexpectedly, you should always run the repair operation before starting MongoDB again. If the ``mongod.lock`` file in the data directory specified by @@ -57,7 +57,7 @@ contains the following line: old lock file: /data/db/mongod.lock. probably means unclean shutdown You must remove the lockfile **and** run the repair operation before -starting the database normally using the following procedure. +starting the database normally using the following procedure: Overview ~~~~~~~~ @@ -149,12 +149,14 @@ the following procedure: In normal operation, you should **never** remove the ``mongod.lock`` file and start :program:`mongod`. Instead use one of the above methods -to recover the database and remove the lock files. In dire you -situations can remove the lockfile, and start the database using the +to recover the database and remove the lock files. In dire +situations you can remove the lockfile, and start the database using the possibly corrupt files, and attempt to recover data from the database; however, it's impossible to predict the state of the database in these situations. If you are not running with journaling, and your database shuts down -unexpectedly for *any* reason, you should always assume that your -database is in an inconsistent and likely corrupt state. +unexpectedly for *any* reason, you should always proceed *as if* your database +is in an inconsistent and likely corrupt state. If at all possible restore +from :doc:`backup ` or if running as a :term:`replica +set` re-sync from an intact member of the set.