Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home

mongomirror

Advertencia

Cuando usas mongomirror con un filtro de namespaces, las transacciones en el origen con namespaces que estén fuera del alcance de includeNamespace <database.collection> se consideran un comportamiento indefinido y pueden incurrir en una posible pérdida de datos.

mongomirror es una herramienta para migrar manualmente datos desde un set de réplicas existente de MongoDB a un set de réplicas de MongoDB Atlas. Consulta también <a class=\" \" href=\" \">Descarga mongomirror.

Para ejecutar mongomirror, debe especificar:

  • El set de réplicas de origen y el set de réplicas de Atlas 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 set de réplicas de origen requiere autenticación, el nombre de un usuario en el set de réplicas de origen con privilegios para leer cualquier base de datos, incluida la base de datos local. Un usuario con el rol backup proporciona los privilegios adecuados. Para obtener detalles sobre los privilegios específicos requeridos, consulta Acceso requerido en el set 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 por SCRAM se encuentran en la base de datos admin.

  • Usuarios autenticados con X.509 es la base de datos $external.

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

Para obtener más información, consulta 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 mecanismo estándar de autenticación Salted Challenge Response que utiliza la función 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.

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

Nuevo 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 <AWS id de clave de acceso>

  • --password <secret access key id>

  • --awsSessionToken <AWS session token>

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

--awsSessionToken

Nuevo 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>

Archivo YAML que almacena opciones y valores para mongomirror. Especifica el archivo utilizando rutas relativas o absolutas para ejecutar mongomirror con las opciones que contiene el archivo.

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

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

password: <passwordForUser>
destinationPassword: <passwordForDestinationUser>

Puedes ejecutar mongomirror sin incluir las opciones --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 para el usuario de base de datos en el clúster Atlas. La base de datos de autenticación para usuarios autenticados mediante SCRAM es la base de datos admin.

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 base de datos en el clúster Atlas. Atlas ofrece las siguientes formas de autenticación para usuarios de bases 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 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

Nuevo en la versión 0.10.0

Omitir índices al migrar datos.

--includeNamespace <database.collection>

Especifique un namespace 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, solamente las operaciones de escritura aplicadas a los espacios de nombres especificados en --includeNamespace o --includeDB se aplican al clúster de destino.

--includeDB <database>

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

Nota

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

--ssl

Permite conexiones de red cifradas TLS/SSL al set de réplicas de origen.

--sslPEMKeyFile <file>

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

--sslPEMKeyPassword <value>

Contraseña para descifrar el archivo clave del certificado especificado en --sslPEMKeyFile. Utilizar si el --sslPEMKeyFile está cifrado.

--sslCAFile <file>

El archivo .pem que contiene la cadena de certificados raíz de la Autoridad Certificadora (CA) para el set de réplicas de origen. Especifica el archivo usando 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.

Deshabilita la validación de los certificados TLS/SSL presentados por el set de réplicas de origen. Permite que mongomirror se conecte al set de réplicas de origen si el nombre del host en los certificados no coincide con el nombre de host 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 set de réplicas de origen. Al utilizar el ajuste --allowInvalidCertificates, MongoDB registra como una 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 para la cadena de certificados y el nombre de host del servidor. Esto te permite usar certificados y nombres de host no válidos.

Esto reemplaza las opciones obsoletas sslAllowInvalidHostnames y sslAllowInvalidCertificates.

--gssapiServiceName <name>

Si el set de réplicas de origen utiliza autenticación Kerberos, se debe especificar el nombre del servicio usando GSSAPI/Kerberos. Solo es necesario si el servicio no utiliza el nombre por defecto de mongodb.

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

--gssapiHostName <host>

Si el set de réplicas de origen usa autenticación Kerberos, el nombre de host de un servicio que usa GSSAPI/Kerberos. Sólo 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>

En desuso desde la versión 0.9.0

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

--writeConcern <write concern>

Obsoleto desde la versión 0.2.3: mongomirror siempre usa nivel de confirmación de escritura de mayoría.

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

Por defecto: 4

El número de colecciones que se copiarán y restaurarán en paralelo.

--bypassDocumentValidation

Obsoleto desde la versión 0.2.3: mongomirror siempre omite la validación del 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 alojar todas las entradas de oplog que se produzcan durante la mongomirror sincronización inicial.

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

--oplogBatchSize <num>

por defecto: 10,000

Especifica el número de entradas de oplog que se enviarán como lote. mongomirror permite un tamaño máximo de volumen de datos de 16 MB de documentos para enviar como un agrupar.

--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. mongomirror también rastrea y aplica entradas del oplog.

  • oplog sync

    mongomirror está siguiendo y aplicando entradas del oplog.

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 etapa initial sync, cada subdocumento en details representa una sola colección que está siendo copiada por mongomirror.

Dependiendo de la stage o phase, mongomirror puede que no incluya este campo en la respuesta.

details.<namespace>

El namespace 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 todos los documentos o índices desde 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

El número de bytes copiados hasta ahora. Toma en cuenta que esta es una medición diferente de los mongomirror registros, que informan 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 muestran durante la etapa initial sync al copiar índices.

details.currentTimestamp

El valor BSON timestamp de la entrada del oplog procesada más recientemente. mongomirror solo actualiza este punto de datos cada 10 segundos, por lo que mongomirror puede estar ligeramente por delante del tiempo reportado.

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

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 marca de tiempo BSON de la última entrada de oplog disponible en la implementación de origen.

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

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 por mongomirror.

--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 al clúster de destino. También remueve 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 set de réplicas de origen que no requiere autenticación, ejecutar 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 de Atlas admin en Atlas.

El siguiente ejemplo migra un conjunto de réplicas fuente que utiliza la 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 set de réplicas de origen que utiliza autenticación SCRAM-SHA1, ejecutar mongomirror con las siguientes opciones:

El usuario del set de réplicas de origen debe tener el acceso requerido en el clúster de origen. El rol backup proporciona los privilegios apropiados.

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 el Atlas admin en Atlas.

El siguiente ejemplo migra desde un set 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 set de réplicas de origen que utiliza X.509 autenticación, ejecutar mongomirror con las siguientes opciones:

El usuario del set de réplicas de origen debe tener el acceso requerido en el clúster de origen. El rol backup proporciona los privilegios apropiados.

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 el Atlas admin en 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 set de réplicas de origen debe tener el acceso requerido en el clúster de origen. El rol backup proporciona los privilegios apropiados.

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 el Atlas admin en 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