Docs Menu
Docs Home

Mongomirror

Advertencia

Cuando usas mongomirror con un filtro de espacio de nombres, las transacciones en la fuente con espacios de nombres que están fuera del alcance de includeNamespace <database.collection> se consideran un comportamiento indefinido e incurren en una posible pérdida de datos.

mongomirror Es una herramienta para migrar manualmente datos de un conjunto de réplicas de MongoDB existente a un conjunto de réplicas de MongoDB Atlas. Consulte también Descargar mongomirror.

Para ejecutar mongomirror, debe especificar:

  • El conjunto de réplicas de origen y el conjunto de réplicas de Atlas de destino.

  • Un usuario en el clúster Atlas con los privilegios adecuados, la contraseña correspondiente y los privilegios adecuados, si el conjunto de réplicas de origen requiere autenticación.

mongomirror --host <sourceReplSet> \
--destination <atlasCluster> \
--destinationUsername <atlasAdminUser> \
--destinationPassword <atlasPassword> \
[Additional options]

Puedes especificar algunas opciones en el config file en lugar de incluirlas en el comando.

--host <host>

La información del host para el set de réplicas de origen. Especifique el nombre del set de réplicas y una lista de nodos iniciales de los miembros, como en el siguiente ejemplo:

<RSname>/<host1>:<port1>,<host2>:<port2>,<host3>:<port3>
--username <username>

Si el conjunto de réplicas de origen requiere autenticación, el nombre de un usuario del conjunto de réplicas de origen con privilegios para leer cualquier base de datos, incluida la local base de datos. Un usuario con el rol proporciona los privilegios adecuados. Para obtener más información sobre los privilegios específicos backup requeridos, consulte Acceso requerido en el conjunto de réplicas de origen.

--password <password>

Contraseña para el usuario especificado en --username.

--authenticationDatabase <authenticationDatabase>

La base de datos del conjunto de réplicas de origen donde --username se creó el usuario especificado en. La base de datos de autenticación para:

  • Los usuarios autenticados mediante SCRAM son la base de datos admin.

  • Los usuarios autenticados por X.509son la base de datos $external.

  • Los usuarios autenticados por AWS IAM son la base de datos $external.

Para obtener más información, consulte Base de datos de autenticación.

--authenticationMechanism <authenticationMechanism>

El mecanismo de autenticación que se utilizará para autenticar al usuario en el conjunto de réplicas de origen.

Valor
Descripción

RFC 5802 estándar del mecanismo de autenticación de respuesta a desafío salado utilizando la función de hash SHA-256.

Autenticación de certificados TLS/SSL de MongoDB.

GSSAPI (Kerberos)

Autenticación externa mediante Kerberos. Este mecanismo solo está disponible en MongoDB Enterprise.

PLAIN (SASL LDAP)

Autenticación externa mediante LDAP. También puedes utilizar PLAIN para autenticar a los usuarios de base de datos. PLAIN transmite contraseñas en texto plano. Este mecanismo solo está disponible en MongoDB Enterprise.

MONGODB-IAM

Novedades en la versión 0.10.0

Autenticación externa con AWS IAM.

Para autenticarse con las credenciales de AWS IAM, utilice las siguientes opciones:

  • --username < ID de clave de acceso de AWS>

  • --password <secret access key id>

  • --awsSessionToken <AWS session token>

Para obtener más información, consulte Mecanismos de autenticación.

--awsSessionToken

Novedades en la versión 0.10.0

Un token de sesión de AWS para utilizar con el mecanismo de autenticación MONGODB-IAM.

--compressors <snappy,...>

Novedades en la versión 0.9.0

Lista de compresores separados por comas para habilitar. Use "ninguno" para deshabilitar. Predeterminado: snappy,zstd,zlib

--config=<file>

ArchivoYAML que almacena opciones y valores mongomirror para. Especifique el archivo mediante rutas relativas o absolutas para ejecutar mongomirror con las opciones que contiene.

El archivo de configuración admite las siguientes opciones:

Especifique las opciones en el archivo de configuración con la sintaxis option: value. No incluya -- antes de las opciones en el archivo de configuración. Si define una opción en el archivo de configuración, no es necesario especificarla en el comando mongomirror.

Ejemplo

Cree un archivo de configuración llamado myconfig.yaml que contenga lo siguiente:

password: <passwordForUser>
destinationPassword: <passwordForDestinationUser>

Puede ejecutar mongomirror sin incluir los indicadores --password y --destinationPassword:

mongomirror --host <sourceReplSet> \
--ssl \
--username <atlasAdminUser> \
--destinationUsername <atlasAdminUser> \
--config=myconfig.yaml \
--destination <atlasCluster> \
[Additional options]
--destination <destination>

La información del host para el set de réplicas de Atlas de destino.

Especifique el nombre del conjunto de réplicas y una lista de semillas de los miembros, como se muestra a continuación:

<RSname>/<host1>:<port1>,<host2>:<port2>,<host3>:<port3>
--destinationAuthenticationDatabase <authentication database>

Base de datos de autenticación del usuario de la base de datos en el clúster Atlas. La base de datos de autenticación para usuarios autenticados mediante SCRAM es la admin base de datos.

Para obtener más información,consulte Autenticación de usuarios de la base de datos.

--destinationAuthenticationMechanism <authentication mechanism>

Mecanismo de autenticación para el usuario de la base de datos en el clúster Atlas. Atlas ofrece los siguientes métodos de autenticación para los usuarios de la base de datos:

Valor
Descripción

RFC 5802 estándar del mecanismo de autenticación de respuesta a desafío salado utilizando la función de hash SHA-1.

RFC 5802 estándar del mecanismo de autenticación de respuesta a desafío salado utilizando la función de hash SHA-256.

PLAIN (SASL LDAP)

Autenticación externa mediante LDAP. También puedes utilizar PLAIN para autenticar a los usuarios de base de datos. PLAIN transmite contraseñas en texto plano. Este mecanismo solo está disponible en MongoDB Enterprise.

Para obtener más información,consulte Autenticación de usuarios de la base de datos.

--destinationUsername <Atlas user name>

Nombre de un usuario de base de datos en el clúster de Atlas con privilegios de lectura, escritura y administración de cualquier base de datos. Un usuario con el rol de administrador de Atlas proporciona los privilegios adecuados. Para obtener más información sobre los privilegios específicos necesarios,consulte Acceso requerido en el clúster de destino.

--destinationPassword <password>

Contraseña del usuario de la base de datos especificada en --destinationUsername.

--drop

Marca que indica quemongomirrordebe eliminar todas las colecciones de usuarios (visibles en cada base de datos conlistCollections) en el clúster de destino. Esta opción no elimina colecciones internas como local.system* ni el registro de operaciones.

--noIndexRestore

Novedades en la versión 0.10.0

Omitir índices al migrar datos.

--includeNamespace <database.collection>

Especifique un espacio de nombres en el clúster de origen para reflejarlo en el clúster de destino. Puede proporcionarse varias veces.

Nota

Si una transacción abarca varios espacios de nombres, solo las operaciones de escritura aplicadas a los espacios de nombres especificados en --includeNamespace o --includeDB se aplican al clúster de destino.

--includeDB <database>

Especifique una base de datos en el clúster de origen para replicarla en el clúster de destino. Puede proporcionarse varias veces.

Nota

Si una transacción abarca varios espacios de nombres, solo las operaciones de escritura aplicadas a los espacios de nombres especificados en --includeNamespace o --includeDB se aplican al clúster de destino.

--ssl

Habilita conexiones cifradas TLS/SSL al conjunto de réplicas de origen.

--sslPEMKeyFile <file>

El archivo .pem si el conjunto de réplicas de origen requiere que los clientes presenten un certificado. Este archivo contiene el certificado TLS/SSL y la clave. Especifique el archivo usando rutas relativas o absolutas.

--sslPEMKeyPassword <value>

Contraseña para descifrar el archivo de clave de certificado especificado en --sslPEMKeyFile. Úsela si --sslPEMKeyFile está cifrado.

--sslCAFile <file>

El archivo .pem que contiene la cadena de certificados raíz de la autoridad de certificación (CA) para el conjunto de réplicas de origen. Especifique el archivo mediante rutas relativas o absolutas.

--sslCRLFile <filename>

El archivo .pem que contiene la lista de revocación de certificados del conjunto de réplicas de origen. Especifique el archivo mediante rutas relativas o absolutas.

--sslAllowInvalidHostnames

Obsoleto Usar tlsInsecure en su lugar.

Desactiva la validación de los certificados TLS/SSL presentados por el conjunto de réplicas de origen. Permite mongomirror que se conecte al conjunto de réplicas de origen si el nombre de host de los certificados no coincide con el especificado.

Importante

Esta opción omite toda validación de certificados, lo que puede resultar en la aceptación de certificados no válidos.

--sslAllowInvalidCertificates

Obsoleto Usar tlsInsecure en su lugar.

Omite las comprobaciones de validación de los certificados presentados por el conjunto de réplicas de origen. Al usar la configuración --allowInvalidCertificates, MongoDB registra como advertencia el uso del certificado no válido.

Importante

Esta opción omite toda validación de certificados, lo que puede resultar en la aceptación de certificados no válidos.

--tlsInsecure

Omite las comprobaciones de validación de la cadena de certificados y el nombre de host del servidor. Esto permite usar certificados y nombres de host no válidos.

Esto reemplaza las opciones obsoletas sslAllowInvalidHostnames y sslAllowInvalidCertificates.

--gssapiServiceName <name>

Si el conjunto de réplicas de origen utiliza autenticación Kerberos, el nombre del servicio que utiliza GSSAPI/Kerberos. Solo es necesario si el servicio no utiliza el nombre predeterminado mongodb.

Esta opción solo está disponible en MongoDB Enterprise.

--gssapiHostName <host>

Si el conjunto de réplicas de origen utiliza autenticación Kerberos, el nombre de host de un servicio que utiliza GSSAPI/Kerberos. Solo es necesario si el nombre de host de una máquina no coincide con el nombre de host resuelto por DNS.

Esta opción solo está disponible en MongoDB Enterprise.

--readPreference <read preference>

Obsoleto desde la versión 0.9.0

mongomirror siempre lee desde el host principal a menos que la fuente sea un solo host sin un nombre de conjunto de réplicas, en cuyo caso realiza una conexión directa solo a ese host.

--writeConcern <write concern>

Obsoleto desde la 0.2.3 versión: mongomirror siempre utiliza la preocupación de escritura mayoritaria.

--numParallelCollections <num>, -j <num>

Por defecto: 4

El número de colecciones a copiar y restaurar en paralelo.

--bypassDocumentValidation

Obsoleto desde la 0.2.3 versión: siempre omite la validación delmongomirror documento.

--bookmarkFile <file>

por defecto: mongomirror.bookmark

Nombre del archivo de marcadores de marca de tiempo del registro de operaciones.

--forceDump

Bandera que indica que resincroniza todas las colecciones de origen, incluso si existe un archivo de marcadores no mongomirror vacío.

--oplogPath <path>

Novedades en la versión 0.5.0

Permite a mongomirror almacenar en buffer la ventana de sincronización inicial de oplog en disco. Cuando se especifica un valor para esta opción, mongomirror transmite las entradas del registro oplog de origen al directorio especificado en un solo archivo: <oplogPath>/oplog-mongomirror.bson.sz. Después de que todo el archivo oplog se reproduzca en el clúster de destino, mongomirror remueve el archivo y comienza a monitorear el registro oplog de origen sin almacenamiento intermedio.

De forma predeterminada, transmite las entradas del registro de operaciones desde el origen y las aplica al clúster de destino. Sin embargo, la migraciónmongomirror puede fallar si el registro de operaciones de origen no es lo suficientemente grande como para contener toda la ventana inicial del registro de operaciones de sincronización. Para evitar este error, puede aumentar el tamaño del registro de operaciones de origen o especificar esta opción para garantizar que no se quede sin espacio durante el proceso de migración.

Importante

Debe haber suficiente espacio en disco para acomodar todas las entradas del registro de operaciones de origen que ocurren durante la sincronización mongomirror inicial.

Por ejemplo, si el registro de operaciones de origen es 10 GB y cubre 24 horas de cambios, y se estima que mongomirror la sincronización de demora 48 horas, debe haber al menos 20 GB de espacio libre en disco en el directorio especificado.

--oplogBatchSize <num>

10Predeterminado:,000

Especifique la cantidad de entradas de registro de operaciones que se enviarán como un lote. mongomirror permite un tamaño máximo de volumen de datos de 16 MB de documentos para enviar como un lote.

--httpStatusPort <num>

Dirige a mongomirror para iniciar un servidor HTTP en el puerto especificado. Puedes recuperar el estado actual de mongomirror si emites una solicitud HTTP GET a http://localhost:<num>.

Al ejecutarse --httpStatusPort con, no sale al detectar un error. En su lugar, registra el error con normalidad y lo informa por HTTP al puertomongomirror especificado.

mongomirror Devuelve un documento en respuesta a la solicitud HTTP. La siguiente sintaxis de ejemplo representa todos los campos de salida posibles; la respuesta real podría devolver solo un subconjunto de estos campos. Consulte la tabla siguiente para obtener una descripción de los campos y cuándo esperarlos.

{
"stage" : "<stage Name>",
"phase" : "<phase Name>",
"details" : {
"currentTimestamp" : "<BSON timestamp>",
"latestTimestamp" : "<BSON timestamp>",
"lastWriteOnSourceTimestamp" : "<BSON timestamp>",
"<namespace>" : {
"complete" : <boolean>,
"copiedBytes" : <integer>,
"totalBytes" : <integer>,
"createIndexes" : <integer>
},
...
},
"errorMessage" : "<error message>"
}

La siguiente tabla describe cada campo y sus posibles valores:

Campo
Descripción

stage

El nombre de la etapa en curso. Los valores posibles son:

  • initializing

    mongomirror Ha comenzado pero aún no está copiando ningún dato.

  • initial sync

    mongomirror está copiando documentos e índices que ya existen en la implementación de origen. también sigue y aplica entradas del registro demongomirror operaciones.

  • oplog sync

    mongomirror Está siguiendo y aplicando entradas del registro de operaciones.

phase

El nombre de la fase. Proporciona detalles más específicos sobre qué parte de stage está en curso.

details

Un documento que proporciona una descripción detallada del progreso de la fase actual.

Durante la initial sync etapa, cada subdocumento en details representa una única colección que está siendo copiada mongomirror por.

Dependiendo de stage phaseo, puede no incluir este campo en lamongomirror respuesta.

details.<namespace>

El espacio de nombres completo de la colección que se está copiando, mostrado como <database>.<collection>.

Solo se muestra durante la fase initial sync al copiar documentos o índices.

details.<namespace>.complete

Muestra true o false dependiendo de si mongomirror ha copiado o no todos los documentos o índices de la colección al clúster Atlas de destino.

Solo se muestra durante la fase initial sync al copiar documentos o índices.

details.<namespace>.copiedBytes

Número de bytes copiados hasta el momento. Tenga en cuenta que esta medida es diferente a la de los mongomirror registros, que indican el número actual/total de documentos copiados.

Solo se muestra durante la fase initial sync al copiar datos que no son de índice.

details.<namespace>.totalBytes

El tamaño total (en bytes) de la colección.

Solo se muestra durante la fase initial sync al copiar datos que no son de índice.

details.<namespace>.createIndexes

El número de índices que se han creado o se crearán.

Solo se muestra durante la etapa initial sync al copiar índices.

details.currentTimestamp

El valor de la marca de tiempo BSON de la entrada del registro de operaciones procesada más recientemente. solo actualiza este punto mongomirror de datos cada 10 segundos, por lo que mongomirror puede estar ligeramente más adelantado respecto del tiempo informado.

Solo se muestra durante las etapas initial sync o oplog sync al seguir o aplicar entradas del registro de operaciones.

details.latestTimestamp

Durante la etapa initial sync, esto representa el valor de marca de tiempo BSON de la última entrada del oplog disponible después de que los datos iniciales fueran copiados durante la sincronización inicial.

Durante la etapa oplog sync, esto representa el valor de la marca de tiempo BSON de la última entrada del registro de operaciones disponible en la implementación de origen.

Solo se muestra durante las etapas initial sync o oplog sync al seguir o aplicar entradas del registro de operaciones.

details
.lastWriteOnSourceTimestamp

El valor de la marca de tiempo BSON de la entrada más reciente del registro de operaciones que no es una operación no operativa. Las entradas no operativas suelen ser operaciones a nivel de sistema, como las operaciones de corazón, que no escriben ni editan datos en la base de datos. actualiza este valor mongomirror cada 10 segundos. Es posible que las operaciones que escriben o editan datos en la base de datos no se informen hasta la siguiente actualización.

El campo lastWriteOnSourceTimestamp es útil como confirmación de que no se están produciendo nuevas escrituras en la implementación de origen antes de realizar el corte durante una migración.

errorMessage

Una cadena que describe cualquier error encontrado mongomirror por.

--collStatsThreshold <num>

Novedades en la versión 0.9.0

Número máximo de colecciones que pueden existir antes de que se deshabilite collStats. Use -1 para ejecutar collStats siempre o 0 para no ejecutarlo nunca. Valor predeterminado: -1

--removeAutoIndexId

Novedades en la versión 0.12.0

Elimina la opción autoIndexId de las colecciones durante la sincronización inicial con el clúster de destino. También elimina la opción autoIndexId de cualquier colección que mongomirror cree durante la migración.

--preserveUUIDs

Permite que Atlas conserve el UUID durante la migración en vivo. Esta opción solo funciona con el proceso de migración en vivo que ejecuta Atlas. Si usa la --preserveUUIDs opción en la línea de comandos, fallará debido a errores de permisos. Estos errores son previsibles, ya que esta opción no está diseñada para usarse en la línea de comandos en un proceso de migración autogestionado que mongomirror ejecuta.

El siguiente ejemplo migra desde un conjunto de réplicas de origen que no requiere autenticación:

mongomirror --host sourceRS/source-host1:27017,source-host2:27017 \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017 \
--destinationUsername myAtlasUser \
--destinationPassword myAtlasPwd

Para migrar desde un conjunto de réplicas de origen que no requiere autenticación, ejecute mongomirror con las siguientes opciones:

Para el destino, especifica el nombre del set de réplicas seguido de una lista de nodos iniciales en el siguiente formato:

<replicaSetName>/<host1>:<port1>,<host2>:<port2>,<host3>:<port3>,...

El usuario especificado debe tener el rol en Atlas admin Atlas.

El siguiente ejemplo migra un conjunto de réplicas de origen que utiliza autenticación SCRAM-SHA1 a Atlas:

mongomirror --host sourceRS/source-host1:27017,source-host2:27017,source-host3:27017 \
--username mySourceUser \
--password mySourcePassword \
--authenticationDatabase admin \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017 \
--destinationUsername myAtlasUser \
--destinationPassword atlasPassw0Rd

Para migrar desde un conjunto de réplicas de origen que utiliza1 autenticación SCRAM-SHA, ejecute con las siguientes mongomirror opciones:

El usuario del conjunto de réplicas de origen debe tener el acceso requerido al clúster de origen. El rol backup proporciona los privilegios adecuados.

Para el destino, especifica el nombre del set de réplicas seguido de una lista de nodos iniciales en el siguiente formato:

<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,...

El usuario especificado debe tener en Atlas admin Atlas.

El siguiente ejemplo migra desde un conjunto de réplicas de origen que utiliza autenticación X.509:

mongomirror --host sourceRS/source-host1:27017,source-host2:27017,source-host3:27017 \
--username "CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry" \
--authenticationDatabase '$external' \
--authenticationMechanism MONGODB-X509 \
--ssl \
--sslPEMKeyFile <path-to-my-client-certificate.pem> \
--sslCAFile <path-to-my-certificate-authority-certificate.pem> \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017 \
--destinationUsername myAtlasUser \
--destinationPassword atlasPassw0Rd

Para migrar desde un conjunto de réplicas de origen que utiliza509 autenticación X., ejecute con las siguientes mongomirror opciones:

El usuario del conjunto de réplicas de origen debe tener el acceso requerido al clúster de origen. El rol backup proporciona los privilegios adecuados.

Para el destino, especifica el nombre del set de réplicas seguido de una lista de nodos iniciales en el siguiente formato:

<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,...

El usuario especificado debe tener en Atlas admin Atlas.

El siguiente ejemplo migra desde un conjunto de réplicas de origen que utiliza autenticación Kerberos:

mongomirror --host sourceRS/source-host1:27017,source-host2:27017,source-host3:27017 \
--username sourceUser/administrator@MYREALM.COM \
--authenticationDatabase '$external' \
--authenticationMechanism GSSAPI \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017,atlas-host3:27017 \
--destinationUsername atlasUser \
--destinationPassword atlasPass

Para migrar desde un conjunto de réplicas de origen que utiliza autenticación Kerberos, ejecute con las siguientes mongomirror opciones:

El usuario del conjunto de réplicas de origen debe tener el acceso requerido al clúster de origen. El rol backup proporciona los privilegios adecuados.

Para el destino, especifica el nombre del set de réplicas seguido de una lista de nodos iniciales en el siguiente formato:

<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,...

El usuario especificado debe tener en Atlas admin Atlas.

Puede guardar los registros de salida de un procedimiento mongomirror en un archivo para su posterior análisis y depuración. Utilice el siguiente formato para guardar la salida en un archivo mongomirror.log:

mongomirror <args> 2>&1 | tee -a mongomirror.log

En esta página