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.

Dépannage de l’API de données Amazon RDS

Utilisez les sections suivantes, dont le titre correspond aux messages d’erreur courants, pour vous aider à résoudre les problèmes que vous rencontrez avec l’API de données Amazon RDS (API de données).

Transaction <transaction_ID> isn’t found

Dans ce cas, l’ID de transaction spécifié dans un appel de l’API de données est introuvable. La cause de ce problème, parmi les suivantes, est ajoutée au message d’erreur :

Pour plus d’informations sur l’exécution des transactions, consultez Appel de l’API de données Amazon RDS.

Packet for query is too large

Dans ce cas, le jeu de résultats renvoyé pour une ligne était trop volumineux. La taille de l’API de données ne doit pas dépasser 64 Ko par ligne dans le jeu de résultat renvoyé par la base de données.

Pour résoudre ce problème, assurez-vous que la taille de chaque ligne d’un jeu de résultat est inférieure ou égale à 64 Ko.

Database Response Exceeded Size Limit

Dans ce cas, la taille du jeu de résultat renvoyé par la base de données était trop grande. La limite de l’API de données est de 1 Mio dans le jeu de résultats renvoyé par la base de données.

Pour résoudre ce problème, assurez-vous que les appels à l’API de données renvoient au maximum 1 Mio. Si vous avez besoin de renvoyer plus de 1 Mio, vous pouvez utiliser plusieurs appels ExecuteStatement avec la clause LIMIT dans votre requête.

Pour plus d’informations sur la clause LIMIT, consultez Syntaxe SELECT dans la documentation de MySQL.

HttpEndpointn'est pas activé pour le cluster <cluster_ID>

Vérifiez les causes potentielles suivantes de ce problème :

DatabaseErrorException: La transaction exécute toujours une requête

Lorsque votre application envoie une demande avec un ID de transaction qui exécute déjà une autre requête, l’API de données renvoie immédiatement cette erreur à votre application. Cette situation peut se produire si votre application envoie des demandes de façon asynchrone, par exemple à l’aide d’un mécanisme comme les « promesses » en Javascript.

Pour résoudre ce problème, attendez que la demande précédente soit terminée, puis réessayez. Vous pouvez répéter la tentative jusqu’à ce que l’erreur disparaisse ou qu’un autre type d’erreur soit renvoyé à l’application.

Cette condition peut se produire avec l’API de données pour Aurora Serverless v2 et les instances provisionnées. Dans l’API de données pour Aurora Serverless v1, les demandes envoyées avec le même ID de transaction sont mises en attente jusqu’à ce que la précédente soit terminée. Cependant, cet ancien comportement peut entraîner des délais d’expiration si la demande précédente met trop de temps à s’exécuter. Si vous migrez une ancienne application d’API de données qui envoie des demandes simultanées, adaptez votre logique de gestion des exceptions afin de prendre en compte ce nouveau type d’erreur.

Exception de résultat non pris en charge

L’API de données ne prend pas en charge tous les types de données. Cette erreur se produit lorsque vous exécutez une requête qui renvoie un type de données non pris en charge.

Pour contourner ce problème, convertissez le type de données non pris en charge en TEXT. Par exemple :

SELECT custom_type::TEXT FROM my_table;
-- OR
SELECT CAST(custom_type AS TEXT) FROM my_table;

Les instructions multiples ne sont pas prises en charge

Les instructions multiples ne sont pas prises en charge dans l’API de données pour Aurora sans serveur v2 et les clusters provisionnés. Toute tentative d’exécuter plusieurs instructions dans un seul appel d’API entraîne cette erreur.

Pour exécuter des instructions multiples, utilisez des appels d’API ExecuteStatement distincts ou utilisez l’API BatchExecuteStatement pour le traitement par lots.

Le paramètre de schéma n’est pas pris en charge

Aurora sans serveur v1 ignore silencieusement le paramètre de schéma. Cependant, Aurora sans serveur v2 et les clusters provisionnés rejettent explicitement les appels d’API contenant le paramètre de schéma.

Pour résoudre ce problème, supprimez le paramètre de schéma de tous les appels à l’API de données lorsque vous utilisez Aurora sans serveur v2 ou des clusters provisionnés.

IPv6 problèmes de connectivité

Si vous rencontrez des problèmes lors de la connexion à l'API de données à l'aide de IPv6 points de terminaison, vérifiez les causes potentielles suivantes :

Pour résoudre les problèmes de IPv6 connectivité, procédez comme suit :