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 dans Aurora DSQL

Résolution des problèmes liés aux erreurs de connexion

erreur : code d'erreur SSL non reconnu : 6 ou impossible d'accepter la connexion, le SNI n'a pas été reçu

Vous utilisez peut-être une version de psql antérieure à la version 14, qui ne prend pas en charge l'indication du nom du serveur (SNI). Le SNI est requis lors de la connexion à Aurora DSQL.

Vous pouvez vérifier votre version client avec psql --version.

erreur : NetworkUnreachable

Une erreur NetworkUnreachable lors des tentatives de connexion peut indiquer que votre client ne prend pas en charge les connexions IPv6, au lieu de signaler un problème réseau réel. Cette erreur se produit fréquemment sur les IPv4-only instances en raison de la façon dont les clients PostgreSQL gèrent les connexions à double pile. Lorsqu’un serveur prend en charge le mode double pile, ces clients résolvent d’abord les noms d’hôte en adresses IPv4 et IPv6. Ils tentent d’abord une connexion IPv4, puis essayent IPv6 en cas d’échec de la connexion initiale. Si votre système ne prend pas en charge IPv6, vous verrez une erreur NetworkUnreachable générale au lieu d’un message clair « IPv6 non pris en charge ».

Résolution des erreurs liées à l’authentification

L’authentification IAM a échoué pour l’utilisateur « ... »

Lorsque vous générez un jeton d’authentification IAM Aurora DSQL, la durée maximale que vous pouvez définir est d’une semaine. Au bout d’une semaine, vous ne pourrez plus vous authentifier avec ce jeton.

En outre, Aurora DSQL rejette votre demande de connexion si le rôle que vous avez endossé a expiré. Par exemple, si vous essayez de vous connecter avec un rôle IAM temporaire même si votre jeton d’authentification n’a pas expiré, Aurora DSQL rejettera la demande de connexion.

Pour plus d’informations sur le fonctionnement d’IAM avec Aurora DSQL, consultez Comprendre l’authentification et l’autorisation pour Aurora DSQL et Gestion des identités et des accès AWS dans Aurora DSQL.

Une erreur s'est produite (InvalidAccessKeyId) lors de l'appel de l' GetObjectopération : l'ID de clé d' AWS accès que vous avez fourni n'existe pas dans nos dossiers

IAM a rejeté votre demande. Pour plus d’informations, consultez Pourquoi les demandes sont-elles signées.

Le rôle IAM <role> n’existe pas

Aurora DSQL n’a pas pu trouver votre rôle IAM. Pour en savoir plus, consultez Rôles IAM.

Le rôle IAM doit ressembler à un ARN IAM

Pour plus d’informations, consultez Identifiants IAM - ARN IAM.

Mappage entre un utilisateur et une action erronés

Cette erreur se produit lorsque le type de jeton d'authentification ne correspond pas au rôle de base de données. Aurora DSQL utilise deux types de jetons : DbConnectAdmin pour le admin rôle et DbConnect pour les rôles de base de données personnalisés.

Résolution des erreurs liées à l’autorisation

Rôle <role> non pris en charge

Aurora DSQL ne prend pas en charge cette opération GRANT. Consultez la section Sous-ensembles de commandes SQL pris en charge dans Aurora DSQL.

Impossible d’établir une approbation avec le rôle <role>

Aurora DSQL ne prend pas en charge cette opération GRANT. Consultez la section Sous-ensembles de commandes SQL pris en charge dans Aurora DSQL.

Le rôle <role> n’existe pas

Aurora DSQL n’a pas pu trouver l’utilisateur de base de données spécifié. Consultez Autoriser les rôles de base de données personnalisés à se connecter à un cluster.

ERREUR : autorisation refusée pour accorder l’approbation IAM avec le rôle <role>

Pour accorder l’accès à un rôle de base de données, vous devez être connecté à votre cluster avec le rôle d’administrateur. Pour plus d’informations, consultez Autoriser les rôles de base de données à utiliser SQL dans une base de données.

ERREUR : le rôle <role> doit avoir l’attribut LOGIN

Tous les rôles de base de données que vous créez doivent disposer de l’autorisation LOGIN.

Pour corriger cette erreur, assurez-vous d'avoir créé le rôle PostgreSQL avec l'LOGINautorisation requise. Pour plus d’informations, consultez CREATE ROLE et ALTER ROLE dans la documentation de PostgreSQL.

ERREUR : le rôle <role> ne peut pas être supprimé, car certains objets en dépendent

Aurora DSQL renvoie une erreur si vous supprimez un rôle de base de données avec une relation IAM jusqu’à ce que vous révoquiez la relation en utilisant AWS IAM REVOKE. Pour plus d’informations, consultez Révocation de l’autorisation.

Résolution des erreurs SQL

Erreur : non pris en charge

Aurora DSQL ne prend pas en charge tous les PostgreSQL-based dialectes. Pour plus d’informations sur les fonctionnalités prises en charge, consultez Fonctionnalités PostgreSQL prises en charge dans Aurora DSQL.

Erreur : utiliser CREATE INDEX ASYNC à la place

Pour créer un index sur une table contenant des lignes existantes, vous devez utiliser la commande CREATE INDEX ASYNC. Pour plus d’informations, consultez Création d’index de manière asynchrone dans Aurora DSQL.

Erreur : serveur non disponible (SQLSTATE XX000)

Une erreur d'indisponibilité du serveur indique une condition de service temporaire. Votre connexion reste active, vous pouvez donc réessayer sans vous reconnecter.

Réessayez toujours l'intégralité de la transaction depuis le début, y compris la COMMIT commande, avec un retard et une instabilité exponentiels.

Concevez les transactions de manière à ce qu'elles soient idempotentes lorsque cela est possible. Pour les transactions non idempotentes, vérifiez si Aurora DSQL a appliqué l'écriture avant de réessayer la transaction.

Surveillez le taux d'erreurs d'indisponibilité du serveur. Attendez-vous à de nouvelles tentatives de temps en temps. Si les erreurs persistent ou affectent les performances de l'application, contactez le AWS support.

Résolution des problèmes liés aux réponses au contrôle de simultanéité

OC000 « ERREUR : une modification entre en conflit avec une autre transaction (OC000) »

Cette transaction a tenté de modifier les mêmes tuples qu'une autre transaction simultanée. Cela indique une controverse sur les tuples modifiés. Pour en savoir plus, reportez-vous à la section Contrôle de simultanéité dans Aurora DSQL.

OC001 « ERREUR : le schéma a été mis à jour par une autre transaction (OC001) »

Votre session contenait une copie en cache du catalogue de schémas à la version V1, chargée à l'instant T1.

Une transaction distincte a mis à jour le catalogue vers la version V2 au moment T2.

À l'instant T3, lorsque votre session exécute une requête, elle détecte qu'elle est en retard et tente de se rebaser sur les nouvelles modifications du catalogue. Dans certains cas, le rebasage échoue et Aurora DSQL renvoie une réponse 40001 OC001. Le temps entre T2 et T3 peut aller de quelques millisecondes à quelques minutes, car les processeurs de requêtes détectent les modifications du catalogue de manière réactive au lieu de recevoir des mises à jour proactives.

Lorsque vous réessayez à partir de la même session, Aurora DSQL actualise le cache du catalogue. La nouvelle transaction utilise le catalogue V2 et aboutit tant qu'aucune autre modification du catalogue n'est intervenue depuis T2.

Résolution des problèmes de SSL/TLS connexion

Erreur SSL : échec de la vérification du certificat

Cette erreur indique que le client ne peut pas vérifier le certificat du serveur. Assurez-vous que :

Code d’erreur SSL non reconnu : 6

Cette erreur se produit avec les clients PostgreSQL antérieurs à la version 14. Mettez à niveau votre client PostgreSQL vers la version 17 pour résoudre ce problème.

Erreur SSL : schéma non enregistré (Windows)

Il s’agit d’un problème connu lié au client Windows psql lors de l’utilisation de certificats système. Utilisez la méthode du fichier de certificat téléchargé décrite dans les instructions Connexion depuis Windows.

Résolution des problèmes liés aux métriques manquantes dans la console Amazon CloudWatch Database Insights

Le cluster Aurora DSQL n'apparaît pas dans la console Amazon CloudWatch Database Insights

Amazon CloudWatch Database Insights remplit son sélecteur de cluster à l'aide des données d'activité issues des analyses de la base de données Aurora DSQL. Pour plus d'informations sur les informations sur les bases de données Aurora DSQL, consultezSurveillance des clusters Aurora DSQL avec Aurora DSQL Database Insights. Un cluster n'est visible dans Database Insights qu'après avoir généré une charge capturée par l'échantillonneur DASH (Active Session History) Aurora DSQL au cours des huit derniers jours.

DASH utilise un échantillonnage d'une seconde, qui peut manquer des transactions rapides et peu fréquentes qui se terminent en quelques millisecondes.

Procédez comme suit pour vérifier si cela explique ce que vous voyez :