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 is not supported. If you run convertToCapped, mongosync exits with an 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 obtener más información,setUserWriteBlockMode consulte.

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

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

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

If you issue a dropDatabase command on the source cluster, this change is not directly applied on the destination cluster. Instead, Mongosync drops user collections and views in the database on the destination cluster, but it does not drop system collections on that database.

Por ejemplo, en el clúster de destino:

• The drop operation does not affect a user-created system.js collection.

• If you enable profiling, the system.profile collection remains.

• If you create views on the source cluster and then drop the database, replicating the drop removes the views, but leaves an empty system.views collection.

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 una relación entre los UUID en el clúster de origen y el clúster de destino. Si las aplicaciones contienen UUID codificados (que MongoDB no recomienda), es posible que se deba actualizar esas aplicaciones 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 __mdb_internal con. A partir 1 de, y18 semongosync ignoran todas las bases de datos que comienzan __mdb_internal con.

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)

Using DDL operations (operations that act on collections or databases such as db.createCollection() and db.dropDatabase()) during sync increase the risk of migration failure and may negatively impact mongosync performance. For best performance, refrain from performing DDL operations on the source cluster while the sync is in progress.

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

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.