Skip to content

edits to recovery document #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 4, 2012
Merged

edits to recovery document #20

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 11 additions & 9 deletions aspiration/tutorial/recover-data-following-unexpected-shutdown.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
<setting-journal>`. 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
Expand All @@ -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
Expand All @@ -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
~~~~~~~~
Expand Down Expand Up @@ -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 </administration/backup>` or if running as a :term:`replica
set` re-sync from an intact member of the set.