Solución de problemas de latencia de destino

Esta sección contiene escenarios que pueden contribuir a la latencia de destino.

Problemas de indexación

Durante la fase de CDC, AWS DMS replica los cambios en la fuente mediante la ejecución de sentencias DML (insertar, actualizar y eliminar) en la de destino. En el caso de las migraciones heterogéneas que utilizan DMS, las diferencias en las optimizaciones de los índices en el origen y el destino pueden provocar que la escritura en el destino tarde más tiempo. Esto provoca problemas de rendimiento y latencia del destino.

Para solucionar problemas de indexación, haga lo siguiente. Los procedimientos de estos pasos varían según los distintos motores de bases de datos.

• Monitoree el tiempo de consulta de la base de datos de destino. La comparación del tiempo de ejecución de la consulta en el destino y en el origen puede indicar qué índices necesitan optimizarse.

• Habilite el registro para consultas de ejecución lenta.

Para corregir problemas de indexación de réplicas de ejecución prolongada, haga lo siguiente:

• Ajuste los índices de las bases de datos de origen y destino para que el tiempo de ejecución de la consulta sea similar en el origen y en el destino.

• Compare los índices secundarios utilizados en las consultas de DML para el origen y el destino. Asegúrese de que el rendimiento de DML en el destino es comparable o mejor que el rendimiento de DML de origen.

Tenga en cuenta que el procedimiento para optimizar los índices es específico del motor de base de datos. No hay ninguna característica de DMS para ajustar los índices de origen y destino.

Mensaje de CLASIFICADOR en el registro de tareas

Si un punto final de destino no puede mantener el volumen de cambios que se AWS DMS escriben en él, la tarea almacena en caché los cambios en la instancia de replicación. Si la caché supera un umbral interno, la tarea deja de leer los cambios adicionales del origen. DMS lo hace para evitar que la instancia de replicación se quede sin espacio de almacenamiento o que la tarea se bloquee al leer un gran volumen de eventos pendientes.

Para solucionar este problema, consulte los CloudWatch registros para ver si hay un mensaje similar a uno de los siguientes:

[SORTER ]I: Reading from source is paused. Total disk usage exceeded the limit 90% (sorter_transaction.c:110)
[SORTER ]I: Reading from source is paused. Total storage used by swap files exceeded the limit 1048576000 bytes  (sorter_transaction.c:110)

Si los registros contienen un mensaje similar al primer mensaje, desactive cualquier registro de rastreo para la tarea y aumente el almacenamiento de las instancias de replicación. Para obtener información sobre cómo aumentar el almacenamiento de las instancias de replicación, consulte Modificación de una instancia de replicación.

Si los registros contienen un mensaje parecido al segundo mensaje, haga lo siguiente:

• Mueva las tablas con numerosas transacciones u operaciones de DML de larga ejecución a una tarea independiente, si no dependen de otras tablas de la tarea.

• Aumente la configuración MemoryLimitTotal y MemoryKeepTime para mantener la transacción en la memoria durante más tiempo. Esto no servirá de nada si la latencia se mantiene, pero puede ayudar a mantenerla baja durante periodos cortos de volumen transaccional. Para obtener más información sobre estos ajustes de tarea, consulte Configuración de ajuste del procesamiento de cambios.

• Evalúe si puede usar la aplicación por lotes para la transacción mediante la configuración de BatchApplyEnabled en true. Para obtener información acerca de la opción BatchApplyEnabled, consulte Configuración de las tareas de los metadatos de destino.

Bloqueo de base de datos

Si una aplicación accede a una base de datos que AWS DMS se utiliza como destino de replicación, la aplicación puede bloquear una tabla a la que DMS intenta acceder. Esto crea una contención de bloqueos. Dado que DMS escribe los cambios en la base de datos de destino en el orden en que se produjeron en el origen, los retrasos en la escritura en una tabla debido a problemas de bloqueo provocan retrasos en la escritura en todas las tablas.

Para solucionar este problema, consulte la base de datos de destino para comprobar si una contención de bloqueos bloquea las transacciones de escritura de DMS. Si la base de datos de destino está bloqueando las transacciones de escritura de DMS, realice una o varias de las siguientes acciones:

• Reestructure las consultas para confirmar los cambios con más frecuencia.

• Modifique la configuración de tiempo de espera del bloqueo.

• Divida las tablas para minimizar las contenciones de bloqueos.

Tenga en cuenta que el procedimiento para optimizar las contenciones de bloqueos es específico del motor de base de datos. No hay ninguna característica de DMS para ajustar las contenciones de bloqueos.

Búsquedas de LOB lentas

Cuando AWS DMS replica una columna de objetos grandes (LOB), realiza una búsqueda en el origen justo antes de escribir los cambios en el destino. Por lo general, esta búsqueda no provoca ninguna latencia en el destino, pero si la base de datos de origen retrasa la búsqueda debido a un bloqueo, la latencia de destino puede aumentar.

Este problema suele ser difícil de diagnosticar. Para solucionar este problema, habilite la depuración detallada en los registros de tareas y compare las marcas temporales de las llamadas de búsqueda de LOB de DMS. Para obtener información sobre cómo habilitar la depuración detallada, consulte Visualización y administración de los AWS registros de tareas del DMS.

Para solucionar este problema, intente lo siguiente:

• Mejore el rendimiento de las consultas SELECT en la base de datos de origen.

• Ajuste la configuración de LOB de DMS. Para obtener información acerca de cómo ajustar la configuración de LOB, consulte Migración de objetos binarios grandes () LOBs.

Multi-AZ, registros de auditoría y copias de seguridad

En el caso de los objetivos de Amazon RDS, la latencia del objetivo puede aumentar de la siguiente manera:

• Copias de seguridad

• Después de habilitar las zonas de disponibilidad múltiples (multi-AZ)

• Después de habilitar el registro de la base de datos, como los registros de auditoría o consultas lentas.

Estos problemas suelen ser difíciles de diagnosticar. Para solucionar estos problemas, monitoree la latencia para detectar picos periódicos durante los periodos de mantenimiento de Amazon RDS o periodos de grandes cargas de la base de datos.

Para corregir estos problemas, pruebe lo siguiente:

• Si es posible, durante una migración a corto plazo, desactive las zonas de disponibilidad múltiples (multi-AZ), las copias de seguridad o el registro.

• Reprograme los periodos de mantenimiento para los periodos de baja actividad.