Advertencia
Vaciado de datos y restauración: conflictos con el prefijo $ en los campos
A partir de MongoDB 5.0, se pueden anteponer nombres de campos de documentos con un carácter de dólar ($). Sin embargo, mongodump y mongorestore no funcionarán con nombres de campo que estén precedidos por un carácter de signo de dólar en las opciones de una colección.
MongoDB Extended JSON (v2) no puede diferenciar entre los contenedores de tipo y los campos que tienen el mismo nombre que los contenedores de tipo. No uses los formatos extendidos de JSON si la representación BSON correspondiente puede incluir claves con el prefijo $. El mecanismo de DBRefs es una excepción a esta regla general.
Comportamiento
Restaurar a la versión del servidor coincidente
Al utilizar mongorestore para cargar archivos de datos creados por mongodump, las versiones de MongoDB de las implementaciones de origen y destino deben ser una de las siguientes:
La misma versión principal.
La misma compatibilidad de características entre versiones.
Por ejemplo, si el vaciado se creó a partir de una implementación de MongoDB que ejecuta la versión 4.4, la implementación de MongoDB al que se restaura también debe ejecutar la versión 4.4 o tener la compatibilidad de características entre versiones configurada en 4.4.
Para cambiar su versión de compatibilidad de características entre versiones, consulte setFeatureCompatibilityVersion.
Nota
Puedes restaurar los archivos BSON generados desde mongodump en implementaciones de MongoDB que ejecuten la misma versión o una más reciente que la de la implementación de origen. Sin embargo, restaurar archivos en una implementación de versión más reciente no es la forma recomendada de actualizar tu implementación. Para aprender cómo actualizar su implementación, consulte la documentación de actualización.
Esta garantía no se aplica a los metadatos, los archivos de archivo ni a los de reproducción de oplog. Si intentas restaurar estos archivos utilizando versiones de implementación de origen y destino diferentes, el proceso mongorestore podría resultar en un fallo, un fallo silencioso o metadatos corruptos.
Además, asegúrate de utilizar la misma versión de mongorestore para cargar los archivos de datos que la versión de mongodump que se utilizó para crearlos. Por ejemplo, si utilizaste mongodump versión 100.18.0 para crear el vaciado, utiliza mongorestore versión 100.18.0 para restaurarlo.
Solo insertar
mongorestore puede crear una nueva base de datos o añadir datos a una base de datos existente. Sin embargo, mongorestore realiza solo inserciones y no realiza actualizaciones. Si restauras documentos a una base de datos y colección existente y los documentos existentes tienen el mismo valor para el campo _id que los documentos a restaurar, mongorestore no sobrescribirá esos documentos.
Orden de documento
Por defecto, mongorestore puede insertar documentos en un orden aleatorio. Para preservar el orden de los documentos durante el proceso de restauración, utilice --maintainInsertionOrder.
Reconstruir índices
mongorestore recrea los índices registrados por mongodump después de restaurar los datos.
Nota
Para las instalaciones de MongoDB con featureCompatibilityVersion (compatibilidad de características entre versiones) configuradas en "4.0" o anterior, la creación de índices generará un error si una clave de índice en un documento existente supera el límite.
Para evitar este problema, considera usar índices hash o indexación un valor calculado en su lugar. Para resolver el problema del índice después de la restauración de los datos, puedes desactivar la validación por defecto de la longitud de la clave de índice en la base de datos de destino configurando el parámetro mongod instancia's failIndexKeyTooLong en falso.
Excluir system.profile Colección
mongorestore no restaura los datos de la colección system.profile.
FIPS
mongorestore crea automáticamente conexiones compatibles con FIPS a mongod/mongos que está configurado para utilizar el modo FIPS
Nivel de confirmación de escritura
Si especificas el nivel de confirmación de escritura (write concern) tanto en la opción --writeConcern como en la opción de cadena de conexión --uri, el valor de --writeConcern sobrescribirá el nivel de confirmación de escritura (write concern) especificado en la cadena URI.
Colecciones de series de tiempo
A partir de MongoDB 5.0, puedes utilizar mongorestore para restaurar colecciones de series temporales. Para más detalles, consulta Restaurar una colección de series de tiempo.
Reproducción de Oplog en una conversión de formato de serie de tiempo
MongoDB 8.x y MongoDB 9.0 almacenan colecciones de series de tiempo en diferentes formatos:
En MongoDB 8.x, una colección de series de tiempo consta de una vista y una colección
system.buckets.<collection>separada.A partir de MongoDB 9.0, una colección de series de tiempo es una única colección.
Cuando utiliza setFeatureCompatibilityVersion para cambiar la compatibilidad de características entre versiones (FCV) en este límite, el servidor convierte cada colección de series de tiempo al formato que coincide con la nueva FCV. El servidor registra cada conversión en el oplog.
Cada conversión también cambia el namespace al que se dirigen las escrituras de depósito, de system.buckets.<collection> a <collection>. Las entradas de oplog registradas antes de una conversión no coinciden con el formato de colección que las sigue.
Como resultado, mongorestore no puede reproducir un rango de oplog que abarque una conversión. Restaure las entradas de cada lado de la conversión como rangos separados y cambie la compatibilidad de características entre versiones en la implementación de destino entre las dos restauraciones:
Reproduzca las entradas de oplog que preceden a la conversión.
Utilice --oplogLimit para detener la reproducción antes de la conversión.
Cambie la compatibilidad de características entre versiones en la implementación de destino.
Ejecuta setFeatureCompatibilityVersion en el destino para realizar el mismo cambio de compatibilidad de características entre versiones, en la misma dirección, que produjo la conversión.
Se requiere el cambio de compatibilidad de características entre versiones en el destino. mongorestore nunca cambia la compatibilidad de características entre versiones y no reescribe los namespace en toda la conversión. Si el destino permanece en una compatibilidad de características entre versiones para ambas restauraciones, las entradas del segundo rango nombran un namespace que no coincide con el formato de colección del destino. La restauración falla.
A partir de Database Tools 100.18.0, mongorestore falla con un mensaje que nombra la conversión cuando la encuentra durante --oplogReplay. Las versiones anteriores de Database Tools informan de un comando oplog desconocido en su lugar.
Para evitar producir un vaciado que no se pueda restaurar, no cambie la compatibilidad de características entre versiones mientras se ejecuta mongodump --oplog. Si captura el oplog usted mismo con mongodump --db=local --collection=oplog.rs y lo reproduce con --oplogFile, mongodump no puede detectar el cambio de compatibilidad de características entre versiones, así que compruebe que el rango que restaura no abarque una conversión.
Uso de mongorestore en los clústeres gratuitos y flexibles de Atlas
En los clústeres Free (M0) y Flex, se aplican las siguientes limitaciones:
No puedes ejecutar
mongorestoreen la base de datosadmin. Por defecto,mongorestoreomite esta base de datos. Si utilizas la opción--dbpara establecer la base de datos de destino enadmin, el programa devuelve un error.No puedes usar las siguientes opciones con el programa
mongorestore:
Comportamiento en caso de error
Si mongorestore falla, puede dejar el sistema en un estado inconsistente en el que parte de los datos se restauraron, pero no todos. Después de un fallo, borra cualquier dato restaurado y vuelve a ejecutar el proceso desde el principio.
Nota
Reversiones del clúster de destino
Si el clúster sufre un rollback durante el proceso de restauración, elimine todos los datos restaurados o importados y realice el proceso nuevamente desde el principio. Ver la documentación de rollback para obtener más detalles.
Acceso requerido
Para restaurar los datos en una implementación de MongoDB que tiene control de acceso habilitado, el rol restore proporciona los privilegios necesarios para restaurar los datos de las copias de seguridad si los datos no incluyen datos de la colección system.profile y ejecuta mongorestore sin la opción --oplogReplay.
Nota
Si el clúster de destino es un clúster de MongoDB Atlas, se requiere el rol Atlas admin en su lugar. MongoDB Atlas no ofrece un/a restore rol, privilegio o acción de privilegio individual. Para obtener más información, consulte Configurar usuario de base de datos.
Si los datos de copia de seguridad incluyen los datos de una colección system.profile o si ejecutas mongorestore con la opción --oplogReplay, necesitas privilegios adicionales:
| Si los datos de la copia de seguridad incluyen datos de la colección Tanto los roles incorporados |
| Para ejecutar con Otorgue solo a los usuarios que deben ejecutar |
Uso en la estrategia de copia de seguridad
Sistemas autónomos/sets de réplicas
Para obtener una descripción general del uso de mongorestore como parte de una estrategia de copia de seguridad y recuperación, consulta Respaldar y Restaurar con las Herramientas de MongoDB.
Clústeres fragmentados
Para utilizar mongodump y mongorestore como estrategia de copia de seguridad para clústeres particionados, consulte Copia de seguridad de un clúster particionado autogestionado con un volcado de base de datos.
Los clústeres fragmentados también pueden utilizar uno de los siguientes procesos coordinados de copia de seguridad y restauración, que garantizan la atomicidad entre particiones mientras siguen admitiendo escrituras: