Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Résolution des problèmes liés à mon SQL terminal
Cette section contient des scénarios de réplication spécifiques à MySQL. AWS DMS analyse régulièrement le journal My SQL binary pour répliquer les modifications. Ce processus peut augmenter la latence dans les scénarios suivants :
Rubriques
Transaction de longue durée sur la source
Comme My écrit SQL uniquement les transactions validées dans le journal binaire, les transactions de longue durée provoquent des pics de latence proportionnels à la durée d'exécution de la requête.
Pour identifier les transactions de longue durée, utilisez la requête suivante ou utilisez le journal des requêtes lentes :
SHOW FULL PROCESSLIST;
Pour plus d'informations sur l'utilisation du journal des requêtes lentes, consultez le journal des requêtes lentes
Pour éviter les pics de latence liés aux transactions de longue durée, restructurez vos transactions sources afin de réduire le temps d’exécution des requêtes ou d’augmenter la fréquence de validation.
Charge de travail élevée sur la source
Comme il DMS CDC s'agit d'un processus à thread unique, un grand nombre de transactions peut augmenter la latence de la source. Pour déterminer si la latence source est due à une charge de travail importante, comparez le nombre et la taille des journaux binaires générés pendant la période de latence aux journaux générés avant cette latence. Pour vérifier les journaux binaires et l'état des DMS CDC threads, utilisez les requêtes suivantes :
SHOW BINARY LOGS; SHOW PROCESSLIST;
Pour plus d'informations sur les états des threads de vidage de journaux CDC binaires, consultez la section États des threads source de réplication
Vous pouvez déterminer la latence en comparant la dernière position du journal binaire générée sur la source avec celle de l'événement DMS en cours de traitement. Pour identifier le dernier journal binaire de la source, procédez comme suit :
Activez les journaux de débogage sur le CAPTURE composant SOURCE _.
Récupérez le journal binaire de DMS traitement et les détails de position dans les journaux de débogage des tâches.
Utilisez la requête suivante pour identifier le dernier journal binaire de la source :
SHOW MASTER STATUS;
Pour optimiser davantage les performances, réglez EventsPollInterval. Par défaut, DMS interroge le journal binaire toutes les 5 secondes, mais vous pouvez améliorer les performances en réduisant cette valeur. Pour plus d'informations sur le paramètre EventsPollInterval, consultez Paramètres du point de terminaison lors de l'utilisation de My SQL comme source pour AWS DMS.
Contention des journaux binaires
Lorsque vous migrez plusieurs tables contenant une grande quantité de données, nous vous recommandons de les diviser en tâches distinctes pour My SQL 5.7.2 ou version ultérieure. Dans My SQL versions 5.7.2 et ultérieures, le thread de vidage principal réduit les conflits de verrouillage et améliore le débit. Par conséquent, le thread de vidage ne verrouille plus le journal binaire chaque fois qu’il lit un événement. Cela signifie que plusieurs threads de vidage peuvent lire le fichier journal binaire simultanément. Cela signifie également que les threads de vidage peuvent lire le journal binaire pendant que les clients écrivent dans celui-ci. Pour plus d'informations sur les threads de vidage, consultez Replication Threads
Pour améliorer les performances de réplication pour les versions de Mes SQL sources antérieures à la version 5.7.2, essayez de consolider les tâches avec des CDC composants.
