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 **Note** Les rubriques suivantes fournissent des conseils de dépannage pour les erreurs et les problèmes que vous pouvez rencontrer en utilisant Aurora DSQL. Si vous rencontrez un problème qui n’est pas répertorié ici, contactez le support AWS **Topics** + [Résolution des problèmes liés aux erreurs de connexion](#troubleshooting-connections) + [Résolution des erreurs liées à l’authentification](#troubleshooting-authentication) + [Résolution des erreurs liées à l’autorisation](#troubleshooting-authorization) + [Résolution des erreurs SQL](#troubleshooting-sql) + [Résolution des problèmes liés aux réponses au contrôle de simultanéité](#troubleshooting-occ) + [Résolution des problèmes de SSL/TLS connexion](#troubleshooting-ssl-tls) + [Résolution des problèmes liés aux métriques manquantes dans la console Amazon CloudWatch Database Insights](#troubleshooting-database-insights) ## 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](https://www.postgresql.org/docs/release/14.0/), 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](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/authentication-authorization.html) et [Gestion des identités et des accès AWS dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam.html). **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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html#why-requests-are-signed). **Le rôle IAM n’existe pas** Aurora DSQL n’a pas pu trouver votre rôle IAM. Pour en savoir plus, consultez [Rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html). **Le rôle IAM doit ressembler à un ARN IAM** Pour plus d’informations, consultez [Identifiants IAM - ARN IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns). **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. + Si vous voyez`Wrong user to action mapping. user: admin, action: DbConnect`, utilisez à la `generate-db-connect-admin-auth-token` place de`generate-db-connect-auth-token`. + Si vous voyez`Wrong user to action mapping. user: {{myusername}}, action: DbConnectAdmin`, utilisez à la `generate-db-connect-auth-token` place de`generate-db-connect-admin-auth-token`. ## Résolution des erreurs liées à l’autorisation **Rôle 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 ](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-sql-subsets.html) DSQL. **Impossible d’établir une approbation avec le rôle ** Aurora DSQL ne prend pas en charge cette opération `GRANT`. Consultez la section Sous-ensembles de commandes SQL pris en [ charge dans Aurora ](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-sql-subsets.html) DSQL. **Le rôle 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](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/using-database-and-iam-roles.html#using-database-and-iam-roles-custom-database-roles). **ERREUR : autorisation refusée pour accorder l’approbation IAM avec le rôle ** 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](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/using-database-and-iam-roles.html#using-database-and-iam-roles-custom-database-roles-sql). **ERREUR : le rôle 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'`LOGIN`autorisation requise. Pour plus d’informations, consultez [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) et [ALTER ROLE](https://www.postgresql.org/docs/current/sql-alterrole.html) dans la documentation de PostgreSQL. **ERREUR : le rôle 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](authentication-authorization.md#authentication-authorization-revoke). ## 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](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-sql-features.html). **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](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-create-index-async.html). ### 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. **Résultat d'engagement incertain** Si l'erreur se produit lors de la validation d'une transaction, celle-ci a peut-être été validée même si votre application a reçu une erreur. 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 ](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-concurrency-control.html) 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 : 1. Le certificat Amazon Root CA 1 est correctement installé. Consultez [Configuration des SSL/TLS certificats pour les connexions Aurora DSQL](configure-root-certificates.md) pour savoir comment valider et installer ce certificat. 1. La variable d’environnement `PGSSLROOTCERT` pointe vers le bon fichier de certificat. 1. Le fichier de certificat dispose des autorisations adéquates. **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](configure-root-certificates.md#connect-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, consultez[Surveillance des clusters Aurora DSQL avec Aurora DSQL Database Insights](dsql-db-insights.md). 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 : 1. Vérifiez que vous avez effectué des transactions sur le cluster au cours des huit derniers jours. Un cluster inactif depuis plus longtemps n'apparaît pas dans Database Insights, quelle que soit la façon dont vous l'avez utilisé précédemment. Pour vérifier l'activité récente, consultez la `TotalTransactions` métrique de votre cluster dans CloudWatch. Pour plus d’informations sur cette métrique, consultez [Observabilité et performance](cloudwatch-monitoring.md#observability-performance). 1. Exécutez une charge de travail soutenue sur le cluster afin qu'au moins une session reste active. Les exemples incluent un script de test de charge, un lot d'inserts ou une requête de longue durée. Étant donné que DASH échantillonne une fois par seconde, il est possible qu'une brève charge de travail ne soit pas capturée. Par conséquent, plus l'activité est continue, plus elle a de chances d'apparaître. 1. Attendez quelques minutes après avoir exécuté cette charge de travail, puis actualisez la console Database Insights. 1. Vérifiez que vous visualisez la même AWS région et le même compte que ceux dans lesquels le cluster a été créé. La sélection de la mauvaise région ou du mauvais compte est l'une des raisons courantes pour lesquelles un cluster semble absent.