Advertencia
El siguiente procedimiento se aplica al autónomo mongod
versión de la instancia 8.0. Para otras versiones de MongoDB, consulte la versión correspondiente del manual.
No utilices este tutorial para recuperar a un nodo de un set de réplicas. En su lugar, deberías restaurar desde una copia de seguridad o resincronizar desde otro miembro del set, como se describe en Resincronizar un miembro de un set de réplicas autogestionado.
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 los archivos de datos faltantes pueden evitar que la instancia mongod se inicie, y es posible que los archivos de registro no sean suficientes para recuperarse 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 dbPath contiene un archivo mongod.lock que no está vacío.
El siguiente procedimiento utiliza mongod --repair para recuperarse en estos casos:
Advertencia
Utilice mongod --repair solo si no tiene otras opciones. La operación remueve y no guarda ningún dato corrupto durante el proceso de 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
Ejecuta la operación de reparación como el mismo usuario que normalmente ejecuta el proceso mongod para evitar cambiar los permisos de los archivos de datos de MongoDB.
Crea una copia de seguridad de los archivos de datos.
Cree una copia de seguridad de los archivos de datos en el --dbpath.
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 cualquier motivo, debe reiniciar la instancia con la opción --repair para completar la 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. |