Warning警告
The following procedure applies to standalone 以下过程适用于独立mongod
instance version 4.4. mongod
实例版本4.4。For other MongoDB versions, refer to the corresponding version of the manual.对于其他MongoDB版本,请参阅相应版本的手册。
Do not use this tutorial to recover a member of a replica set. 不要使用本教程来恢复副本集的成员。Instead, you should either restore from a backup or resync from another member of the set, as described in Resync a Member of a Replica Set.相反,您应该从备份中恢复,或者从副本集的另一个成员中重新同步,如“重新同步副本集的成员”中所述。
Tip
If you are running with journaling enabled, there is almost never any need to run repair since the server can use the journal files to restore the data files to a clean state automatically. 如果在启用日志记录的情况下运行,几乎不需要运行修复,因为服务器可以使用日志文件自动将数据文件恢复到干净状态。However, you may need to run repair in cases where you need to recover from a disk-level data corruption.但是,如果需要从磁盘级数据损坏中恢复,则可能需要运行修复。
Disk-level data corruption or missing data files can prevent 磁盘级数据损坏或丢失的数据文件可能会阻止mongod
instance from starting, and journal files may be insufficient to recover automatically:mongod
实例启动,日志文件可能不足以自动恢复:
In such cases, your 在这种情况下,dbPath
contains a non-empty mongod.lock
file.dbPath
包含一个非空的mongod.lock
文件。
The following procedure uses 以下过程使用mongod --repair
to recover from these cases:mongod --repair
从这些情况中恢复:
Warning
Only use 只有在没有其他选择时才使用mongod --repair
if you have no other options. mongod --repair
。The operation removes and does not save any corrupt data during the repair process.该操作会在修复过程中删除并不会保存任何损坏的数据。
Starting in MongoDB 4.4, for the WiredTiger storage engine, 从MongoDB 4.4开始,对于WiredTiger存储引擎mongod --repair
:mongod --repair
:
Important重要的
Run the repair operation as the same user that normally runs the 以正常运行mongod
process to avoid changing the permissions of the MongoDB data files.mongod
进程的用户身份运行修复操作,以避免更改MongoDB数据文件的权限。
Note
If the repair fails to complete for any reason, you must restart the instance with the --repair
option to complete the repair.
[1] | (1, 2) 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. |