Data Transmission Service:Migrar datos de una base de datos MongoDB autogestionada (arquitectura de clúster fragmentado) a una instancia de ApsaraDB for MongoDB (arquitectura de conjunto de réplicas o clúster fragmentado)

Límites de la base de datos de origen

• El servidor debe contar con suficiente ancho de banda de salida. Un ancho de banda insuficiente ralentiza la migración

• Las colecciones que se van a migrar deben tener restricciones PRIMARY KEY o UNIQUE, con todos los campos únicos. De lo contrario, pueden aparecer registros duplicados en el destino

• DTS consume recursos de lectura y escritura tanto en la base de datos de origen como en la de destino durante la migración completa de datos, lo que aumenta la carga del servidor. Ejecute las migraciones en horarios de baja demanda

• Si las bases de datos de origen y de destino usan distintas versiones de MongoDB o motores de almacenamiento, compruebe primero la compatibilidad. Consulte Versiones de MongoDB y motores de almacenamiento

• Para la migración incremental de datos, habilite oplog en la base de datos de origen y reténgalo durante como mínimo 7 días. Si oplog no está habilitado, se devuelven mensajes de error durante la comprobación previa y no se puede iniciar la tarea de migración de datos. Si DTS no logra obtener el oplog, la tarea falla y puede producirse inconsistencia o pérdida de datos. Estos requisitos de retención quedan fuera del acuerdo de nivel de servicio (SLA) de DTS

• Si selecciona colecciones como objetos de migración y planea editarlas en el destino (por ejemplo, cambiarles el nombre), una sola tarea admite hasta 1,000 colecciones. Para más de 1,000 colecciones, configure varias tareas o migre la base de datos completa

• No utilice la base de datos admin ni local como origen o destino

• La base de datos MongoDB autogestionada de origen no puede tener más de 10 nodos mongos

• No migre colecciones con índices de tiempo de vida (TTL). Los índices TTL pueden causar inconsistencia de datos entre el origen y el destino después de la migración

• Asegúrese de que no existan documentos huérfanos en la base de datos de origen ni en la instancia de clúster fragmentado de destino. Los documentos huérfanos pueden provocar inconsistencia de datos o el fallo de la tarea. Consulte la documentación de MongoDB y ¿Cómo elimino los documentos huérfanos de una base de datos MongoDB desplegada con arquitectura de clúster fragmentado?

Durante la migración, no ejecute los siguientes comandos en la base de datos de origen, ya que cambian la distribución de los datos y causan inconsistencia:

• shardCollection, reshardCollection, unshardCollection, moveCollection, movePrimary

Durante la migración de esquema y la migración completa de datos:

• No modifique los esquemas de bases de datos ni de colecciones, incluida la actualización de tipos de arreglo. Los cambios de esquema provocan el fallo de la tarea o inconsistencia de datos

• No escriba datos en la base de datos de origen si ejecuta únicamente la migración completa de datos (sin la incremental). Para garantizar la consistencia de los datos, seleccione la migración de esquema, la migración completa de datos y la migración incremental de datos de forma conjunta

Si el balanceador de la base de datos de origen está activo durante la migración, el traslado de fragmentos puede introducir latencia.

Otros límites

• Si compra una instancia de DTS antes de configurar una tarea, especifique la cantidad de fragmentos al momento de la compra

• DTS no puede conectarse a una base de datos MongoDB mediante una cadena de conexión SRV

• Agregue claves de fragmentación a todos los datos de la base de datos de origen antes de iniciar la migración. Durante la migración, las operaciones INSERT deben incluir claves de fragmentación y las operaciones UPDATE no pueden modificarlas

• Deshabilite el balanceador de la base de datos MongoDB de origen durante la migración completa de datos. Manténgalo deshabilitado hasta que cada subtarea alcance la fase de migración incremental de datos. Volver a habilitarlo antes de tiempo causa inconsistencia de datos. Consulte Gestión del balanceador de ApsaraDB for MongoDB

• Asegúrese de que la base de datos de destino no contenga documentos con la misma clave primaria (_id) que el origen. Si existen duplicados, elimine los documentos correspondientes en el destino antes de iniciar la migración

• La información de las transacciones no se conserva. Las transacciones migradas se convierten en registros individuales

• Si ocurre un conflicto de clave primaria o única cuando DTS escribe en el destino, DTS omite la escritura conflictiva y conserva los datos existentes

• No escale una instancia de clúster fragmentado de ApsaraDB for MongoDB mientras se ejecuta una tarea de migración. El escalado provoca el fallo de la tarea

• Consulte el conteo de registros en la base de datos de destino de ApsaraDB for MongoDB mediante db.$table_name.aggregate([{ $count:"myCount"}])

• Dado que DTS escribe datos de forma concurrente, el espacio de almacenamiento utilizado en el destino es entre un 5 % y un 10 % mayor que en el origen

• Si una colección de destino tiene un índice único o el atributo capped establecido en true, la colección solo admite escrituras de un solo hilo y no admite reproducción concurrente durante la migración incremental. Esto puede aumentar la latencia de la migración

• La migración completa de datos consume recursos de lectura y escritura en ambas bases de datos, lo que aumenta la carga del servidor. Ejecute las migraciones en horarios de baja demanda

• Las operaciones INSERT concurrentes durante la migración completa de datos causan fragmentación de tablas. Después de esta migración, el espacio de tablas en el destino es mayor que en el origen

• DTS intenta reanudar las tareas de migración con errores durante un máximo de 7 días. Antes de trasladar las cargas de trabajo a la instancia de destino, detenga o libere cualquier tarea con errores, o revoque los permisos de escritura de DTS en el destino. De lo contrario, los datos de origen sobrescribirán los de destino cuando se reanude una tarea fallida

• Si una tarea de DTS falla, el soporte técnico de DTS intenta restaurarla en un plazo de 8 horas. Durante la restauración, la tarea puede reiniciarse y sus parámetros pueden modificarse

  Solo se pueden modificar los parámetros de la tarea; los parámetros de la base de datos no cambian. Los parámetros que pueden modificarse se enumeran en la sección Modificar parámetros de instancia .

• Si el destino es una instancia de conjunto de réplicas:

  • Si la conexión es mediante Express Connect, VPN Gateway, Smart Access Gateway, Public IP Address o Cloud Enterprise Network (CEN): establezca Domain Name or IP y Port Number