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.
Sintaxis
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.
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 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
localbase de datos. Un usuario con el rol proporciona los privilegios adecuados. Para obtener más información sobre los privilegios específicosbackuprequeridos, consulte Acceso requerido en el conjunto de réplicas de origen.
--authenticationDatabase <authenticationDatabase>La base de datos del conjunto de réplicas de origen donde
--usernamese 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.
ValorDescripciónSolicitud de comentarios 5802 Mecanismo de autenticación de respuesta de desafío salado estándar 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
PLAINpara autenticar a los usuarios de base de datos.PLAINtransmite 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.
--awsSessionTokenNovedades 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
mongomirrorpara. Especifique el archivo mediante rutas relativas o absolutas para ejecutarmongomirrorcon las opciones que contiene.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>
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 comandomongomirror.Ejemplo
Cree un archivo de configuración llamado
myconfig.yamlque contenga lo siguiente:password: <passwordForUser> destinationPassword: <passwordForDestinationUser> Puede ejecutar
mongomirrorsin incluir los indicadores--passwordy--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
adminbase 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:
ValorDescripciónRFC 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
PLAINpara autenticar a los usuarios de base de datos.PLAINtransmite 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.
--dropMarca que indica que
mongomirrordebe 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 comolocal.system*ni el registro de operaciones.
--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
--includeNamespaceo--includeDBse 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
--includeNamespaceo--includeDBse aplican al clúster de destino.
--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--sslPEMKeyFileestá 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.
--sslAllowInvalidHostnamesObsoleto Usar
tlsInsecureen su lugar.Desactiva la validación de los certificados TLS/SSL presentados por el conjunto de réplicas de origen. Permite
mongomirrorque 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.
--sslAllowInvalidCertificatesObsoleto Usar
tlsInsecureen 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.
--tlsInsecureOmite 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
sslAllowInvalidHostnamesysslAllowInvalidCertificates.
--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
mongomirrorsiempre 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:
mongomirrorsiempre 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.
--bypassDocumentValidationObsoleto desde la 0.2.3 versión: siempre omite la validación del
mongomirrordocumento.
--bookmarkFile <file>por defecto: mongomirror.bookmark
Nombre del archivo de marcadores de marca de tiempo del registro de operaciones.
--forceDumpBandera que indica que resincroniza todas las colecciones de origen, incluso si existe un archivo de marcadores no
mongomirrorvacío.
--oplogPath <path>Novedades en la versión 0.5.0
Permite a
mongomirroralmacenar en buffer la ventana de sincronización inicial de oplog en disco. Cuando se especifica un valor para esta opción,mongomirrortransmite 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,mongomirrorremueve 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ón
mongomirrorpuede 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
mongomirrorinicial.Por ejemplo, si el registro de operaciones de origen es 10 GB y cubre 24 horas de cambios, y se estima que
mongomirrorla 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.
mongomirrorpermite un tamaño máximo de volumen de datos de 16 MB de documentos para enviar como un lote.
--httpStatusPort <num>Dirige a
mongomirrorpara iniciar un servidor HTTP en el puerto especificado. Puedes recuperar el estado actual demongomirrorsi emites una solicitud HTTPGETahttp://localhost:<num>.Al ejecutarse
--httpStatusPortcon, no sale al detectar un error. En su lugar, registra el error con normalidad y lo informa por HTTP al puertomongomirrorespecificado.mongomirrorDevuelve 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:
CampoDescripciónstageEl nombre de la etapa en curso. Los valores posibles son:
initializingmongomirrorHa comenzado pero aún no está copiando ningún dato.initial syncmongomirrorestá copiando documentos e índices que ya existen en la implementación de origen. también sigue y aplica entradas del registro demongomirroroperaciones.oplog syncmongomirrorEstá siguiendo y aplicando entradas del registro de operaciones.
phaseEl nombre de la fase. Proporciona detalles más específicos sobre qué parte de
stageestá en curso.detailsUn documento que proporciona una descripción detallada del progreso de la fase actual.
Durante la
initial syncetapa, cada subdocumento endetailsrepresenta una única colección que está siendo copiadamongomirrorpor.Dependiendo de
stagephaseo, puede no incluir este campo en lamongomirrorrespuesta.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 syncal copiar documentos o índices.details.<namespace>.completeMuestra
trueofalsedependiendo de simongomirrorha 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 syncal copiar documentos o índices.details.<namespace>.copiedBytesNúmero de bytes copiados hasta el momento. Tenga en cuenta que esta medida es diferente a la de los
mongomirrorregistros, que indican el número actual/total de documentos copiados.Solo se muestra durante la fase
initial syncal copiar datos que no son de índice.details.<namespace>.totalBytesEl tamaño total (en bytes) de la colección.
Solo se muestra durante la fase
initial syncal copiar datos que no son de índice.details.<namespace>.createIndexesEl número de índices que se han creado o se crearán.
Solo se muestra durante la etapa
initial syncal copiar índices.details.currentTimestampEl valor de la marca de tiempo BSON de la entrada del registro de operaciones procesada más recientemente. solo actualiza este punto
mongomirrorde datos cada 10 segundos, por lo quemongomirrorpuede estar ligeramente más adelantado respecto del tiempo informado.Solo se muestra durante las etapas
initial syncooplog syncal seguir o aplicar entradas del registro de operaciones.details.latestTimestampDurante 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 syncooplog syncal seguir o aplicar entradas del registro de operaciones.details.lastWriteOnSourceTimestampEl 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
mongomirrorcada 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
lastWriteOnSourceTimestampes ú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.errorMessageUna cadena que describe cualquier error encontrado
mongomirrorpor.
--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
-1para ejecutar collStats siempre o0para no ejecutarlo nunca. Valor predeterminado:-1
--removeAutoIndexIdNovedades en la versión 0.12.0
Elimina la opción
autoIndexIdde las colecciones durante la sincronización inicial con el clúster de destino. También elimina la opciónautoIndexIdde cualquier colección quemongomirrorcree durante la migración.
--preserveUUIDsPermite 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
--preserveUUIDsopció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 quemongomirrorejecuta.
Ejemplos
Migrar un conjunto de réplicas a Atlas: sin autenticación en el origen
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:
--host<sourceReplSet/seed list of members>--destination<Atlas Cluster>--destinationUsername<atlasUser>--destinationPassword<atlasPassword>
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.
Migrar un conjunto de réplicas: el conjunto de réplicas de origen utiliza la autenticación SCRAM-SHA1
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:
--host<sourceReplSet/seed list of members>--username<sourceUser>--password<sourcePassword>--authenticationDatabase<sourceDatabase>--destination<Atlas Cluster>--destinationUsername<atlasUser>--destinationPassword<atlasPassword>
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.
Migra un set de réplicas: el set de réplicas de origen requiere autenticación de cliente X.509
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:
--host<sourceReplSet/seed list of members>--username<subject from the client certificate>--authenticationMechanismMONGODB-X509--authenticationDatabase'$external'--sslPEMKeyFile<path-to-my-client-certificate.pem>--sslCAFile<path to root CA PEM file>--destination<Atlas Cluster>--destinationUsername<atlasUser>--destinationPassword<atlasPassword>
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.
Migrar un conjunto de réplicas: el conjunto de réplicas de origen requiere autenticación Kerberos/GSSAPI
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:
--host<sourceReplSet/seed list of members>--username<Kerberos user principal>--authenticationDatabase'$external'--authenticationMechanismGSSAPI--destination<Atlas Cluster>--destinationUsername<atlasUser>--destinationPassword<atlasPassword>
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.
Guardar la mongomirror salida en un archivo
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