Comment résoudre le problème de latence cible élevée sur une tâche AWS DMS ?

Date de la dernière mise à jour : 23/01/2020

J'exécute une tâche AWS Database Migration Service (AWS DMS) de chargement complet et de capture des données modifiées (CDC). La latence source n'est pas élevée, mais la latence cible est élevée ou elle augmente. Comment résoudre le problème de latence cible élevée sur une tâche de migration AWS DMS ?

Brève description

Vous pouvez utiliser les métriques Amazon CloudWatch pour surveiller les statistiques de votre tâche de réplication. Plus précisément, vous pouvez surveiller CDCLatencySource et CDCLatencyTarget pour identifier la latence de réplication dans la phase de réplication continue (CDC). La métrique CDCLatencySource correspond à la latence entre la source et l'instance de réplication. La métrique CDCLatencyTarget correspond à la latence entre l'instance de réplication et la cible. Pour plus d'informations, consultez la page Métriques des tâches de réplication.

Une valeur CDCLatencySource élevée signifie que le processus de capture des modifications à partir de la source est retardé. Et une valeur CDCLatencyTarget élevée indique que le processus d'application des événements de modification à la cible est retardé. Si les valeurs CDCLatencySource et CDCLatencyTarget sont élevées, analysez d'abord la valeur CDCLatencySource, car la latence cible est toujours égale ou supérieure à la latence source. Une valeur CDCLatencyTarget élevée est la conséquence du retard dans la capture des événements de modification à partir de la source. Si la valeur CDCLatencySource n'est pas élevée et que la valeur CDCLatencyTarget est élevée, la latence peut être causée par les éléments suivants :

  • Il n'existe de clés primaires ni d'index dans la cible.
  • Il existe des goulots d'étranglement de ressources dans la cible.
  • Il existe des goulots d'étranglement de ressources dans l'instance de réplication.
  • Il existe un problème de réseau entre l'instance de réplication et la cible.

Pour résoudre ces problèmes, consultez Bonnes pratiques et résolution des problèmes.

Solution

Pas de clés primaires ou d'index dans la cible

Par défaut, AWS DMS écrit les modifications apportées à la cible à l'aide d'instructions DML (Data Manipulation Language), telles que INSERT, UPDATE ou DELETE, comme toute autre application. Si les index requis ne sont pas en place, les modifications, telles que les mises à jour (UPDATE) et les suppressions (DELETE), peuvent entraîner des analyses complètes de table. Les analyses complètes de la table peuvent entraîner des problèmes de performances sur la cible. Ces analyses entraînent ensuite une latence cible. Vérifiez vos schémas de base de données cible, en particulier si vous avez créé le schéma cible manuellement. Identifiez les requêtes lentes en utilisant des mécanismes de base de données cible, comme le journal des requêtes lentes pour MySQL, pg_stat_activity pour PostgreSQL, ou un plan de requête. Si votre cible est Amazon Redshift, vérifiez également le style de distribution de votre table. Tous les styles de distribution peuvent entraîner une latence cible, car ils mettent plus de temps pour insérer (INSERT) ou mettre à jour (UPDATE) les données dans les tables.

Goulots d'étranglement des ressources dans la cible

Si votre cible ne dispose pas de suffisamment de ressources, elle ne peut pas accepter les modifications à la vitesse à laquelle AWS DMS les envoie. Cela peut entraîner des goulots d'étranglement des ressources sur la cible et une latence cible. Cela peut également se produire si d'autres processus consomment des ressources dans la cible. Si la cible est hébergée sur AWS, vérifiez les statistiques des ressources à partir des métriques CloudWatch.

Goulots d'étranglement des ressources dans l'instance de réplication

Choisissez une instance de réplication qui dispose de suffisamment de ressources pour gérer votre migration : CPU, mémoire, réseau ou iOPS. Vous pouvez surveiller les ressources de votre instance de réplication à l'aide des métriques CloudWatch.

Problème de réseau entre l'instance de réplication et la cible

Les problèmes de bande passante et de latence réseau peuvent également entraîner des problèmes de latence, en particulier, lorsque votre cible est une base de données sur site, ou si vous utilisez AWS DMS pour la réplication entre régions.

Bonnes pratiques et résolution des problèmes

Si votre cible est Amazon Relational Database Service (Amazon RDS), suivez les bonnes pratiques d'amélioration des performances d'une migration AWS DMS. Amazon RDS dispose d'un mécanisme de sauvegarde automatique qui démarre dans la fenêtre de sauvegarde et sauvegarde les données déplacées. Si un instantané de l'instance de base de données cible était en cours de création, AWS DMS peut avoir des problèmes pour appliquer les modifications à la cible. Par conséquent, la latence cible augmente jusqu'à ce que la capture de l'instantané soit terminée. Si votre cible est Amazon Elastic Compute Cloud (Amazon EC2) ou une base de données sur site, vérifiez le mécanisme de sauvegarde de votre base de données cible.

Certains paramètres de tâche peuvent entraîner l'écriture lente des modifications sur la cible. Si vous exécutez une réplication continue à partir d'une source où le taux de modification est élevé, utilisez BatchApplyEnabled. Pour plus d'informations, consultez la section BatchApplyEnabled de Débogage de vos migrations AWS DMS : Que faire lorsque des choses vont mal ?

Pour affecter à BatchApplyEnabled la valeur True, exécutez la commande modify-replication-task en utilisant l'interface de ligne de commande (CLI) AWS :

aws dms modify-replication-task --replication-task-arn arn:aws:dms:ap-northeast-1:123456789012:task:ABCDEFGHIJKLMNOPQRSTUVWXYZ --replication-task-settings "{\"TargetMetadata\":{\"BatchApplyEnabled\":true}}"

Cet article vous a-t-il été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d’aide ?