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

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.

A partir de 1.20.0, debe pasar el indicador --enableCappedCollectionHandling al iniciar mongosync para permitir la creación de nuevas colecciones limitadas durante una migración.

• convertToCapped no es compatible. Si ejecuta convertToCapped, mongosync finalizará con un error.

• cloneCollectionAsCapped no 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.

Bloqueo de escritura

mongosync administra el bloqueo de escritura en los clústeres de origen y destino internamente según tu configuración de migración:

mongosync los bloques de origen escriben después de que llames a /commit. Las escrituras de origen seguirán bloqueadas a menos que la migración falle con un error gestionado. Si mongosync termina inesperadamente durante el commit, puedes desbloquear las escrituras en el clúster de origen manualmente ejecutando el siguiente comando:

db.adminCommand(
   {
      setUserWriteBlockMode: 1,
      global: false
   }
)

Para más información, consulta setUserWriteBlockMode.

mongosync bloquea las escrituras de destino después de que llames a /start. Las escrituras de destino permanecen bloqueadas hasta que canWrite esté true en la respuesta de /progress.

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 "majority" para las lecturas en el clúster de origen. Para las escrituras en el clúster de 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 preferencia de lectura primary 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.

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 la creación de índices iterativos durante la migración. Para evitar la creación de índices de forma iterativa durante la migración, utilice uno de los siguientes métodos para garantizar que los índices de destino coincidan con los índices de origen:

• Construya el índice en la fuente antes de la migración.

• Cree el índice en el origen durante la migración con una configuración de índice 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:

• __mdb_internal_mongosync

• Cualquier cosa que comience con __mdb_internal_mongosync_verifier

Descartar cualquier base de datos de metadatos después de una migración exitosa.

coherencia

mongosync Admite consistencia eventual en el clúster de destino. La consistencia de lectura no está garantizada en el clúster de destino hasta la confirmación. Antes de la confirmación, los clústeres de origen y destino pueden diferir en un momento dado. Para obtener más información, consulte Consideraciones durante la sincronización.

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 del sistema en el clúster de destino.

Si se ejecuta el comando dropDatabase 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 datos.

Por ejemplo, en el clúster de destino:

• La operación de eliminación no afecta a una colección system.js creada por el usuario.

• Si habilita 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 queda 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.

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

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 comienzan con __mdb_internal.

Optimización de creación de índices

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 aumenta el riesgo de fallos en la migración y puede afectar negativamente al rendimiento de mongosync. 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,consulte Operaciones y transacciones DDL 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

Por cada operación de escritura en el clúster de origen, mongosync realiza un viaje de ida y vuelta al servidor de destino. mongosync también realiza solicitudes de soporte para cada lote de operaciones de escritura replicadas. 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 escrituras "majority" y lecturas "majority", 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 rendimiento.

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 recuperar la migración sin reiniciarla desde el principio. Después de que el clúster vuelva a estar en línea, reinicia el archivo binario mongosync utilizando los mismos parámetros de cadena de conexión de tu migración original. mongosync lee su estado almacenado del clúster de destino y reanuda automáticamente la sincronización.

Para verificar que la sincronización se ha reanudado, llama al endpoint /progress y confirma que state devuelve RUNNING.

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.