Skip to content

DOCS-385 change to clarifiy recovery on replica sets #112

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
Aug 8, 2012
Merged

DOCS-385 change to clarifiy recovery on replica sets #112

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
14 changes: 10 additions & 4 deletions source/tutorial/recover-data-following-unexpected-shutdown.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,12 @@ 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
recover data that may be in an inconsistent state.
If you are *not* running as part of a :term:`replica set` **and** do
*not* have journaling enabled use the following procedure to recover
data that may be in an inconsistent state. If you are running as part
of a replica set, you should *always* restore from a backup or restart
the :program:`mongod` instance with an empty :setting:`dbpath` and
allow MongoDB to resync the data.

.. seealso:: The ":doc:`/administration`" documents and the
documentation of the :setting:`repair`, :setting:`repairpath`, and
Expand All @@ -34,8 +38,10 @@ Indications
~~~~~~~~~~~

When you are aware of a :program:`mongod` instance running without
journaling that stops unexpectedly, you should always run the repair
operation before starting MongoDB again.
journaling that stops unexpectedly **and** you're not running with
replication, you should always run the repair operation before
starting MongoDB again. If you're using replication, then restore from
a backup and allow replication to synchronize your data.

If the ``mongod.lock`` file in the data directory specified by
:setting:`dbpath`, ``/data/db`` by default, is *not* a zero-byte file,
Expand Down