Comment puis-je résoudre les problèmes liés au passage d'Amazon Redshift en mode traitement unitaire ?

Lecture de 4 minute(s)
0

Je souhaite utiliser une tâche AWS Database Migration Service (AWS DMS) pour transférer des données vers Amazon Redshift. Cependant, ma tâche présente des problèmes de latence ou d'incohérence de données, et je vois des entrées de journal comme « Échec de l'opération d'application de XXXXBulk. Nous tentons d'exécuter des instructions en bloc en mode un par un XXXXX. »

Brève description

L'entrepôt des données de traitement analytique en ligne (OLAP) Amazon Redshift n'est pas conçu pour effectuer des transactions fréquentes en raison des coûts qu’il engendre. AWS DMS utilise par défaut le mode Application par lot pour traiter les modifications par lots. Si Redshift s'exécute en mode traitement unitaire, c’est que la tâche DMS n'a pas appliqué des modifications à la cible, ce qui a entraîné des problèmes d'incohérence ou de latence dans les données. Lorsque vous utilisez le mode Application par lot, AWS DMS effectue les opérations suivantes :

  1. Collecte les modifications d'un lot contrôlé par les réglages d'application par lot.
  2. Crée une table des modifications nettes qui contient toutes les modifications apportées par le lot à l'instance cible.
  3. Utilise un algorithme qui regroupe les transactions et les applique à la cible en bloc.

Quand une tâche de migration qui réplique des données vers Amazon Redshift ne peut pas appliquer un lot, AWS DMS n'échoue pas sur l'ensemble du lot. AWS DMS décompose le lot et passe en mode traitement unitaire pour appliquer les transactions. Quand l'outil AWS DMS détecte la transaction à l'origine de l'échec du lot, il enregistre la transaction dans la table awsdms_apply_exceptions sur la cible Amazon Redshift. AWS DMS applique ensuite une par une les autres transactions du lot jusqu'à ce que toutes les transactions de ce lot soient appliquées à la cible. Enfin, AWS DMS repasse en mode Application par lot pour un nouveau lot et continue à l'utiliserApplication par lot tant qu'aucun autre lot n'échoue.

Résolution

Pour savoir si votre lot a échoué et si AWS DMS a utilisé le mode traitement unitaire, consultez le journal des tâches AWS DMS. Chaque fois qu'un lot échoue et qu'AWS DMS passe en mode traitement unitaire, l'entrée de journal suivante s'affiche :

« [TARGET_APPLY ]I: Échec de l'opération d'application en bloc. Nous tentons d'exécuter en mode un par un des instructions en bloc (bulk_apply.c:2175). »

Dans ce cas, AWS DMS applique les transactions de manière séquentielle à la cible jusqu'à ce que l'outil AWS DMS rencontre un problème avec une transaction dans le lot. Si AWS DMS rencontre un problème, il enregistre la transaction et une entrée de journal semblable à la suivante s'affiche :

« TARGET_APPLY ]W: Les modifications de source qui n'auraient eu aucun impact n'ont pas été appliquées à la base de données cible. Reportez-vous à la table 'awsdms_apply_exceptions' pour plus de détails. (endpointshell.c:5984). »

Remarque : à moins que vous ne choisissiez de spécifier un schéma de table de contrôle dans vos réglages de tâches AWS DMS, la table awsdms_apply_exceptions est créée par défaut dans le schéma public.

Quand l'outil AWS DMS a enregistré la transaction dans le journal, il termine l'application de toutes les transactions de ce lot. AWS DMS repasse ensuite en mode Application par lot. Un message semblable au suivant s'affiche dans vos journaux :

« [TARGET_APPLY ]I: Revenir au mode application en bloc (bulk_apply.c:4751). »

Les modifications transactionnelles que vous exécutez à partir d'une base de données de traitement des transactions en ligne (OLTP) peuvent impacter les performances d'Amazon Redshift. Lorsque l'action Application par lot échoue, AWS DMS passe en mode traitement unitaire. La latence cible augmente pendant qu’AWS DMS exécute les transactions en mode traitement unitaire. Quand AWS DMS repasse en mode Application en bloc, la latence cible diminue.

Pour résoudre ce problème, connectez-vous à la cible Amazon Redshift. Exécutez ensuite la commande suivante pour obtenir le résultat de la table awsdms_apply_exceptions, afin d'identifier la requête à l'origine de l'échec du lot :

select \* from public.awsdms\_apply\_exceptions order by 4 desc;

Une fois que vous avez identifié la requête à l'origine de l'échec du lot, vérifiez l'erreur. Résolvez le problème afin que les tâches ne passent pas en mode traitement unitaire.

Informations connexes

Débogage des migrations AWS DMS : que faire en cas de problème ?

Utilisation d'une base de données Amazon Redshift comme cible pour AWS Database Migration Service

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 7 mois