Este procedimiento describe el proceso para tomar datos de MongoDB y restaurarlos en una nueva base de datos. set de réplicas. Utiliza este enfoque para sembrar implementaciones de prueba a partir de copias de seguridad de producción o como parte de la recuperación ante desastres.
Importante
No puedes restaurar un único conjunto de datos a tres nuevas mongod instancias y luego crear un set de réplicas. Si copias el conjunto de datos en cada instancia mongod y luego creas el set de réplicas, MongoDB obligará a las secundarias a realizar una sincronización inicial. Los procedimientos de este documento describen las formas correctas y eficientes de implementar un set de réplicas restaurado.
También se puede utilizar mongorestore para restaurar archivos de bases de datos utilizando datos creados con mongodump. Consulta Respaldar y restaurar una implementación autogestionada con MongoDB Tools para obtener más información.
Considerations
Las copias de seguridad proporcionan una snapshot del estado actual de la base de datos. Cuando restauras a partir de una copia de seguridad, la base de datos restaurada no incluye ningún cambio realizado después de que se haya hecho la copia de seguridad, lo que puede provocar pérdida de datos.
Restaurar base de datos en un set de réplicas de un solo nodo
Obtener archivos de copia de seguridad de la base de datos de MongoDB.
Los archivos de copia de seguridad pueden provenir de una instantánea del sistema de archivos. El MongoDB Cloud Manager produce archivos de base de datos MongoDB para snapshots almacenadas y snapshots puntuales. Para Ops Manager, una solución on-premise disponible en MongoDB Enterprise Advanced, consulta también el Resumen de copia de seguridad de Ops Manager.
- Consideraciones para motores de almacenamiento cifrado
- Para los motores de almacenamiento cifrados que utilizan el modo de cifrado
AES256-GCM,AES256-GCMexige que cada proceso use un valor de bloque contador único con la clave.Para motor de almacenamiento cifrado configurado conAES256-GCMcifrado:- Restauración desde una copia de seguridad en caliente
- A partir de la versión 4.2, si restaura desde archivos obtenidos mediante una copia de seguridad "en caliente" (es decir, mientras
mongodestá en ejecución), MongoDB puede detectar claves "sucias" en el inicio y cambiar automáticamente la clave de la base de datos para evitar la reutilización del IV (vector de inicialización).
- Restauración desde una copia de seguridad en frío
Sin embargo, si restaura desde archivos obtenidos mediante una copia de seguridad "en frío" (es decir,
mongodno está en ejecución), MongoDB no puede detectar las claves "sucias" en el inicio, y la reutilización de IV invalida las garantías de confidencialidad e integridad.A partir de la versión 4.2, para evitar la reutilización de las claves después de restaurar desde un snapshot del sistema de archivos en frío, MongoDB agrega una nueva opción de línea de comandos
--eseDatabaseKeyRollover. Al iniciarse con la opción--eseDatabaseKeyRollover, la instanciamongodcambia las claves de la base de datos configuradas con el cifradoAES256-GCMy se cierra.
Descarte la base de datos local si existe en la copia de seguridad.
Si va a restaurar desde una copia de seguridad del sistema de archivos (o cualquier copia de seguridad con la base de datos local), descarte la base de datos local.
Inicia un mongod autónomo usando los archivos de datos de la copia de seguridad como la ruta de datos.
También debes especificar las mismas opciones de inicio que se usaron al crear la snapshot.
mongod --dbpath /data/db <startup options>
Elimina la base de datos local.
Conecta mongosh a la instancia mongod y descarta la base de datos local.
use local db.dropDatabase()
Apagar el autónomo.
Iniciar un nuevo set de réplicas de un solo nodo.
Inicie una instancia como un nuevo conjunto de réplicas de un solo nodo. Especifique la ruta a los archivos de datos de respaldo mongod --dbpath con la opción y el nombre del conjunto de réplicas con la --replSet opción. Para el conjunto de réplicas del servidor de configuración (CSRS), incluya la opción. Incluya cualquier otra opción según corresponda a su --configsvr implementación.
También debes especificar las mismas opciones de inicio que se usaron al crear la snapshot.
Nota
Si los miembros de tu set de réplicas se ejecutan en hosts diferentes o si deseas que clientes remotos se conecten a tu instancia, debes especificar la configuración net.bindIp (o --bind_ip).
Advertencia
Antes de enlazar a un host que no sea localhost (por ejemplo, Públicamente accesible) dirección IP, asegúrese de que ha protegido su clúster de accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, consulta la Lista de verificación de seguridad para implementaciones autogestionadas. Como mínimo, considera activar la autenticación y fortalecer la infraestructura de red.
mongod --dbpath /data/db --replSet <replName> <startup options>
Nota
Todas las colecciones de MongoDB tienen UUIDs por defecto. Cuando MongoDB restaura colecciones, las colecciones restauradas conservan sus UUID originales. Al restaurar una colección en la que no había UUID, MongoDB genera un UUID para la colección restaurada.
Para obtener más información sobre los UUID de colecciones, consulte las Colecciones.
Conecte mongosh a la instancia mongod.
Desde la misma máquina en la que se ejecuta uno de los mongod (en este tutorial, mongodb0.example.net), inicia mongosh. Para conectarte al mongod que escucha en localhost por el puerto predeterminado 27017, simplemente ejecuta:
mongosh
Dependiendo de la ruta, es posible que debas especificar la ruta al binario mongosh.
Si tu mongod no se está ejecutando en el puerto por defecto, especifica la opción --port para mongosh.
Iniciar el nuevo set de réplicas.
Utiliza rs.initiate() en un y solo un nodo del set de réplicas:
rs.initiate( { _id : <replName>, members: [ { _id : 0, host : <host:port> } ] })
MongoDB inicia un conjunto que consta del miembro actual y que utiliza la configuración del conjunto de réplicas predeterminada.
Añadir nodos al set de réplicas
MongoDB proporciona dos opciones para restaurar miembros secundarios de un set de réplicas:
Copie manualmente los archivos de la base de datos a cada directorio de datos.
Permitir sincronización inicial para distribuir datos automáticamente.
Nota
Si tu base de datos es grande, la sincronización inicial puede tardar mucho tiempo en completarse. En el caso de bases de datos grandes, podría ser preferible copiar los archivos de la base de datos en cada host.
Copiar archivos de la base de datos y reiniciar la instancia de mongod
Utiliza la siguiente secuencia de operaciones para "sembrar" miembros adicionales del set de réplicas con los datos restaurados copiando directamente los archivos de datos de MongoDB.
Apague la instancia mongod que restauró.
Utiliza --shutdown o db.shutdownServer() para garantizar un apagado limpio.
Inicie la instancia que mongod restauró.
Agregue los secundarios al set de réplicas.
En una sesión mongosh conectada a la principal,agregue las secundarias al conjunto de réplicas mediante el rs.add() método. Consulte Implementar un conjunto de réplicas autoadministrado para obtener más información sobre la implementación de un conjunto de réplicas.
Actualizar secundarios mediante Sincronización inicial
Utiliza la siguiente secuencia de operaciones para “inicializar” nodos adicionales del set de réplicas con los datos restaurados utilizando la operación de sincronización inicial por defecto.
Vacíe el directorio de datos para cada posible miembro del conjunto de réplicas.
Por ejemplo, si el miembro del conjunto de réplicas tiene un storage.dbPath o --dbpath /data/dbde,debe asegurarse de que el directorio exista y esté vacío.
Agrega cada nodo potencial al conjunto de réplicas.
Conéctate a la primaria usando el mongo shell y añade cada secundaria al set de rs.add() réplicas.
Al añadir un nodo al set de réplicas, Sincronización inicial copia los datos del primario al nodo nuevo.