Fetching contributors…
Cannot retrieve contributors at this time
56 lines (39 sloc) 1.93 KB
Recover a Standalone after an Unexpected Shutdown
.. default-domain:: mongodb
When a standalone :binary:`~bin.mongod` instance has journaling disabled
[#journaling-on]_, an unclean shutdown may leave the data in an
inconsistent state. Following an unclean shutdown, if a non-empty
``mongod.lock`` file exists, :binary:`~bin.mongod` instance logs the
following message upon restart:
.. code-block:: none
Detected unclean shutdown - mongod.lock is not empty.
If your :setting:`~storage.dbPath` contains a non-empty ``mongod.lock``
file, you must repair the database. This tutorial outlines the
procedure to repair your database for a standalone :binary:`~bin.mongod`.
.. warning::
Do not use this tutorial to recover a member of a :term:`replica
set`. Instead, you should either restore from a :doc:`backup
</core/backups>` or resync from another member of the set, as
described in :doc:`/tutorial/resync-replica-set-member`.
.. [#journaling-on]
By default, MongoDB runs with :doc:`journaling </core/journaling>`
enabled to prevent data inconsistency in the event of an unclean
shutdown. To shut down cleanly, see
.. _tutorial-repair-procedures:
.. important::
Run the repair operation as the same user that normally runs the
:binary:`~bin.mongod` process to avoid changing the permissions of the
MongoDB data files.
.. include:: /includes/steps/recover-data-with-repairpath.rst
.. [#manual-removal]
Generally, you should not manually remove the ``mongod.lock`` file.
Instead, use the above procedure to recover the database. In dire
situations, you can remove the file, start the database using the
possibly corrupt files, and attempt to recover data from the
database. However, it is impossible to predict the state of the
database in these situations.