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

Brève description

Lorsqu'une tâche AWS DMS échoue, les journaux de tâches fournissent des informations sur la cause de l'échec, notamment en envoyant des messages d'erreur (]E:) ou des messages d'avertissement (]W:). Dans certains cas, une tâche AWS DMS peut échouer sans erreurs ou avertissements, ce qui peut compliquer le dépannage de la cause. Le plus souvent, cela est dû à l'une des trois raisons suivantes :

1. Conflit de ressources sur l'instance de réplication

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

• Le processeur est nécessaire pour convertir le type de données source d'abord vers le type de données AWS DMS, enfin vers le type de données cible.
• La mémoire est nécessaire, 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 processeur et la mémoire sont également utilisés par le système de surveillance interne pour surveiller l'instance de réplication. Tout conflit sur le processeur ou la mémoire peut entraîner l'échec sans notification d'une tâche de migration.

2. Statut Plein du stockage sur l'instance de réplication

Si le stockage d'instance de réplication est plein, une tâche de migration peut échouer sans aucune notification d'erreur. Pour plus d'informations, consultez Pourquoi mon instance de réplication AWS DMS a-t-elle le statut stockage plein ?

3. Une erreur interne s'est produite

Les tâches AWS DMS peuvent également échouer sans notification s'il existe des erreurs internes invisibles dans les journaux de tâches qui sont journalisés par défaut.

Résolution

Commencez par vérifier l'heure de la dernière entrée dans les journaux de tâches après l'échec de la tâche sans notification. Ensuite, vérifiez l'utilisation du processeur, de la mémoire et du disque sur l'instance de réplication au même moment où la défaillance a été journalisée. 

La présence simultanée d'une faible valeur pour la métrique FreeableMemory et d'une valeur élevée pour la métrique SwapUsage est un indicateur d'un éventuel conflit de mémoire sur l'instance de réplication. Vous devez absolument vérifier les deux métriques. Pour plus d'informations, consultez la section Métriques Data Migration Service.

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

1. Ouvrez la console d'AWS DMS, puis choisissez Tâches de migration de base de données dans le volet de navigation.
2. Choisissez le nom de la tâche qui a échoué.
3. Notez le nom de l'instance de réplication dans la section Présentation des informations.
4. Choisissez Instances de réplication dans le panneau de navigation.
5. Choisissez le nom de l'instance de réplication noté à l'étape 3.
6. Dans la section Métriques de la tâche de migration vous pouvez afficher les métriques CPUUtilization, SwapUsage, FreeableMemory,et FreeStorageSpace.
7. Pour afficher plus de détails, passez la souris sur la métrique et choisissez l'icône d'accès à plus d'options (trois points verticaux).
8. Choisissez Afficher dans la métrique.

Cette action ouvre la console CloudWatch dans laquelle vous pouvez afficher l'utilisation de la métrique au moment où la tâche a échoué.

Si vous constatez des conflits permanents entre le processeur et la mémoire, pensez à réduire le nombre de tâches en cours d'exécution sur l'instance de réplication. Vous pouvez le faire de deux façons, notamment en lançant de nouvelles instances de réplication et en répartissant les tâches entre plusieurs instances de réplication. Vous pouvez également envisager la mise à l'échelle de l'instance de réplication vers un type d'instance plus grand.

Remarque : les instances T2 fournissent des performances de base après l'épuisement des crédits UC. Par exemple, une micro-instance T2 fournit des performances de référence de 10 %. Pour cette raison, prenez en compte le type d'instance utilisé et vérifiez l'utilisation du processeur en conséquence. Pour plus d'informations sur les crédits de processeur et les performances de référence, consultez Crédits de processeur et performances de référence pour les instances à capacité extensible.

Redémarrez la tâche une fois que vous avez identifié la source de l'échec sans notification. 

S'il n'y a pas de conflit sur le processeur, la mémoire ou l'espace disque, c'est que la tâche a très probablement échoué en raison d'une erreur interne. Pour résoudre les erreurs internes, activez le débogage détaillé sur tous les cinq composants de journal. Une fois que le débogage détaillé est activé, redémarrez la tâche et examinez les journaux de la tâche pour identifier la raison de l'échec de la tâche.

---

Informations connexes

Dépannage des tâches de migration dans AWS Database Migration Service

Choix de la taille optimale pour une instance de réplication