El binario mongosync es el proceso principal utilizado en Mongosync. mongosync migra datos de un clúster a otro.
Para una descripción general del proceso mongosync, consulta Acerca de mongosync.
Para comenzar a usar mongosync, consulta la Guía de inicio rápido.
Para obtener información más detallada, consulte la página de Instalación o Conexión mongosync que mejor se ajuste a su situación.
Aviso de Exención de Verificador Integrado
A partir de 1.9, mongosync incluye un verificador incrustado para realizar una serie de verificaciones en todas las colecciones compatibles en el clúster de destino para confirmar que la transferencia de documentos del clúster de origen al destino se realizó con éxito.
Al iniciar el proceso mongosync, proporciona el siguiente descargo de responsabilidad:
Embedded verification is enabled by default. Verification checks for data consistency between the source and destination clusters. Verification will cause mongosync to fail if any inconsistencies are detected, but it does not check for all possible data inconsistencies. Please see the documentation at https://www.mongodb.com/es/docs/cluster-to-cluster-sync/current/reference/verification/embedded for more details. Verification requires approximately 0.5 GB of memory per 1 million documents on the source cluster and will fail if insufficient memory is available. Accepting this disclaimer indicates that you understand the limitations and memory requirements for this tool. To skip this disclaimer prompt, use –-acceptDisclaimer. To disable the embedded verifier, specify 'verification: false' when starting mongosync. Please see https://www.mongodb.com/es/docs/cluster-to-cluster-sync/current/reference/verification/ for alternative verification methods. Do you want to continue? (y/n):
Si ya has leído y aceptado la advertencia, puedes iniciar mongosync con la opción --acceptDisclaimer para omitir esta notificación.
Configuraciones
Independencia del clúster
mongosync sincroniza los datos de la colección entre un clúster de origen y un clúster de destino. mongosync no se sincroniza users or rol. Como resultado, puedes crear usuarios con diferentes permisos de acceso en cada clúster.
archivo de configuración
Se pueden configurar opciones para mongosync en un archivo de configuración YAML. Utilice la opción --config. Por ejemplo:
mongosync --config /etc/mongosync.conf
Para obtener información sobre las configuraciones disponibles, consulte Configuración.
Tipos de Clúster y Colección
Clústeres fragmentados
Mongosync admite la replicación entre clústeres particionados. mongosync replica particiones individuales en paralelo desde el clúster de origen al clúster de destino. Sin embargo, mongosync no preserva la configuración de particionado del clúster de origen.
Importante
Siempre debes desactivar el balanceador en un clúster de destino particionado usando balancerStop. Después de detener el balanceador, espere quince minutos antes de iniciar mongosync. Esto le da al clúster tiempo para finalizar cualquier migración de fragmentos en curso.
Si el clúster de origen o de destino es un clúster particionado y no está ejecutando mongosync con filtro de namespace, debe desactivar el balanceador del clúster de origen ejecutando el comando balancerStop y esperar 15 minutos hasta que finalice el comando.
Si el clúster origen o destino es un clúster y ejecutas mongosync con el filtrado de namespaces, puedes habilitar globalmente el balanceador del clúster de origen pero debes deshabilitarlo para todas las colecciones dentro del filtro de namespaces. Consulta Cómo deshabilitar el equilibrador para colecciones en sincronización filtrada También puedes desactivar completamente el equilibrador del clúster de origen.
Durante la migración, no ejecutes los comandos moveChunk o moveRange. Si ha habilitado el balanceador del clúster de origen, pero lo ha deshabilitado para las colecciones dentro del filtro de espacio de nombres, no ejecute shardCollection en las colecciones dentro del filtro de espacio de nombres. Si ejecutas shardCollection en colecciones dentro del filtro de espacio de nombres durante la migración, mongosync devolverá un error y se detendrá, lo que requerirá que inicies la migración desde cero.
Desactivación automática del balanceador
A partir de la versión 1.17, mongosync desactiva el balanceador en los clústeres de origen y destino durante la inicialización si detecta que los balanceadores no están desactivados.
Esto solo se aplica durante la inicialización. Si mongosync detecta que cualquiera de los balanceadores está habilitado después de que comience la migración, mongosync fallará.
Después de desactivar el balanceador, mongosync espera 15 minutos para asegurarse de que las migraciones de fragmentos en curso se completen antes de continuar con la migración.
Si la migración no es reversible y mongosync deshabilita el balanceador de origen o de destino durante la inicialización, después de un commit exitoso, mongosync volverá a habilitar el/los balanceador(es) que deshabilitó. Si la migración es reversible, mongosync no vuelve a habilitar ningún balanceador para evitar que los usuarios tengan que esperar 15 minutos.
IMPORTANTE: Si mongosync desactiva el balanceador para cualquiera de los clústeres y luego falla antes de confirmarse, debe volver a habilitar el/los balanceador(es) manualmente utilizando el comando de base de datos balancerStart si no tiene previsto ejecutar mongosync nuevamente.
Deshabilitar el equilibrador para colecciones en la sincronización filtrada
Si estás utilizando un filtro de namespace y deseas habilitar el balanceador en tus clústeres de origen para colecciones fuera del filtro de namespace, sigue estas instrucciones antes de comenzar mongosync.
Activa el balanceador para el clúster de origen.
Antes de iniciar mongosync con un filtro de namespace, activa el equilibrador para el clúster de origen ejecutando el método sh.startBalancer() en mongosh.
Deshabilite el balanceador para cada colección.
Deshabilite el balanceador para cada colección dentro del filtro de espacio de nombres ejecutando el comando setAllowMigrations:
db.adminCommand( { setAllowMigrations: “<db>.<collection>”, allowMigrations: false } )
Ejecute el comando anterior para cada colección dentro del filtro del namespace.
Importante
Si habilitas el equilibrador del clúster de origen pero no usas un filtro de namespace, o si no deshabilitas el equilibrador para todas las colecciones dentro del filtro de namespace, mongosync falla.
Fragmentos precortados
Cuando mongosync se sincroniza con un clúster de destino particionado, predivide los fragmentos para las colecciones particionadas en el clúster de destino. Para cada colección particionada, mongosync intenta crear 90 fragmentos.
Distribución de fragmentos
Importante
Incluso si el clúster de origen está equilibrado, mongosync no garantiza el equilibrio del clúster de destino. Porque mongosync no permite la ejecución de operaciones de partición durante la migración, debes esperar hasta que sea seguro aceptar escrituras para reequilibrar el clúster de destino. Consulta Balanceador del clúster fragmentado para conocer la orientación sobre cómo reequilibrar el clúster y limitaciones del clúster fragmentado para obtener información sobre las limitaciones del clúster fragmentado en mongosync.
mongosync no conserva la distribución de fragmentos desde el origen hasta el destino, incluso con múltiples instancias de mongosync. No es posible reproducir una pre-división particular de fragmentos de un clúster de origen en el clúster de destino.
La única configuración de particionado que mongosync conserva del clúster de origen al clúster de destino es la clave de particionado. Una vez que termine la migración, puedes habilitar el balanceador del clúster de destino, que distribuye los documentos independientemente de la distribución del clúster de origen.
partición primaria
Cuando sincronices con un clúster de destino particionado, mongosync asignará una partición primaria a cada base de datos mediante un reenvío circular.
Advertencia
La ejecución de movePrimary en el clúster de origen o destino durante la migración puede resultar en un error fatal o requerir que reinicie la migración desde el principio. Para obtener más información, consulte Clústeres fragmentados.
Configurar el clúster de particiones
A partir de 8.0, MongoDB introduce soporte para clústeres de particiones de configuración, también conocidos como clústeres de servidores de configuración integrados.
mongosync admite la sincronización desde clústeres fragmentados de servidores de configuración dedicados a clústeres fragmentados de servidores de configuración integrados y viceversa. Además, mongosync admite la sincronización de sets de réplicas a clústeres particionados de configuración, pero no viceversa.
Para obtener más información sobre los servidores de configuración embebidos, consulta Partición de configuración.
Múltiples clústeres
Para sincronizar un clúster de origen con varios clústeres de destino, use una instancia de mongosync para cada clúster de destino Para más información, consulte Limitaciones de Múltiples Clústeres.
Colecciones con tamaño fijo
A partir de 1.3.0, Mongosync admite colecciones con tamaño fijo con algunas limitaciones.
convertToCappedno es compatible. Si ejecutasconvertToCapped,mongosyncsale con un error.cloneCollectionAsCappedno está soportado.
Las colecciones con tamaño fijo en el clúster de origen funcionan con normalidad durante la sincronización.
Las colecciones con tamaño fijo en el clúster de destino tienen cambios temporales durante la sincronización:
No hay un número máximo de documentos.
El tamaño máximo de colección es 1PB.
mongosync restaura los valores originales para el número máximo de documentos y el tamaño máximo de documento durante el commit.
Lecturas y guardados
Bloqueo de escritura
Por defecto, mongosync habilita el bloqueo de escritura solo en el destino en el clúster de destino. mongosync desbloquea los guardados justo antes de que el endpoint /progress informe que canWrite está true. Puedes habilitar explícitamente el bloqueo de escritura solo de destino usando el endpoint /start para establecer enableUserWriteBlocking en "destinationOnly".
Puedes habilitar el doble bloqueo de guardado. Si habilitas el doble bloqueo de escritura, mongosync bloquea los guardados:
En el clúster de destino durante la migración.
mongosyncdesbloquea los guardados justo antes de establecercanWriteentrueEn el clúster de origen después de haber llamar a
/commit
Para habilitar el bloqueo dual de escritura, use /start para establecer enableUserWriteBlocking en "sourceAndDestination".
Puede utilizar /start para configurar enableUserWriteBlocking en "none".
No puedes activar el bloqueo dual de guardado o desactivar el bloqueo de guardado después de iniciar la sincronización.
Si desea utilizar la sincronización inversa más adelante, debe habilitar el bloqueo dual de escritura al iniciar mongosync.
Permisos de usuario
Para establecer enableUserWriteBlocking, el usuario mongosync debe tener un rol que incluya los setUserWriteBlockMode y bypassWriteBlockingMode ActionTypes.
Nota
Cuando utilices enableUserWriteBlocking, solo se bloquearán los guardados para los usuarios que no tengan el tipo de acción bypassWriteBlockingMode. Los usuarios que tengan este ActionType podrán realizar guardados.
Lecturas permitidas
Las operaciones de lectura en el clúster de origen siempre están permitidas.
Cuando el endpoint /progress indica que canWrite es true, los datos en los clústeres de origen y destino son coherentes.
Guardados permitidos
Para ver en qué estado se encuentra mongosync, llama al endpoint /progress de la API. La salida /progress incluye un valor booleano, canWrite.
Cuando
canWriteestrue, es seguro guardar en el clúster de destino.Cuando
canWriteseafalse, no guarde en el clúster de destino.
Puedes guardar de forma segura en el clúster de origen mientras mongosync se está sincronizando. No guardes en el clúster de destino a menos que canWrite esté true.
Preocupación por leer y nivel de confirmación de escritura (write concern)
Por defecto, mongosync establece el nivel de consistencia de lectura en "majority" para las lecturas en el clúster de origen. Para escrituras en el clúster de destino, mongosync establece el nivel de confirmación de escritura (write concern) en "majority" con j: true.
Para obtener más información sobre la configuración y el comportamiento de nivel de consistencia de lectura y nivel de confirmación de escritura (write concern), consulta Nivel de consistencia de lectura y nivel de confirmación de escritura (write concern).
preferencia de lectura
mongosync requiere la preferencia de lectura primary al conectar con los clústeres de origen y destino. Para más información, consulta Opciones de preferencia de lectura.
Gestión del índice heredado
mongosync reescribe los valores heredados del índice, como 0 o una string vacía, a 1 en el destino. mongosync también remueve cualquier opción de índice no válida en el destino.
Consideraciones de sincronización intermedia
mongosync la replicación es diferente de la replicación de datos dentro de un set de réplicas. mongosync combina y reordena guardados del clúster de origen al de destino durante la sincronización, y también modifica temporalmente varias características de la colección.
Como resultado, no se garantiza que el destino coincida con el clúster de origen en ningún punto mientras la sincronización siga ejecutándose, incluso cuando la sincronización esté en pausa. Para asegurarse de que los clústeres de destino y origen coincidan antes de hacer el corte, llame al endpoint commit.
La relación entre el clúster de origen y el de destino termina al confirmar, a menos que utilices la funcionalidad de reversión. Para obtener información sobre las limitaciones a mitad de la sincronización, consulta Limitaciones para más detalles.
Importante
Hasta que se haya llamado a commit en mongosync y canWrite devuelva true correctamente, las colecciones migradas en el clúster de destino no se pueden usar para aceptar tráfico de lectura o guardado de aplicaciones. No se debe utilizar mongosync para mantener clústeres secundarios para recuperación ante desastres, análisis u otros casos de uso similares.
Cambios temporales en las características de la colección
mongosync modifica temporalmente las siguientes características de la colección durante la sincronización. Los valores originales se restauran durante el proceso de confirmación.
Cambiar | Descripción |
|---|---|
Unique Indexes | Los índices únicos en el clúster de origen se sincronizan como índices no únicos en el clúster de destino. |
TTL Indexes | La sincronización establece |
Hidden Indexes | La sincronización replica los índices ocultos como no ocultos. |
Bloqueo de escritura | Si se habilita el bloqueo dual de guardar,
Para obtener más información, consulte Bloqueo de Escritura. |
Colecciones con tamaño fijo | La sincronización establece las colecciones limitadas al tamaño máximo permitido. |
Índices Dummy | En algunos casos, la sincronización puede crear índices ficticios en el destino para admitir escrituras en colecciones fragmentadas o agrupadas. |
Creaciones de índices continuas
mongosync no admite creación de índices continuos durante la migración. Para evitar crear índices de manera progresiva durante la migración, utiliza uno de los siguientes métodos para asegurarte de que tus índices de destino coincidan con tus índices de origen:
Construya el índice en la fuente antes de la migración.
Construye el índice en el origen durante la migración con una creación de índices por defecto.
Construye el índice en el destino después de la migración.
mongosync Metadata
mongosync almacena su metadatos en una base de datos o en varias bases de datos durante la migración. Las bases de datos de metadatos pueden llamarse de cualquiera de las siguientes maneras:
mongosync_reserved_for_internal_useCualquier cosa que comience con
mongosync_internal_Cualquier cosa que comience con
mongosync_reserved_for_verification_
Debes descartar todas las bases de datos de metadatos después de una migración exitosa. Después de eliminar los metadatos, no es posible revertir la migración.
Clústeres de destino
coherencia
mongosync permite consistencia eventual en el clúster de destino. La coherencia de lectura no está garantizada en el clúster de destino hasta la confirmación. Antes de confirmar, las fuentes y clústeres de destino pueden diferir en un punto dado en el tiempo. Para obtener más información, consulta Consideraciones de sincronización intermedia.
Mientras mongosync se está sincronizando, mongosync puede reordenar o combinar escrituras mientras las transmite de la fuente al destino. Para un documento determinado, el número total de guardados puede diferir entre el origen y el destino.
Las transacciones podrían no aparecer atómicamente en el clúster de destino. Las escrituras reintentables pueden no ser reintentables en el clúster de destino.
Perfilación
Si el análisis de rendimiento está activado en una base de datos de origen, MongoDB crea una colección especial llamada <db>.system.profile. Una vez que la sincronización esté completa, Mongosync no descartará la colección <db>.system.profile del destino, incluso si la base de datos de origen se descarta en un momento posterior. La colección <db>.system.profile no cambiará la precisión de los datos de usuario en el destino.
Vistas
Si se descarta una base de datos con vistas en el origen, el destino puede mostrar una colección system.views vacía en esa base de datos. La colección vacía system.views no cambiará la precisión de los datos de usuario en el destino.
Colecciones del sistema
Mongosync no replica las colecciones de sistema en el clúster de destino.
Si emite un comando dropDatabase en el clúster de origen, este cambio no se aplica directamente en el clúster de destino. En su lugar, Mongosync descarta las colecciones y vistas de usuario en la base de datos en el clúster de destino, pero no descarta las colecciones del sistema en esa base de datos.
Por ejemplo, en el clúster de destino:
La operación de descarte no afecta a una. colección creada por el usuario
system.jsSi habilitas la creación de perfiles, la colección
system.profilepermanece.Si creas vistas en el clúster de origen y luego descartas la base de datos, replicar el descarte remueve las vistas, pero deja una colección
system.viewsvacía.
En estos casos, la replicación de dropDatabase elimina todas las colecciones creadas por el usuario de la base de datos, pero deja las colecciones del sistema en el clúster de destino.
UUIDs
mongosync crea colecciones con elementos nuevos UUID en el clúster de destino. No existe relación entre los UUID del clúster de origen y los del clúster de destino. Si las aplicaciones contienen UUID codificados de forma rígida (algo que MongoDB no recomienda), puede que sea necesario actualizarlas antes de que funcionen correctamente con el clúster migrado.
Clasificación
mongosync inserta documentos en el clúster de destino en un orden indefinido que no conserva el orden natural de clasificación del clúster de origen. Si las aplicaciones dependen del orden de los documentos pero no tienen un método de ordenamiento definido, es posible que debas actualizar esas aplicaciones para especificar el orden de clasificación esperado antes de que las aplicaciones funcionen correctamente con el clúster migrado.
MongoDB Atlas Bases de datos internas
mongosync 1.17 y versiones anteriores devuelven un error si el clúster de destino contiene una __mdb_internal_atlas base de datos que no está vacía. Esta es una interna base de datos utilizada por MongoDB Atlas. Es posible que recibas un error que indique "found existing data on
the destination cluster; the destination cluster must be empty; please drop
existing data on the destination and start the migration again".
Para evitar migraciones fallidas, actualice a mongosync 1.18 o posterior, que ignora automáticamente todas las bases de datos internas.
Rendimiento
Resiliencia
mongosync es resiliente y puede gestionar errores no fatales. Los registros que contienen la palabra "error" o "fallo" no indican que mongosync esté fallando o corrompiendo datos. Por ejemplo, si ocurre un error de red, el registro mongosync puede contener la palabra "error", pero mongosync todavía es capaz de completar la sincronización. En el caso de que no se complete una sincronización, mongosync escribe una entrada de registro fatal.
Operaciones de Lenguaje de Definición de Datos (DDL)
El uso de operaciones DDL (operaciones que actúan sobre colecciones o bases de datos como db.createCollection() y db.dropDatabase()) durante la sincronización incrementa el riesgo de fallo de migración y puede impactar negativamente el rendimiento de mongosync. Para obtener el mejor rendimiento, abstente de realizar operaciones DDL en el clúster de origen mientras la sincronización está en curso.
Para obtener más información sobre operaciones DDL, consulta Operaciones DDL y transacciones pendientes.
Latencia de la red
La latencia de red o largas distancias físicas entre los componentes de migración pueden afectar negativamente la velocidad de sincronización.
- Latencia entre
mongosyncy las particiones de destino - Para cada operación en el clúster de origen,
mongosyncrealiza dos viajes de ida y vuelta al servidor de destino. Cuanto mayor sea la latencia, más lenta será la sincronización. - Latencia entre particiones de destino
mongosyncejecuta operaciones y actualiza sus propios metadatos en lotes dentro de una transacción en el clúster de destino. Esto puede dar lugar a transacciones entre particiones, lo que podría ser más costoso si las particiones están muy separadas.- Latencia entre los nodos de cualquier set de réplicas en el clúster de origen o destino
mongosyncutiliza"majority"escritos y"majority"lecturas, que requieren el reconocimiento de múltiples nodos en un set de réplicas, incluyendo los sets de réplicas que respaldan particiones. Si la mayoría de estos nodos no está en la misma región, habrá implicaciones negativas en el rendimiento.
Interrupciones durante la sincronización
Las siguientes consideraciones se refieren a las interrupciones durante el proceso mongosync.
Errores y cierres inesperados
Si mongosync encuentra un error o se vuelve inaccesible durante la sincronización, o puedes reanudar tu operación mongosync desde donde se detuvo. El binario mongosync es sin estado y almacena los metadatos para un reinicio en el clúster de destino.
Para continuar con la sincronización, reinicia mongosync una vez que esté disponible nuevamente y utiliza los mismos parámetros que tu sincronización interrumpida. Una vez que reinicies mongosync, el proceso se reanuda desde donde se detuvo.
Disponibilidad del clúster
Si su clúster de origen o destino se bloquea inesperadamente, puede reiniciar mongosync de forma segura desde donde se detuvo. Una vez que tu clúster esté disponible nuevamente, reinicia mongosync y usa los mismos parámetros que se interrumpieron en la sincronización anterior.
Sincronización pausada
Si mongosync está en el estado PAUSADO, mongosync no admite las siguientes acciones:
Actualizar la versión de MongoDB del clúster de origen o destino
Habilitar y luego deshabilitar el balanceador
Puedes actualizar mongosync mientras está en el estado PAUSED.