mongosync Comportamiento

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.

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.

db.adminCommand(
  { 
    setAllowMigrations: “<db>.<collection>”,
    allowMigrations: false
  }
)

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.

• convertToCapped no es compatible. Si ejecutas convertToCapped, mongosync sale con un error.

• cloneCollectionAsCapped No es compatible.

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 la cantidad máxima de documentos y el tamaño máximo de documentos durante la confirmación.

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. mongosync desbloquea los guardados justo antes de establecer canWrite en true

• En 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 de escritura dual cuando mongosync inicie.

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.

Manejo de índices heredados

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.

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.

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.

• Construya 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_use

• Cualquier 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.

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 elimina una base de datos con vistas en el origen, el destino podría mostrar una colección system.views vacía. Esta colección system.views vacía no afectará 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.js

• Si habilitas la creación de perfiles, la colección system.profile permanece.

• 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 se deja una colección system.views vací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.

UUID

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.

Bases de datos internas de MongoDB Atlas

MongoDB Atlas y otros servicios en la nube almacenan datos esenciales en bases de datos internas dedicadas dentro de su clúster. Estas bases de datos comienzan con __mdb_internal. A partir de 1.18, mongosync ignora todas las bases de datos que empiezan con __mdb_internal.

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 mongosync y las particiones de destino

Para cada operación en el clúster de origen, mongosync realiza 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

mongosync ejecuta 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

mongosync utiliza "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.

Errores y cierres inesperados

Si mongosync detecta un error o deja de estar disponible durante la sincronización, puede reanudar la operación mongosync desde donde se detuvo. El binario mongosync no tiene estado y almacena los metadatos para un reinicio en el clúster de destino.

Para continuar la sincronización, reinicie mongosync cuando vuelva a estar disponible y utilice los mismos parámetros que la sincronización interrumpida. Al reiniciar mongosync, el proceso se reanudará 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.