sql >> Base de Datos >  >> NoSQL >> MongoDB

Cómo migrar datos en MongoDB

El objetivo de esta publicación es conocer las diversas formas de migración de datos en MongoDB que pueden ayudarnos a escribir scripts que cambien su base de datos al agregar nuevos documentos y modificar los existentes.

Si viene aquí por primera vez, eche un vistazo a la precuela Self-Hosted MongoDB.

Muy bien, retomando desde donde lo dejamos, comencemos con la migración de datos en MongoDB.

Ahora bien, los pasos básicos para migrar datos de una MongoDB a otra serían:

  1. Cree una copia de seguridad comprimida de los datos existentes
  2. Volcar los datos en una nueva base de datos

Esto es muy sencillo cuando la base de datos de origen no está en línea porque sabemos que no se crearán/actualizarán documentos nuevos durante el proceso de migración. Veamos primero la migración simple antes de sumergirnos en el escenario en vivo.

Migrar desde una base de datos sin conexión en MongoDB

Creando una copia de seguridad

Vamos a utilizar un programa de utilidad existente mongodump para crear la copia de seguridad de la base de datos.

Ejecute este comando en el servidor de la base de datos de origen

mongodump --host="hostname:port" \
  --username="username" --password="password" \
  --authenticationDatabase "admin" \
  --db="db name" --collection="collection name" --query='json' \
  --forceTableScan -v --gzip --out ./dump

--host :El nombre de host MongoDB de origen junto con el puerto. Por defecto es localhost:27017 . Si es una cadena de conexión, puede usar esta opción —-uri="mongodb://username:password@host1[:port1]..."

--username :especifica un nombre de usuario para autenticarse en una base de datos MongoDB que usa autenticación.

--password :especifica una contraseña para autenticarse en una base de datos MongoDB que usa autenticación.

--authenticationDatabase :Especifica la base de datos de autenticación donde el --username especificado ha sido creado.

Si no especifica una base de datos de autenticación o una base de datos para exportar, mongodump asume que la base de datos de administración contiene las credenciales del usuario.

--db :especifica la base de datos de la que se realizará una copia de seguridad. Si no especifica una base de datos, mongodump recopila de todas las bases de datos en esta instancia.

Alternativamente, también puede especificar la base de datos directamente en la cadena de conexión URI, es decir, mongodb://username:password@uri/dbname .
Proporcionar una cadena de conexión al mismo tiempo que se usa --db y especificar información contradictoria dará como resultado un error .

--collection :Especifica una colección para respaldar. Si no especifica una colección, esta opción copia todas las colecciones en la base de datos o instancia especificada en los archivos de volcado.

--query :proporciona un documento JSON como una consulta que, opcionalmente, limita los documentos incluidos en la salida de mongodump.
Debe encerrar el documento de consulta entre comillas simples ('{ ... }') para garantizar que no interactúe con su entorno.
La consulta debe estar en formato Extended JSON v2 (ya sea en modo relajado o canónico/estricto), incluyendo los nombres de los campos y los operadores entre comillas, p. '{ "created_at": { "\$gte": ISODate(...) } }' .

Para utilizar --query opción, también debe especificar la --collection opción.

--forceTableScan :Obliga a mongodump a escanear el almacén de datos directamente. Por lo general, mongodump guarda las entradas tal como aparecen en el índice de _id campo.

Si especifica una consulta --query , mongodump usará el índice más apropiado para respaldar esa consulta.
Por lo tanto, no puede usar --forceTableScan con el --query opción .

--gzip :Comprime la salida. Si mongodump da salida al directorio de volcado, la nueva función comprime los archivos individuales. Los archivos tienen el sufijo .gz .

--out :especifica el directorio donde mongodump escribirá BSON archivos para las bases de datos volcadas. De forma predeterminada, mongodump guarda los archivos de salida en un directorio llamado dump en el directorio de trabajo actual.

Restauración de la copia de seguridad

Usaremos un programa de utilidad llamado mongorestore para restaurar la copia de seguridad de la base de datos.

Copie el volcado del directorio de copia de seguridad en la nueva instancia de la base de datos y ejecute el siguiente comando:

mongorestore --uri="mongodb://user:password@host:port/?authSource=admin" \
  --drop --noIndexRestore --gzip -v ./dump

Reemplace las credenciales con las nuevas credenciales de la base de datos. Quite la línea en el paso anterior, el --authenticationDatabase se especifica la opción en la cadena URI.

Además, use --gzip si se usa al crear la copia de seguridad.

--drop :antes de restaurar las colecciones de la copia de seguridad volcada, elimina las colecciones de la base de datos de destino. No descarta colecciones que no están en la copia de seguridad.--noIndexRestore :evita que mongorestore restaure y cree índices como se especifica en la salida de mongodump correspondiente.

Si desea cambiar el nombre de la base de datos durante la restauración, puede hacerlo usando
--nsFrom="old_name.*" --nsTo="new_name.*" opciones.

Sin embargo, no funcionará si tuviera que migrar con oplogs que es un requisito en la migración desde una instancia en línea.

Migrar desde una base de datos en linea en MongoDB

El único desafío de migrar desde una base de datos en línea es no poder pausar las actualizaciones durante la migración. Así que aquí está la descripción general de los pasos,

  1. Ejecutar una migración masiva inicial con oplogs capturar
  2. Ejecute un trabajo de sincronización para mitigar la latencia del cambio de conexión de la base de datos

Ahora, para capturar oplogs , se debe inicializar un conjunto de réplicas en las bases de datos de origen y de destino. Esto se debe a que oplogs se capturan desde local.oplog.rs espacio de nombres, que se crea después de inicializar un conjunto de réplicas.

Puede seguir esta guía para configurar un conjunto de réplicas.

Migración inicial con Oplog Capture

Los Oplogs, en palabras simples, son los registros de operaciones creados por operación en la base de datos. Representan un estado de documento parcial o, en otras palabras, el estado de la base de datos. Así que vamos a capturar cualquier actualización en nuestra antigua base de datos durante el proceso de migración usando estos oplogs .

Ejecute el programa mongodump con las siguientes opciones,

mongodump --uri=".../?authSource=admin" \
  --forceTableScan --oplog \
  --gzip -v --out ./dump

--oplog :Crea un archivo llamado oplog.bson como parte del mongodump producción. El oplog.bson El archivo, ubicado en el nivel superior del directorio de salida, contiene oplog entradas que ocurren durante la operación mongodump. Este archivo proporciona una instantánea efectiva de un punto en el tiempo del estado de nuestra instancia de base de datos.

Restaurar los datos con oplog replay

Para reproducir los oplogs, se requiere un rol especial. Vamos a crear y asignar el rol al usuario de la base de datos que se usa para la migración.

Crear el rol

db.createRole({
  role: "interalUseOnlyOplogRestore",
  privileges: [
    {
      resource: { anyResource: true },
      actions: [ "anyAction" ] 
    }
  ],
  roles: []
})

Asignar el rol

db.grantRolesToUser(
  "admin",
  [{ role:"interalUseOnlyOplogRestore", db:"admin" }]
);

Ahora puede restaurar usando el programa mongorestore con las siguientes opciones,

mongorestore --uri="mongodb://admin:.../?authSource=admin" \
  --oplogReplay 
  --gzip -v ./dump

En el comando anterior, usando el mismo usuario admin con quien estaba asociado el rol.

--oplogReplay :después de restaurar el volcado de la base de datos, reproduce las entradas de oplog desde un archivo bson y restaura la base de datos a la copia de seguridad de un momento dado capturada con mongodump --oplog comando.

Mitigar la latencia del cambio de conexión de la base de datos

Muy bien, hasta ahora hemos terminado con la mayor parte del trabajo pesado. Lo único que queda es mantener la coherencia entre las bases de datos durante el cambio de conexión en nuestros servidores de aplicaciones.

Si está ejecutando MongoDB versión 3.6+, es mejor optar por el enfoque Change Stream, que es un mecanismo basado en eventos introducido para capturar cambios en su base de datos de manera optimizada. Aquí hay un artículo que lo cubre https://www.mongodb.com/blog/post/an-introduction-to-change-streams

Consulte el script de sincronización genérico, que puede ejecutar como un trabajo CRON cada minuto.

Actualice las variables en este script y ejecútelo como

$ ./delta-sync.sh from_epoch_in_milliseconds

# from_epoch_in_milliseconds is automatically picked with every iteration if not supplied

O puede configurar un trabajo cron para ejecutar esto cada minuto.

* * * * * ~/delta-sync.sh

La salida se puede monitorear con el siguiente comando (estoy ejecutando RHEL 8, consulte la guía de su sistema operativo para la salida cron)

$ tail -f /var/log/cron | grep CRON

Este es un registro de sincronización de muestra.

CMD (~/cron/dsync.sh)
CMDOUT (INFO: Updated log registry to use new timestamp on next run.)
CMDOUT (INFO: Created sync directory: /home/ec2-user/cron/dump/2020-11-03T19:01:01Z)
CMDOUT (Fetching oplog in range [2020-11-03T19:00:01Z - 2020-11-03T19:01:01Z])
CMDOUT (2020-11-03T19:01:02.319+0000#011dumping up to 1 collections in parallel)
CMDOUT (2020-11-03T19:01:02.334+0000#011writing local.oplog.rs to /home/ec2-user/cron/dump/2020-11-03T19:01:01Z/local/oplog.rs.bson.gz)
CMDOUT (2020-11-03T19:01:04.943+0000#011local.oplog.rs  0)
CMDOUT (2020-11-03T19:01:04.964+0000#011local.oplog.rs  0)
CMDOUT (2020-11-03T19:01:04.964+0000#011done dumping local.oplog.rs (0 documents))
CMDOUT (INFO: Dump success!)
CMDOUT (INFO: Replaying oplogs...)
CMDOUT (2020-11-03T19:01:05.030+0000#011using write concern: &{majority false 0})
CMDOUT (2020-11-03T19:01:05.054+0000#011will listen for SIGTERM, SIGINT, and SIGKILL)
CMDOUT (2020-11-03T19:01:05.055+0000#011connected to node type: standalone)
CMDOUT (2020-11-03T19:01:05.055+0000#011mongorestore target is a directory, not a file)
CMDOUT (2020-11-03T19:01:05.055+0000#011preparing collections to restore from)
CMDOUT (2020-11-03T19:01:05.055+0000#011found collection local.oplog.rs bson to restore to local.oplog.rs)
CMDOUT (2020-11-03T19:01:05.055+0000#011found collection metadata from local.oplog.rs to restore to local.oplog.rs)
CMDOUT (2020-11-03T19:01:05.055+0000#011restoring up to 4 collections in parallel)
CMDOUT (2020-11-03T19:01:05.055+0000#011replaying oplog)
CMDOUT (2020-11-03T19:01:05.055+0000#011applied 0 oplog entries)
CMDOUT (2020-11-03T19:01:05.055+0000#0110 document(s) restored successfully. 0 document(s) failed to restore.)
CMDOUT (INFO: Restore success!)

Puede detener este script después de verificar que no haya más oplogs se están creando, es decir, cuando la base de datos de origen se desconectó.

Esto concluye la guía completa de migración de datos MongoDB autohospedada. Si desea obtener más información sobre MongoDB, aquí hay un recurso útil sobre cómo usar MongoDB como fuente de datos en goLang.