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.
Sintaxis
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.
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 rolbackupproporciona los privilegios adecuados. Para obtener detalles sobre los privilegios específicos requeridos, consulta Acceso requerido en el set 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 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.
ValorDescripciónRFC 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
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
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.
--awsSessionTokenNuevo 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 ejecutarmongomirrorcon las opciones que contiene 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>
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
Crear un archivo de configuración llamado
myconfig.yamlque contenga lo siguiente:password: <passwordForUser> destinationPassword: <passwordForDestinationUser> Puedes ejecutar
mongomirrorsin incluir las opciones--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 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:
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 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 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
--includeNamespaceo--includeDBse 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
--includeNamespaceo--includeDBse aplican al clúster de destino.
--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--sslPEMKeyFileestá 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.
--sslAllowInvalidHostnamesObsoleto Usar
tlsInsecureen su lugar.Deshabilita la validación de los certificados TLS/SSL presentados por el set de réplicas de origen. Permite que
mongomirrorse 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.
--sslAllowInvalidCertificatesObsoleto Usar
tlsInsecureen 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.
--tlsInsecureOmite 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
sslAllowInvalidHostnamesysslAllowInvalidCertificates.
--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
mongomirrorsiempre 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:
mongomirrorsiempre 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.
--bypassDocumentValidationObsoleto desde la versión 0.2.3:
mongomirrorsiempre 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.
--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 alojar todas las entradas de oplog que se produzcan durante la
mongomirrorsincronización inicial.Por ejemplo, si el oplog de origen es de 10 GB y cubre 24 horas de cambios, y la sincronización de
mongomirrorse 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.
mongomirrorpermite un tamaño máximo de volumen de datos de 16 MB de documentos para enviar como un agrupar.
--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.mongomirrortambién rastrea y aplica entradas del oplog.oplog syncmongomirrorestá siguiendo y aplicando entradas del oplog.
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 etapa
initial sync, cada subdocumento endetailsrepresenta una sola colección que está siendo copiada pormongomirror.Dependiendo de la
stageophase,mongomirrorpuede 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 syncal copiar documentos o índices.details.<namespace>.completeMuestra
trueofalsedependiendo de simongomirrorha copiado todos los documentos o índices desde la colección al clúster Atlas de destino.Solo se muestra durante la fase
initial syncal copiar documentos o índices.details.<namespace>.copiedBytesEl número de bytes copiados hasta ahora. Toma en cuenta que esta es una medición diferente de los
mongomirrorregistros, que informan 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 muestran durante la etapa
initial syncal copiar índices.details.currentTimestampEl valor BSON timestamp de la entrada del oplog procesada más recientemente.
mongomirrorsolo actualiza este punto de datos cada 10 segundos, por lo quemongomirrorpuede estar ligeramente por delante del tiempo reportado.Solo se muestra durante las etapas
initial syncooplog syncal seguir o aplicar entradas de oplog.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 marca de tiempo BSON de la última entrada de oplog disponible en la implementación de origen.Solo se muestra durante las etapas
initial syncooplog syncal seguir o aplicar entradas de oplog.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 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
-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 al clúster de destino. También remueve 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
Migra un set 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 set de réplicas de origen que no requiere autenticación, ejecutar 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 de Atlas admin en Atlas.
Migrar un set de réplicas: el set de réplicas de origen utiliza la autenticación SCRAM-SHA1
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:
--host<sourceReplSet/seed list of members>--username<sourceUser>--password<sourcePassword>--authenticationDatabase<sourceDatabase>--destination<Atlas Cluster>--destinationUsername<atlasUser>--destinationPassword<atlasPassword>
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.
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 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:
--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 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.
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 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.
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