Pourquoi ma tâche AWS DMS a-t-elle échoué sans message d’erreur ?

Brève description

Lorsqu’une tâche AWS DMS échoue, une entrée est créée dans le journal des tâches. Le journal des tâches fournit des informations sur la cause de l’échec sous forme de messages d’erreur (]E:) ou de messages d’avertissement (]W:). Dans certains cas, une tâche AWS DMS peut échouer sans message d’erreur ou d’avertissement, ce qui complique la résolution du problème.

Le plus souvent, la tâche AWS DMS échoue pour l’une des raisons suivantes :

Conflit de ressources sur l’instance de réplication

Le processeur et la mémoire sont les deux ressources les plus importantes requises pour une tâche de migration :

• Le processeur doit d’abord convertir le type de données source en type AWS DMS, puis en type de données cible.
• La mémoire est requise, car AWS DMS crée des flux vers la source et la cible. AWS DMS stocke les informations dans les tampons de flux en mémoire sur l’instance de réplication.

Le système de surveillance interne utilise également le processeur et la mémoire pour surveiller l’instance de réplication. Tout conflit au niveau du processeur ou de la mémoire peut donc entraîner l’échec sans message d’erreur d’une tâche de migration.

État de stockage plein sur l’instance de réplication

Si le stockage de l’instance de réplication est plein, une tâche de migration peut échouer sans message d’erreur.

Une erreur interne s’est produite

Les tâches AWS DMS peuvent également échouer sans message d’erreur en cas d’erreurs internes. Les erreurs internes ne sont pas visibles dans les journaux de tâches qui sont enregistrés par défaut.

Résolution

Remarque : si votre tâche utilise un système de gestion de base de données non relationnelle, il peut être préférable de l’exécuter sans paramètres parallèles. Pour en savoir plus, consultez la page Paramètres des tâches de métadonnées cibles.

Consultez vos journaux DMS, source et cible pour obtenir plus d’informations. Vérifiez l’heure de la dernière entrée dans les journaux de tâches après l’échec sans message de la tâche. Examinez ensuite l’utilisation du processeur, de la mémoire et du disque sur l’instance de réplication au moment où l’échec a été enregistré.

Si vous constatez une combinaison de FreeableMemory faible et de SwapUsage élevé, il est possible qu’un conflit de mémoire existe sur l’instance de réplication. Pour en savoir plus, consultez Métriques AWS Database Migration Service.

Pour consulter les métriques CloudWatch, procédez comme suit :

1. Ouvrez la console AWS DMS.
2. Dans le volet de navigation, sélectionnez Tâches de migration de base de données.
3. Choisissez le nom de la tâche qui a échoué.
4. Dans la section Détails de présentation, notez le nom de l’instance de réplication.
5. Dans le volet de navigation, sélectionnez Instances de réplication.
6. Choisissez le nom de l’instance de réplication que vous avez noté.
7. Dans la section Métriques de tâche de migration, passez en revue les métriques CPUUtilization, SwapUsage, FreeableMemory et FreeStorageSpace.
8. Pour afficher plus de détails, passez le curseur sur une métrique et cliquez sur l’icône « Plus d’options ».
9. Choisissez Afficher dans les métriques. Cette action déclenche l’ouverture de la console CloudWatch.

Dans la console CloudWatch, consultez l’utilisation de la métrique au moment de l’échec de la tâche.

Si vous constatez un conflit constant au niveau du processeur ou de la mémoire, réduisez le nombre de tâches exécutées sur l’instance de réplication. Pour réduire le nombre de tâches, vous pouvez lancer de nouvelles instances de réplication et répartir les tâches entre plusieurs instances de réplication. Vous pouvez également augmenter verticalement l’instance de réplication en passant à un type d’instance plus important.

Remarque : les instances T2 fournissent des performances de base une fois les crédits CPU épuisés. Par exemple, une instance T2.micro fournit une performance de base de 10 %. Vous devez tenir compte du type d’instance lorsque vous examinez l’utilisation du processeur. Pour en savoir plus, consultez la page Concepts et définitions clés pour les instances à performances extensibles.

Une fois la cause de l’échec sans message d’erreur identifiée, redémarrez la tâche. S’il n’y a pas de conflit au niveau du processeur, de la mémoire ou de l’espace disque, la tâche a probablement échoué en raison d’une erreur interne. Pour résoudre les erreurs internes, activez le débogage détaillé. Examinez les journaux générés avant l’erreur, puis activez le débogage détaillé pour les journaux associés. Par exemple, si les derniers journaux proviennent de TARGET_APPLY, activez le débogage détaillé pour SORTER, TARGET_APPLY. Une fois le débogage détaillé activé, redémarrez la tâche, puis consultez les journaux de tâches pour identifier la raison de son échec.

Remarque : le problème peut-être lié à des problèmes de validation, plutôt qu’à vos données. Pour savoir si la validation est la cause de votre problème, exécutez une tâche de validation uniquement pour voir si le problème se produit.

Informations connexes

Résolution des problèmes liés aux tâches de migration dans AWS Database Migration Service

Comment puis-je obtenir un support technique auprès d’AWS ?

Pourquoi mon instance de base de données de réplication AWS DMS présente-t-elle le statut Stockage plein ?