El binario mongosync es el proceso principal utilizado en Mongosync. mongosync migra datos de un clúster a otro.
Para una visión general del proceso de 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 sincroniza usuarios ni roles. 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
Cuando el clúster de origen o de destino es un clúster fragmentado, debe detener el balanceador en ambos clústeres y no ejecutar los moveChunk moveRange comandos ni durante la migración. Para detener el balanceador, ejecute el comando y espere a que balancerStop finalice.
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 crea el doble de fragmentos de los que hay en el clúster de destino.
Distribución de fragmentos
Importante
Aunque el clúster de origen esté equilibrado, mongosync no garantiza el equilibrio del clúster de destino. Dado mongosync que no admite la ejecución de operaciones de fragmentación durante la migración, debe esperar hasta que sea seguro aceptar escrituras para reequilibrar el clúster de destino. Consulte el Balanceador de clústeres fragmentados para obtener orientación sobre cómo reequilibrar el clúster y las limitaciones de los clústeres fragmentados para obtener información sobre dichas limitaciones mongosync en.
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
Ejecutar en el clúster de origen o destino durante la migración puede provocar un error grave o requerir que reinicie la migración desde el principio. Para obtener más información,movePrimary 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 integrados, 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. SiconvertToCappedejecuta,mongosyncsaldrá 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 enableUserWriteBlocking establecer, el mongosync usuario debe tener un rol que incluya los setUserWriteBlockMode bypassWriteBlockingMode tipos de acción y.
Nota
Al enableUserWriteBlocking usar, las escrituras solo se bloquean para los usuarios que no tienen el tipo de acción. Los usuarios que tienen este tipo de acción pueden realizar bypassWriteBlockingMode escrituras.
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 preocupación de lectura en para las lecturas en el clúster de origen. Para las escrituras en el clúster de "majority" destino, mongosync establece el nivel de preocupación de escritura en "majority" con j: verdadero.
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 primary preferencia de lectura al conectarse a los clústeres de origen y destino. Para obtener más información, consulte 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 conjunto de réplicas. mongosync combina y reordena las escrituras desde el clúster de origen al clúster 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 no hayas llamado commit en mongosync y que canWrite devuelva true con éxito, el clúster de destino no podrá aceptar el tráfico de lectura ni de escritura de la aplicación. No utilices mongosync para mantener clústeres de recuperación ante desastres.
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 predeterminada.
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 se ejecuta el comando en el clúster de origen, este cambio no se aplica directamente en el clúster de destino. En su lugar, Mongosync elimina las colecciones y vistas de usuario en la base de datos del clúster de destino, pero no elimina las colecciones del sistema en dicha base de dropDatabase datos.
Por ejemplo, en el clúster de destino:
La operación de eliminación no afecta a una colección creada por el usuario.
system.jsSi habilita la creación de perfiles, la colección
system.profilepermanece.Si crea vistas en el clúster de origen y luego elimina la base de datos, al replicar la eliminación se eliminan las vistas, pero queda 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 nuevos UUID en el clúster de destino. No existe relación entre los UUID del clúster de origen y el de destino. Si las aplicaciones contienen UUID codificados (lo cual MongoDB no recomienda), es posible que deba actualizarlas para 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 anteriores devuelven un error si el clúster de destino contiene una __mdb_internal_atlas base de datos no vacía. Esta es una base de datos interna utilizada por MongoDB Atlas. Es posible que reciba un error que "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" indique.
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() db.dropDatabase()y) durante la sincronización aumenta el riesgo de fallos en la migración y puede afectar negativamente al mongosync rendimiento de. Para obtener el mejor rendimiento, evite realizar operaciones DDL en el clúster de origen mientras se esté realizando la sincronización.
Para obtener más información sobre las 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"escrituras y lecturas, que requieren confirmación de varios nodos en un conjunto de réplicas, incluidos los conjuntos de réplicas con respaldo de fragmentos. Si la mayoría de estos nodos no se encuentran en la misma región, esto tendrá consecuencias negativas en el"majority"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.