Advertencia
El siguiente procedimiento se aplica al autónomo mongod
Versión de instancia 6.0. Para otras versiones de MongoDB, consulte la versión correspondiente del manual.
No utilice este tutorial para recuperar un miembro de un conjunto de réplicas. En su lugar, debe restaurar desde una copia de seguridad o resincronizar desde otro miembro del conjunto, como se describe en Resincronizar un miembro de un conjunto de réplicas autoadministrado.
Tip
Si está ejecutando con el registro en la bitácora habilitado, casi nunca es necesario ejecutar una reparación ya que el servidor puede usar los archivos del registro para restaurar los archivos de datos a un estado limpio automáticamente. Sin embargo, es posible que deba ejecutar una reparación en los casos en que necesite recuperarse de una corrupción de datos a nivel de disco.
La corrupción de datos a nivel de disco o archivos de datos faltantes pueden impedir que la instancia se inicie, y los archivos de diario pueden ser insuficientes para recuperarse mongod automáticamente:
2018-10-24T18:05:18.248-04:00 W STORAGE [initandlisten] Detected unclean shutdown - mongod.lock is not empty. ... 2018-10-24T17:24:53.122-04:00 E STORAGE [initandlisten] Failed to get the cursor for uri: table:collection-2-6854866147293273505 2018-10-24T17:24:53.122-04:00 E STORAGE [initandlisten] This may be due to missing data files. ... ... ***aborting after fassert() failure
En tales casos, su contiene dbPath un mongod.lock archivo que no está vacío.
El siguiente procedimiento utiliza para recuperarse de estos mongod --repair casos:
Advertencia
Utilice solo si no tiene otras opciones. La operación elimina y no guarda los datos dañados durante el proceso de mongod --repair reparación.
Para el motor de almacenamiento WiredTiger, mongod --repair:
Reconstruye todos los índices de las colecciones con uno o más índices inconsistentes.
Descarta datos corruptos.
Crea archivos vacíos/de marcador de posición para los archivos de datos/metadatos que falten.
Procedimiento
Importante
Ejecute la operación de reparación como el mismo usuario que normalmente ejecuta el proceso para evitar cambiar los permisos de los archivos de datos de mongod MongoDB.
Crea una copia de seguridad de los archivos de datos.
Cree una copia de seguridad de los archivos de datos --dbpath en.
Comienza mongod con --repair.
Para reparar los archivos de datos, inicia la mongod instancia con la opción --repair.
Emite un comando similar al siguiente para tu autónomo:
mongod --dbpath /data/db --repair
Al completar, el dbpath debe contener los archivos de datos reparados y un archivo mongod.lock vacío. [1]
Nota
Si la reparación no se completa por algún motivo, debe reiniciar la instancia con la opción para completar la --repair reparación.
| [1] | Por lo general, no debe remover manualmente el archivo mongod.lock. En su lugar, utiliza el procedimiento anterior para recuperar la base de datos. En situaciones críticas, puedes remover el archivo, iniciar la base de datos utilizando los archivos que posiblemente están dañados e intentar recuperar datos de la base de datos. Sin embargo, en estas situaciones es imposible predecir el estado de la base de datos. |