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.
El formato JSON extendido de MongoDB2 (v) no distingue entre envoltorios de tipo y campos con el mismo nombre que los envoltorios de tipo. No utilice formatos JSON extendidos si la representación BSON correspondiente puede incluir claves con el $ prefijo. El mecanismo 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 la versión de compatibilidad de sus características,setFeatureCompatibilityVersion consulte.
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, considere usar índices hash o indexar un valor calculado. Para resolver el problema del índice después de restaurar los datos, puede deshabilitar la validación predeterminada de la longitud de la clave del índice en la base de datos de destino estableciendo el parámetro de la instancia mongod failIndexKeyTooLong en falso.
Excluir la colección system.profile
mongorestore no restaura los system.profile datos de la colección.
FIPS
mongorestore crea automáticamente conexiones compatibles con FIPS a un mongod/mongos que está configurado para usar 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 setFeatureCompatibilityVersion se utiliza para cambiar la versión de compatibilidad de características (FCV) a través de este límite, el servidor convierte cada colección de series temporales 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.
setFeatureCompatibilityVersion Ejecute en el objetivo para realizar el mismo cambio de FCV, 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 datos en una implementación de MongoDB que tiene el control de acceso habilitado, el restore rol proporciona los privilegios necesarios para restaurar datos desde copias de seguridad si los datos no incluyen system.profile datos de la colección y ejecuta mongorestore sin la --oplogReplay opción.
Nota
Si el clúster de destino es un clúster de MongoDB Atlas, se Atlas admin requiere el rol. MongoDB Atlas no ofrece un restore rol, privilegio ni acción de privilegio individual. Para obtener más información, consulte Configurar usuarios de la base de datos.
Si los datos de respaldo incluyen datos de recopilación o system.profile ejecuta mongorestore con la opción, necesita privilegios --oplogReplay adicionales:
| Si los datos de respaldo incluyen Tanto los roles integrados |
| 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: