Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

Limitaciones

Advertencia

mongosync no verifica el cumplimiento de las limitaciones documentadas. Es importante asegurarse de que la aplicación no se vea afectada por las limitaciones.Ejecutar mongosync en presencia de una de estas limitaciones podría provocar un comportamiento indefinido en el clúster de destino.

Debe respetar estas limitaciones durante toda la migración, incluso cuando la migración esté pausada o detenida si se reanudará.

Nota

Para obtener información sobre la compatibilidad del servidor MongoDB, consulte Compatibilidad de la versión de MongoDB Server.

  • mongosync No admite actualizaciones de versiones de servidor locales que cambien la versión principal o secundaria durante una migración. mongosync sí permite actualizaciones de versiones de parche. Para obtener más información, consulte Instrucciones de actualización del servidor.

  • mongosync No valida que los clústeres o el entorno estén configurados correctamente.

  • Otros clientes no deben escribir en el clúster de destino mientras mongosync esté en ejecución.

  • Si se desea iniciar el proceso de confirmación y no se ha establecido enableUserWriteBlocking en "sourceAndDestination" al utilizar el punto final start, es necesario impedir la escritura en el clúster de origen antes de iniciar el proceso de confirmación.

  • colecciones system.* no se replican.

  • No se admiten documentos que tengan nombres de campos que comiencen con el símbolo dólar ($). Consulte Nombres de campos con puntos y signos de dólar.

  • Los clústeres sin servidor no son compatibles.

  • Un MongoDB Shared nivel no es compatible.

  • No se admite Queryable Encryption.

  • No se puede sincronizar una colección que tenga un índice único y un índice no único definido en los mismos campos.

  • Antes de intentar ejecutar mongosync con un clúster de Atlas M10+, desactive el Require Indexes for All Queries opción para establecer notablescan a false en ambos clústeres, fuente y destino.

  • mongosync No sincroniza usuarios ni roles.

  • mongosync no replica operaciones realizadas en el clúster de origen durante la sincronización con el clúster de applyOps destino.

  • mongosync debe leer desde el clúster de origen utilizando la primary preferencia de lectura.

  • mongosync no admite clústeres de origen o destino que actualmente estén actualizando versiones de MongoDB.

  • mongosync no admite la sincronización de Índices de búsqueda Atlas.

  • mongosync solo admite clústeres que utilizan el motor de almacenamiento WiredTiger.

  • No puedes sincronizar una colección con ningún documento que tenga una marca de tiempo vacía, como Timestamp(0,0) en versiones anteriores a6.0 clúster de origen.

  • mongosync no admite documentos con nombres de campo duplicados. Para más detalles, consulta MongoDB no admite nombres de campos duplicados.

MongoDB no prueba Mongosync con Community builds y en la mayoría de los casos, MongoDB no ofrece asistencia para Mongosync con implementaciones de Community. Si deseas usar Mongosync con MongoDB Community Edition, contacta a un representante de ventas de MongoDB para hablar sobre requisitos y opciones individuales.

  • No se admiten colección de series de tiempo.

  • Las colecciones con índice clusterizado con expireAfterSeconds establecido no son compatibles.

  • mongosync no admite sincronizar desde un clúster a un set de réplicas.

  • mongosync no admite la sincronización con una topología de clúster fragmentada con uno o más árbitros.

  • mongosync No admite la sincronización hacia o desde clústeres globales.

  • La sincronización desde un conjunto de réplicas a un clúster fragmentado tiene las siguientes limitaciones:

    • mongosync Permite a los usuarios renombrar las colecciones que sharding.shardingEntries incluye la opción durante la sincronización, con algunas limitaciones. Para más información,consulte "Renombrar durante la sincronización".

    • Si utilizas la opción sharding.createSupportingIndexes, los índices se crean automáticamente en el clúster de destino durante la sincronización. No se pueden crear estos índices posteriormente en el clúster de origen.

    • Si quieres crear un índice para admitir las claves de partición manualmente, debes crear el índice antes de que mongosync comience o después de que se complete la migración y mongosync se detenga.

  • Dentro de una colección, el campo _id debe ser único en todas las particiones del clúster. Consulta Clústeres particionados e índices únicos para obtener más detalles.

  • No se puede utilizar el comando movePrimary para reasignar la partición primaria durante la sincronización.

  • No hay replicación para la configuración de zonas. mongosync replica datos, no hereda zonas.

  • No se pueden agregar ni eliminar particiones mientras se está sincronizando.

  • mongosync solo sincroniza los índices que existen en todas las particiones.

  • mongosync solo sincroniza los índices que tienen especificaciones de índice coherentes en todas las particiones.

    Nota

    Para comprobar la presencia de inconsistencias en los índices, consulta Find Inconsistent Indexes Across Particiones.

  • Si el clúster de origen o destino es un clúster fragmentado y no está ejecutando mongosync con filtrado de espacio de nombres, debe deshabilitar el equilibrador del clúster de origen ejecutando el comando y balancerStop esperando 15 minutos para que se complete el comando.

    Si el clúster de origen o destino es un clúster fragmentado y está ejecutando mongosync con filtrado de espacios de nombres, puede habilitar globalmente el equilibrador del clúster de origen, pero debe desactivarlo para todas las colecciones dentro del filtro de espacios de nombres. Consulta Cómo desactivar el balanceador para colecciones en sincronización filtrada. También se puede deshabilitar completamente el balanceador del clúster de origen.

    Siempre debes deshabilitar el balanceador en un clúster de destino particionado usando balancerStop.

  • Si has activado el balanceador del clúster de origen, pero lo has desactivado para las colecciones dentro del filtro de espacio de nombres, no ejecutes shardCollection en las colecciones dentro del filtro de espacio de nombres. Si ejecutas shardCollection en las colecciones dentro del filtro del namespace durante la migración, mongosync devuelve un error y se detiene, lo que requiere que inicies la migración desde cero.

  • mongosync no es compatible con ejecutar el comando transitionFromDedicatedConfigServer durante la ejecución.

  • No debe ejecutar los moveChunk comandos y en los clústeres de origen o destino.moveRange

  • La clave de partición no puede ser refinada mientras se está sincronizando.

  • Las operaciones del clúster de origen no se admiten durante la reshardCollection sincronización.

  • El número máximo de índices por colección particionada es 63, que es uno menos que el límite por defecto de 64.

  • mongosync no admite colecciones con una intercalación no por defecto en clústeres sharded. Esto aplica tanto a colecciones particionadas como unsharded.

  • mongosync errores en índices que son inconsistentes o faltan en algunos fragmentos que contienen datos.

  • mongosync falla si hay una ventana de balanceo configurada en el clúster de origen o destino.

  • Si la fuente anterior tiene índices únicos que están parcialmente distribuidos a través de particiones, revertirlo puede causar fallos. Asegúrese de que existan índices únicos en todas las particiones antes de revertir.

  • Los clústeres de origen y destino deben tener el mismo número de fragmentos. No se puede revertir la sincronización cuando los clústeres tienen topologías diferentes.

  • Los clústeres de origen y destino deben ejecutar la misma versión principal de MongoDB.

  • Para invertir la dirección, mongosync requiere que todos los índices únicos en el clúster de origen (excepto _id) no tengan claves de índice único heredadas.

  • mongosync no admite la sincronización de varios clústeres de origen a un clúster de destino.

  • Un clúster no puede ser simultáneamente un clúster de origen en una instancia mongosync y un clúster de destino en otra instancia mongosync.

  • El filtrado no es compatible con la sincronización reversible.

  • El clúster de destino no debe contener datos de usuario antes de comenzar a menos que establezca el parámetro preExistingDestinationData en true al llamar a /start.

  • El clúster de destino no debe contener la base de datos del sistema mongosync_reserved_for_internal_use antes de comenzar.

  • No puede modificar un filtro que esté en uso. Para crear un nuevo filtro, consulta: Reemplazar un filtro existente.

  • Solo puedes renombrar las colecciones en ciertas situaciones. Para más detalles, consulta: Añadir y renombrar colecciones.

  • Si un filtro incluye una vista pero no la colección base, sólo los metadatos de la vista se sincronizan con el clúster de destino. Para incluir los documentos de vista, también debe sincronizar la colección base.

  • No puedes especificar colección del sistema ni base de datos del sistema en un filtro.

  • Para usar la $out etapa de agregación o el comando (cuando mapReduce se configura para crear o reemplazar una colección) con filtrado, debe configurar el filtro para que use toda la base de datos. No puede limitar el filtro a colecciones dentro de la base de datos.

    Para obtener más información,consulte Filtrado con mapReduce y $out.

  • El filtrado no admite el bloqueo de escritura dual. Puede usar el bloqueo de escritura solo en el destino.

A partir de 1.3.0, Mongosync admite colecciones con tamaño fijo con algunas limitaciones.

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.

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.

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.

A partir de 1.9, mongosync puede usar un verificador incorporado para confirmar la sincronización exitosa de las recopilaciones del clúster de origen al clúster de destino.

El verificador integrado no está disponible en mongosync 1.8 y anteriores.

Para métodos de verificación alternativos, ve Verificar transferencia de datos.

El verificador integrado tiene las siguientes limitaciones:

  • mongosync almacena el estado del verificador en la memoria, lo que puede causar una sobrecarga significativa de memoria. Para ejecutar el verificador, mongosync requiere aproximadamente 10 GB de memoria, además de 500 MB adicionales por cada 1 millones de documentos.

  • No se puede reanudar el verificador. Si un usuario detiene o pausa la sincroniza y luego inicia mongosync nuevamente por cualquier motivo, el proceso de verificación se reinicia desde el principio. Esto puede hacer que la verificación quede sustancialmente por detrás de la migración.

  • Al migrar de un set de réplicas a un clúster, no puedes renombrar las colecciones de origen que especificas en las opciones de particionado. Si renombras una colección incluida en las opciones de particionado durante la fase de CEA, el verificador informa un desajuste de particionado.

  • Si inicias la sincronización con la verificación habilitada y buildIndexes configurado en never, la migración fallará si mongosync encuentra una colección TTL en el clúster de origen. Esto puede suceder después de que llames al endpoint /start o mucho más tarde, como cuando un usuario crea un índice TTL en el clúster de origen mientras una migración está en curso.

    Para sincronizar colecciones TTL sin crear índices en el clúster de destino, debe iniciar la sincronización con el verificador deshabilitado.

El verificador no comprueba los siguientes espacios de nombres:

  • Colecciones con tamaño fijo

  • Colecciones con índices TTL, incluidos los índices TTL que se agregan o eliminan durante la migración

  • Colecciones que no utilizan la intercalación predeterminada

Para verificar colecciones no admitidas, añada código de script adicional para examinar las colecciones. Para obtener más información, consulta Verificar transferencia de datos.

Nota

A partir de la versión 1.10, el verificador verifica inconsistencias de datos provenientes de un evento DDL que ocurrió en el pre-6.0 clúster de origen durante la migración. Esto se debe a que anterior a6.0 las migraciones no admiten eventos DDL.

Para obtener más información, consulte 6.0 Limitaciones de migración anteriores a.

mongosync no migra la Configuración de query Persistente (PQS), que se introdujo en MongoDB 8.0. Si tu clúster de origen utiliza PQS, debes migrarlos manualmente.

A partir de 1.10, mongosync admite migraciones desde clústeres de origen que ejecutan versiones del servidor de MongoDB anteriores a 6.0. Para obtener información sobre las rutas de migración compatibles, consulte Compatibilidad de versiones de MongoDB Server.

Se aplican las siguientes limitaciones al pre-6.0 migración:

  • El clúster de origen no puede tener documentos huérfanos. Para limpiar cualquier documento huérfano, ejecuta el comando cleanupOrphaned en las instancias mongod en el nodo principal de cada partición en su clúster de origen. Espera a que este comando se complete con un estado {ok:1} antes de iniciar la migración.

  • Las escrituras que generan eventos DDL no pueden ocurrir en el clúster de origen durante la migración. Los siguientes eventos no pueden ocurrir:

    • collMod

    • create

    • createIndexes

    • drop

    • dropDatabase

    • dropIndexes

    • refineCollectionShardKey

    • rename

    • reshardCollection

    • shardCollection

    Esto incluye operaciones que pueden crear nuevas colecciones,mapReduce como, y. También incluye colecciones creadas implícitamente a partir de inserciones. Durante la migración, solo$out $mergese pueden realizar operaciones de escritura que generen eventos CRUD.

    Nota

    Se permiten escrituras que produzcan eventos DDL en colecciones de origen fuera del filtro de espacio de nombres.

  • geoHaystack los índices no son compatibles.

  • /reverse el endpoint no es compatible. No puede activar la opción reversible en la solicitud /start.

  • No puedes establecer la opción enableUserWriteBlocking en "sourceAndDestination" en la solicitud /start, por lo que el bloqueo dual de escritura no es compatible. Se admite el bloqueo de guardar solo para el destino. Asegúrese de que no se realicen guardados en el clúster de origen después de llamar al punto final /commit.

  • No puedes habilitar el parámetro de particionado createSupportingIndexes. En su lugar, crea un índice para admitir tu clave de partición en el clúster de origen.

  • Si hay algún índice con especificaciones inconsistentes o que falte en una o más particiones, mongosync devuelve un error. Para comprobar inconsistencias de índices, consulta Buscar índices inconsistentes en las particiones.

Volver

Dirección para sincronizar a la inversa

En esta página