Data Transmission Service:Cross-account migration

Límites de la base de datos de origen

• Requisito de ancho de banda: El servidor que aloja la base de datos de origen debe tener suficiente ancho de banda de salida. De lo contrario, la velocidad de migración de datos se verá afectada.

• No se admite la versión 2.8 de Tair (compatible con Redis OSS) como origen.

• Si ejecuta solo la migración completa (sin incremental), detenga las escrituras en el origen durante la migración para evitar inconsistencias en los datos.

• Al migrar desde un origen Basic Edition hacia un destino con arquitectura de clúster, utilice exclusivamente operaciones de clave única. Los comandos de múltiples claves que abarcan varios slots devuelven el siguiente error:

  CROSSSLOT Keys in request don't hash to the same slot

• DTS inserta una clave con el prefijo DTS_REDIS_TIMESTAMP_HEARTBEAT en el origen para rastrear las marcas de tiempo de actualización. Si el origen utiliza una arquitectura de clúster, esta clave se inserta en cada shard. La clave se filtra durante la migración y caduca al finalizar la tarea.

• Si el origen es una instancia de solo lectura o la cuenta de DTS carece de permiso SETEX, la latencia reportada podría ser inexacta.

• Para mejorar la estabilidad de la migración, aumente el parámetro repl-backlog-size en redis.conf.

• Si el origen es una instancia Tair Enterprise Edition con Storage Medium configurado en Persistent Memory, establezca el parámetro appendonly en yes. Para más detalles, consulte Procedure.

• Si el origen es una instancia secundaria de un Global Distributed Cache, DTS migra únicamente dicha instancia secundaria. No se admiten otras instancias secundarias.

Otros límites

• Ni el origen ni el destino admiten instancias de almacenamiento de capacidad de Tair (compatible con Redis OSS) Enterprise Edition.

• Si el cifrado transparente de datos (TDE) está habilitado en cualquiera de las instancias, DTS no podrá realizar la migración.

• Si el destino se queda sin memoria, la directiva de desalojo predeterminada (maxmemory-policy) es volatile-lru, lo cual puede causar inconsistencia en los datos. Para evitar la pérdida silenciosa de datos, configure la directiva de desalojo del destino en noeviction. Con noeviction, las operaciones de escritura fallan cuando la memoria está llena y la tarea se detiene, pero no se elimina ningún dato de forma silenciosa. Para detalles sobre las directivas, consulte Introduction to Redis data eviction policies.

• Si la instancia de destino utiliza una arquitectura de clúster y algún shard alcanza su límite de memoria, o si la instancia agota su espacio de almacenamiento, la tarea de DTS fallará con un error de falta de memoria (OOM).

• Las operaciones de escalado (agregar o eliminar shards), los cambios de especificaciones o las modificaciones de endpoint o puerto en cualquiera de las instancias durante la migración interrumpirán la tarea. Si esto ocurre, borre todos los datos sincronizados del destino y reconfigure la tarea.

• Tras un evento de failover (incluido el cambio de primario a secundario) en el destino, los datos podrían escribirse solo en la memoria sin replicarse al nodo secundario, lo que provocaría pérdida de datos.

• Si una instancia de migración incluye tareas completas e incrementales, reiniciar la instancia puede provocar que DTS vuelva a ejecutar ambas tareas.

• Reiniciar una instancia de migración puede causar que los comandos no idempotentes (como INCRBY o LPUSH) se ejecuten repetidamente, lo que genera inconsistencia en los datos.

• Para scripts de Lua invocados mediante EVAL o EVALSHA, DTS no puede confirmar la ejecución exitosa durante la migración incremental.

• Para estructuras de datos List, DTS no vacía los datos existentes en el destino al usar psync o sync, lo que puede resultar en entradas duplicadas.

• Si las claves en el origen tienen directivas de caducidad, el recuento de claves visible en el destino (por ejemplo, mediante INFO) podría ser menor que en el origen. Las claves sin directivas de caducidad o las claves no caducadas son consistentes entre el origen y el destino.

• Cuando el Access Method es Public IP Address, Instance Mode no admite Cluster.

• Ejecute la migración fuera del horario pico. La migración completa consume recursos de lectura y escritura en ambas instancias.

• Después de la migración completa, el espacio de almacenamiento del destino será mayor que el del origen debido a las operaciones INSERT concurrentes.

• DTS intenta recuperar automáticamente las tareas con errores durante un máximo de siete días. Antes de cambiar el tráfico al destino, detenga o libere la tarea, o revoque el permiso de escritura de la cuenta de DTS mediante REVOKE para evitar que las tareas recuperadas sobrescriban los datos del destino.

• Si participa una instancia Tair (compatible con Redis OSS) cifrada con TLS, conéctese a DTS usando SSL-encrypted (TLSv1.3 no es compatible). Actualmente no se admite la conexión con SSL-encrypted a un origen de tipo Alibaba Cloud Instance.

• Si una tarea falla, el personal de soporte de DTS intentará restaurarla en un plazo de ocho horas. La restauración puede implicar reiniciar la tarea o ajustar sus parámetros. Solo se modifican los parámetros de la tarea de DTS, no los de la base de datos. Para consultar los parámetros ajustables, véase Modify instance parameters.

Casos especiales para orígenes Redis autogestionados

Cuando el Access Method de origen no es Alibaba Cloud Instance:

• Un cambio de primario a secundario en el origen provoca el fallo de la tarea.

• DTS calcula la latencia comparando la marca de tiempo del último registro migrado con la hora actual. Si el origen no tiene actividad DML durante un período prolongado, la latencia mostrada puede ser inexacta. Ejecute una operación DML en el origen para actualizar la latencia. Si migra una base de datos completa, utilice una tabla de latidos que escriba datos cada segundo.

• Los cambios en el endpoint de Redis durante la migración (por ejemplo, debido a la migración de la instancia o al cambio de primario a secundario) pueden causar reintentos, retrasos, fallos o inconsistencia en los datos. Monitoree el estado de la tarea y reconfigúrela si detecta comportamientos anómalos.

Paso 1: Abrir la lista de tareas de migración

Inicie sesión con la cuenta de destino y vaya a la lista de tareas de migración de datos mediante uno de estos métodos:

Paso 2: Crear la tarea

Haga clic en Create Task para abrir la página de configuración de la tarea.

Paso 3: Configurar las bases de datos de origen y destino

Configure los parámetros tanto para la base de datos de origen como para la de destino:

Nombre de la tarea

Base de datos de origen

Base de datos de destino

Paso 4: Probar la conectividad

Haga clic en Test Connectivity and Proceed en la parte inferior de la página.

Asegúrese de que los rangos de IP del servicio DTS estén agregados a la configuración de seguridad de ambas instancias. Consulte Add DTS server IP addresses to a whitelist .

Si alguna de las instancias es autogestionada (el Access Method no es Alibaba Cloud Instance ), haga clic en Test Connectivity en el cuadro de diálogo CIDR Blocks of DTS Servers .

Paso 5: Configurar los objetos de migración

En la página Configure Objects, configure los siguientes parámetros:

Haga clic en Next Advanced Settings y configure lo siguiente:

Haga clic en Next Data Verification para configurar la verificación de datos. Para más detalles, consulte Configure a data verification task.

Paso 6: Ejecutar la comprobación previa

Haga clic en Next: Save Task Settings and Precheck.

Para previsualizar los parámetros de la API correspondientes a esta configuración, pase el cursor sobre el botón y haga clic en Preview OpenAPI parameters .

DTS ejecuta una comprobación previa antes de iniciar la migración. La tarea comienza únicamente después de superar dicha comprobación.

Si la comprobación previa falla, haga clic en View Details junto al elemento fallido, solucione el problema y vuelva a ejecutar la comprobación previa.

Si aparece una advertencia: para los elementos que no se pueden omitir, solucione el problema y vuelva a ejecutar. Para los elementos que sí se pueden omitir, haga clic en Confirm Alert Details > Ignore > OK > Precheck Again . Ignorar advertencias puede causar inconsistencia en los datos.

Paso 7: Adquirir e iniciar

1. Cuando Success Rate alcance el 100%, haga clic en Next: Purchase Instance.

2. En la página Purchase, seleccione la clase de instancia:

   Parámetro	Descripción
   Resource Group Settings	Seleccione el resource group para esta instancia. Predeterminado: default resource group. Consulte What is Resource Management?.
   Instance Class	Seleccione una especificación según sus requisitos de volumen y velocidad de migración. Consulte Data migration link specifications.

3. Lea y acepte los Data Transmission Service (Pay-as-you-go) Service Terms.

4. Haga clic en Buy and Start y luego haga clic en OK en el cuadro de diálogo de confirmación.

Monitoree el progreso de la migración en la página de migración de datos.

Si la tarea incluye migración completa e incremental, se muestra como Incremental Data Migration en la página de lista de tareas de migración.