发布于 2015-09-14 14:56:00 | 197 次阅读 | 评论: 0 | 来源: 网络整理
If MongoDB does not shutdown cleanly [1] the on-disk representation of the data files will likely reflect an inconsistent state which could lead to data corruption. [2]
To prevent data inconsistency and corruption, always shut down the database cleanly and use the durability journaling. The journal writes data to disk every 100 milliseconds by default and ensures that MongoDB can recover to a consistent state even in the case of an unclean shutdown due to power loss or other system failure.
If you are not running as part of a 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 mongod instance with an empty dbpath and allow MongoDB to perform an initial sync to restore the data.
也可以参考
The 管理 documents, including Replica Set Syncing, and the documentation on the repair, repairpath, and journal settings.
| [1] | To ensure a clean shut down, use the mongod --shutdown option, your control script, “Control-C” (when running mongod in interactive mode,) or kill $(pidof mongod) or kill -2 $(pidof mongod). |
| [2] | You can also use the db.collection.validate() method to test the integrity of a single collection. However, this process is time consuming, and without journaling you can safely assume that the data is in an invalid state and you should either run the repair operation or resync from an intact member of the replica set. |
When you are aware of a mongod instance running without 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 perform an initial sync to restore data.
If the mongod.lock file in the data directory specified by dbpath, /data/db by default, is not a zero-byte file, then mongod will refuse to start, and you will find a message that contains the following line in your MongoDB log our output:
Unclean shutdown detected.
This indicates that you need to remove the lockfile and run repair. If you run repair when the mongodb.lock file exists without the mongod --repairpath option, you will see a message that 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:
警告
Recovering a member of a replica set.
Do not use this procedure to recover a member of a replica set. Instead you should either restore from a backup or perform an initial sync using data from an intact member of the set, as described in Resyncing a Member of a Replica Set.
There are two processes to repair data files that result from an unexpected shutdown:
Use the --repair option in conjunction with the --repairpath option. mongod will read the existing data files, and write the existing data to new data files. This does not modify or alter the existing data files.
You do not need to remove the mongod.lock file before using this procedure.
Use the --repair option. mongod will read the existing data files, write the existing data to new files and replace the existing, possibly corrupt, files with new files.
You must remove the mongod.lock file before using this procedure.
注解
--repair functionality is also available in the shell with the db.repairDatabase() helper for the repairDatabase command.
To repair your data files using the --repairpath option to preserve the original data files unmodified:
Start mongod using --repair to read the existing data files.
mongod --dbpath /data/db --repair --repairpath /data/db0
When this completes, the new repaired data files will be in the /data/db0 directory.
Start mongod using the following invocation to point the dbpath at /data/db2:
mongod --dbpath /data/db0
Once you confirm that the data files are operational you may delete or archive the data files in the /data/db directory.
To repair your data files without preserving the original files, do not use the --repairpath option, as in the following procedure:
Remove the stale lock file:
rm /data/db/mongod.lock
Replace /data/db with your dbpath where your MongoDB instance’s data files reside.
警告
After you remove the mongod.lock file you must run the --repair process before using your database.
Start mongod using --repair to read the existing data files.
mongod --dbpath /data/db --repair
When this completes, the repaired data files will replace the original data files in the /data/db directory.
Start mongod using the following invocation to point the dbpath at /data/db:
mongod --dbpath /data/db
In normal operation, you should never remove the mongod.lock file and start mongod. Instead consider the one of the above methods 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 proceed as if your database is in an inconsistent and likely corrupt state. If at all possible restore from backup or, if running as a replica set, restore by performing an initial sync using data from an intact member of the set, as described in Resyncing a Member of a Replica Set.