Advertencia
El siguiente procedimiento se aplica a los dispositivos independientes mongod
Versión de instancia 8.2. 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.
Crear una copia de seguridad de los archivos de datos.
Cree una copia de seguridad de los archivos de datos --dbpath en.
Comience mongod --repaircon.
Para reparar los archivos de datos, inicie la instancia mongod --repair con la opción.
Emita un comando similar al siguiente para su sistema independiente:
mongod --dbpath /data/db --repair
Al finalizar, el dbpath archivo debe contener los archivos de datos reparados y un mongod.lock archivo 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] | Generalmente, no se debe eliminar manualmente el archivo mongod.lock. En su lugar, utilice el procedimiento anterior para recuperar la base de datos. En situaciones extremas, puede eliminar el archivo, iniciar la base de datos con los archivos posiblemente dañados e intentar recuperar los datos. Sin embargo, es imposible predecir el estado de la base de datos en estas situaciones. |