mongomirror

Sintaxis

Para ejecutar mongomirror, debe especificar:

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

• Un usuario del clúster Atlas con los privilegios adecuados, la contraseña correspondiente y los privilegios adecuados, si el set 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.

opciones

--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 en el set de réplicas de origen donde se creó el usuario especificado en --username. 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 de 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 set de réplicas de origen.

Valor	Descripción
SCRAM-SHA-1	RFC 5802 estándar del mecanismo de autenticación de respuesta a desafío salado utilizando la función de hash SHA-1.
SCRAM-SHA-256	RFC 5802 estándar del mecanismo de autenticación de respuesta a desafío salado utilizando la función de hash SHA-256.
MONGODB-X509	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, se deben utilizar las siguientes opciones: --username <AWS access key id> --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,...>

Nuevo en la versión 0.9.0

Lista de compresores separados por comas que permitir. Utilizar 'none' para dejar de permitir. Por defecto: snappy,zstd,zlib

--config=<file>

Archivo YAML que almacena las opciones y valores de mongomirror. Especificar el archivo usando rutas relativas o absolutas para ejecutar mongomirror con las opciones incluidas en el archivo.

El archivo de configuración admite las siguientes opciones:

• password <password>

• sslPEMKeyPassword <password>

• destinationPassword <password>

• uri <cadena de conexión URI del clúster de origen>

Especificar las opciones en el archivo de configuración utilizando la sintaxis option: value. No incluir -- antes de las opciones en el archivo de configuración. Si se establece una opción en el archivo de configuración, no es necesario especificar esa opción 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.

Especificar el nombre del set de réplicas y una lista de nodos iniciales de los nodos, 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 aprender más, se puede consultar Autenticación de usuarios de 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
SCRAM-SHA-1	RFC 5802 estándar del mecanismo de autenticación de respuesta a desafío salado utilizando la función de hash SHA-1.
SCRAM-SHA-256	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 aprender más, se puede consultar Autenticación de usuarios de base de datos.

--destinationUsername <Atlas user name>

Nombre de un usuario de base de datos en el clúster Atlas con privilegios para leer, guardar y administrar cualquier base de datos. Un usuario con el rol de administrador de Atlas proporciona los privilegios adecuados. Para obtener detalles sobre los privilegios específicos requeridos, consulte Acceso requerido en el clúster de destino.

--destinationPassword <password>

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

--drop

Bandera que indica que mongomirror debe descartar todas las colecciones de usuario (que se pueden ver en cada base de datos con listCollections) en el clúster de destino. Esta opción no descarta colecciones internas como local.system* y el oplog.

--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 para el set de réplicas de origen. Especificar el archivo usando 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 conectarse al set de réplicas de origen si el nombre de 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 sustituye a 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>

En desuso desde la versión 0.2.3. : mongomirror siempre utiliza el nivel de confirmación de escritura (write concern) 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

En desuso desde la versión 0.2.3. : mongomirror always bypasses document validación.

--bookmarkFile <file>

por defecto: mongomirror.bookmark

Nombre del archivo de marcador de tiempo del oplog.

--forceDump

Indicador que indica que mongomirror resincronice todas las colecciones fuente, incluso si existe un archivo de marcadores no vacío.

--oplogPath <path>

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

Por defecto, mongomirror transmite registros de oplog desde el origen y los aplica al clúster de destino. Sin embargo, la migración puede fallar si el oplog de origen no es lo suficientemente grande como para contener toda la ventana del oplog de sincronización inicial. Para evitar este error, puedes aumentar el tamaño del oplog de origen, o especificar esta opción para asegurarte de que el oplog de origen 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 un lote. se permite un volumen máximo de datos de hasta 16 MB de documentos que se pueden enviar en 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>.

Cuando se ejecuta con --httpStatusPort, mongomirror no se detiene si encuentra un error. En cambio, registra el error como de costumbre e informa del error a través de HTTP en el puerto especificado.

mongomirror devuelve un documento en respuesta a la solicitud HTTP. La siguiente sintaxis de ejemplo representa todos los posibles campos de salida; la respuesta real puede devolver solo un subconjunto de estos campos. Consulte la siguiente tabla para obtener una descripción de los campos y saber cuándo esperar que aparezcan.

{
   "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 fase en progreso. 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. Sólo 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. Sólo 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 en el registro de operaciones (oplog) que no es una operación nula. Las entradas no-op son generalmente operaciones a nivel de sistema, como los latidos del corazón, que no guardan ni editan datos en la base de datos. mongomirror actualiza este valor cada 10 segundos. Las operaciones que guardan o editan datos en la base de datos pueden no ser reportadas hasta que se produzca la siguiente actualización. El campo lastWriteOnSourceTimestamp es útil como confirmación de que no se están realizando nuevas escrituras en la implementación de origen antes de la transición durante una migración.
errorMessage	Una cadena que describe cualquier error encontrado por mongomirror.

--collStatsThreshold <num>

Nuevo en la versión 0.9.0

Número máximo de colecciones que pueden existir antes de que collStats se deshabilite. Utiliza -1 para ejecutar siempre collStats, o 0 para no ejecutar collStats nunca. Valor por defecto: -1

--removeAutoIndexId

Nuevo 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 a Atlas preservar el UUID durante la migración en vivo. Esta opción funciona solo con el proceso de migración en vivo que ejecuta Atlas. Si utilizas la opción --preserveUUIDs en la línea de comandos, fallará debido a errores de permisos. Se esperan estos errores porque esta opción no está diseñada para usarse en la línea de comandos en un proceso de migración autogestionado que se ejecuta mongomirror.

Ejemplos

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

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

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

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

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

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

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

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

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