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. # Gestion des erreurs avec DynamoDB Cette section décrit les erreurs d’exécution et la façon de les traiter. Elle décrit également les messages d’erreur et les codes spécifiques d’Amazon DynamoDB. Pour obtenir la liste des erreurs courantes qui s'appliquent à tous les AWS services, voir [Gestion des accès](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/CommonErrors.html) **Topics** + [Composants erreur](#Programming.Errors.Components) + [Erreurs transactionnelles](#Programming.Errors.TransactionalErrors) + [Codes et messages d’erreur](#Programming.Errors.MessagesAndCodes) + [Gestion des erreurs dans votre application](#Programming.Errors.Handling) + [Nouvelles tentatives après erreur et backoff exponentiel](#Programming.Errors.RetryAndBackoff) + [Opérations par lot et gestion des erreurs](#Programming.Errors.BatchOperations) ## Composants erreur Quand votre programme envoie une demande, DynamoDB tente de la traiter. Si la demande aboutit, DynamoDB renvoie un code d’état HTTP de succès (`200 OK`), ainsi que les résultats de l’opération demandée. Si la demande échoue, DynamoDB renvoie une erreur. Chaque erreur possède trois composants : + Un code d’état HTTP (`400`, par exemple). + Un nom d’exception (`ResourceNotFoundException`, par exemple). + Un message d’erreur (`Requested resource not found: Table: tablename not found`, par exemple). AWS SDKs Prenez soin de propager les erreurs dans votre application afin que vous puissiez prendre les mesures appropriées. Par exemple, dans un programme Java, vous pouvez écrire une logique `try-catch` de façon à gérer un `ResourceNotFoundException`. Si vous n'utilisez pas de AWS SDK, vous devez analyser le contenu de la réponse de bas niveau de DynamoDB. Voici un exemple de réponse. ``` HTTP/1.1 400 Bad Request x-amzn-RequestId: LDM6CJP8RMQ1FHKSC1RBVJFPNVV4KQNSO5AEMF66Q9ASUAAJG Content-Type: application/x-amz-json-1.0 Content-Length: 240 Date: Thu, 15 Mar 2012 23:56:23 GMT {"__type":"com.amazonaws.dynamodb.v20120810#ResourceNotFoundException", "message":"Requested resource not found: Table: tablename not found"} ``` ## Erreurs transactionnelles Pour plus d’informations sur les erreurs transactionnelles, veuillez consulter [Gestion des conflits de transactions dans DynamoDB](transaction-apis.md#transaction-conflict-handling) ## Codes et messages d’erreur Voici la liste des exceptions renvoyées par DynamoDB, regroupées par code d’état HTTP. Si *OK to retry?* a pour réponse *Yes*, vous pouvez soumettre à nouveau la même demande. Si *OK to retry?* a pour réponse *No*, vous devez résoudre le problème côté client avant de soumettre une nouvelle demande. ### Code d’état HTTP 400 Un code d’état HTTP `400` indique un problème avec votre demande, tel qu’un échec d’authentification, l’absence de paramètres requis ou le dépassement du débit provisionné d’une table. Vous devez corriger le problème dans votre application avant de soumettre à nouveau la demande. **AccessDeniedException ** Message : *Accès refusé.* Le client n’a pas signé correctement la demande. Si vous utilisez un kit AWS SDK, les demandes sont signées automatiquement ; sinon, accédez au [Processus de signature Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) dans le *Références générales AWS*. OK pour réessayer ? Non **ConditionalCheckFailedException** Message : *Échec de la demande conditionnelle. * Vous avez spécifié une condition qui a été analysée comme false. Par exemple, il se peut que vous avez essayé d’effectuer une mise à jour conditionnelle sur un élément, mais que la valeur réelle de l’attribut ne corresponde pas à la valeur attendue de la condition. OK pour réessayer ? Non **IncompleteSignatureException** Message : *La signature de la demande n’est pas conforme aux normes AWS .* La signature de la demande ne comprenait pas tous les composants requis. Si vous utilisez un AWS SDK, les demandes sont signées automatiquement ; sinon, passez au [processus de signature Signature version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) dans le *Références générales AWS*. OK pour réessayer ? Non **ItemCollectionSizeLimitExceededException** Message : *Dépassement de taille de la collection.* Pour une table avec un index secondaire local, un groupe d’éléments avec la même valeur de clé de partition a dépassé la limite de taille maximum de 10 Go. Pour plus d’informations sur les collections d’éléments, consultez [Collections d’articles dans les index secondaires locaux](LSI.md#LSI.ItemCollections). OK pour réessayer ? Oui **LimitExceededException** Message : *Beaucoup trop d’opérations pour un abonné donné.* Il y a beaucoup trop d’opérations de contrôle simultanées. Le nombre cumulé de tables et d’index à l’état `CREATING`, `DELETING` ou `UPDATING` ne peut pas dépasser 500. OK pour réessayer ? Oui **MissingAuthenticationTokenException** Message : *La demande doit comporter un ID de clé d’accès AWS valide (inscrit).* La demande n’incluait pas l’en-tête d’autorisation obligatoire ou n’était pas correctement formée. Consultez [API de bas niveau de DynamoDB](Programming.LowLevelAPI.md). OK pour réessayer ? Non **ProvisionedThroughputExceededException** Message : *Vous avez dépassé le débit provisionné autorisé maximal pour une table ou pour un ou plusieurs index secondaires globaux. [Pour consulter les indicateurs de performance relatifs au débit provisionné par rapport au débit consommé, ouvrez la console Amazon. CloudWatch](https://console.aws.amazon.com/cloudwatch/home)* L’erreur inclut une liste de champs `ThrottlingReason` fournissant un contexte spécifique expliquant pourquoi la limitation s’est produite, en fonction du format `ResourceType+OperationType+LimitType` (par exemple, `TableReadProvisionedThroughputExceeded`) et de l’ARN de la ressource affectée. Cela vous permet d’identifier la ressource limitée (table ou index), le type d’opération qui a déclenché la limitation (lecture ou écriture) et la limite spécifique qui a été dépassée (dans ce cas, la capacité allouée). Pour plus d’informations sur le diagnostic et la résolution des problèmes de limitation, consultez [Diagnostic des problèmes de limitation](throttling-diagnosing-workflow.md). Exemple : votre taux de demandes est trop élevé. AWS SDKs Pour DynamoDB, réessayez automatiquement les demandes qui reçoivent cette exception. Votre demande finit par aboutir, à moins que la file d’attente des nouvelles tentatives soit trop grande pour être terminée. Réduisez la fréquence des demandes avec [Nouvelles tentatives après erreur et backoff exponentiel](#Programming.Errors.RetryAndBackoff). OK pour réessayer ? Oui **ReplicatedWriteConflictException** Message : *Un ou plusieurs éléments de cette demande sont modifiés par une demande dans une autre région.* Exemple : Une opération d’écriture a été demandée pour un élément d’une table globale multirégionale fortement cohérente (MRSC) qui est actuellement modifiée par une demande dans une autre région. OK pour réessayer ? Oui **RequestLimitExceeded** Message : *Throughput exceeds the current throughput limit for your account (le débit dépasse la limite de débit actuelle de votre compte). Pour demander une augmentation de limite, contactez le AWS Support à l'adresse [https://aws.amazon.com/support.](https://aws.amazon.com/support)* L’erreur inclut une liste de champs `ThrottlingReason` fournissant un contexte spécifique expliquant pourquoi la limitation s’est produite, en fonction du format `ResourceType+OperationType+LimitType` (par exemple, `TableWriteAccountLimitExceeded` ou `IndexReadAccountLimitExceeded`) et de l’ARN de la ressource affectée. Cela vous permet d’identifier quelle ressource est limitée (table ou index), quel type d’opération a déclenché la limitation (lecture ou écriture) et si vous avez dépassé les quotas de service au niveau du compte. Pour plus d’informations sur le diagnostic et la résolution des problèmes de limitation, consultez [Diagnostic des problèmes de limitation](throttling-diagnosing-workflow.md). Exemple : Le taux de demandes à la demande dépasse le débit autorisé du compte et la table ne peut pas être davantage mise à l’échelle. OK pour réessayer ? Oui **ResourceInUseException** Message : *La ressource que vous essayez de modifier est en cours d’utilisation. * Exemple : vous avez essayé de recréer une table existante ou de supprimer une table dont l’état est `CREATING`. OK pour réessayer ? Non **ResourceNotFoundException ** Message : *La ressource demandée est introuvable.* Exemple : la table demandée n’existe pas ou se trouve trop tôt dans l’état `CREATING`. OK pour réessayer ? Non **ThrottlingException** Message : *Le taux de demandes dépasse le débit autorisé.* Cette exception est renvoyée sous forme de AmazonServiceException réponse avec un code d'état THROTTLING\$1EXCEPTION. Cette exception peut être renvoyée si vous effectuez des opérations d’API de [plan de contrôle](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html#HowItWorks.API.ControlPlane) trop rapidement. Pour les tables utilisant le mode à la demande, cette exception peut être renvoyée pour toute opération d’API de [plan de données](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html#HowItWorks.API.DataPlane) si votre taux de demandes est trop élevé. Pour en savoir plus sur la mise à l’échelle à la demande, consultez [Débit initial et propriétés de mise à l’échelle](on-demand-capacity-mode.md#on-demand-capacity-mode-initial). L’erreur inclut une liste de champs `ThrottlingReason` fournissant un contexte spécifique expliquant pourquoi la limitation s’est produite, en fonction du format `ResourceType+OperationType+LimitType` (par exemple, `TableReadKeyRangeThroughputExceeded` ou `IndexWriteMaxOnDemandThroughputExceeded`) et de l’ARN de la ressource affectée. Ces informations vous permettent d’identifier la ressource limitée (table ou index), le type d’opération qui a déclenché la limitation (lecture ou écriture) et la limite spécifique qui a été dépassée (limites de partition ou débit maximum à la demande). Pour plus d’informations sur le diagnostic et la résolution des problèmes de limitation, consultez [Diagnostic des problèmes de limitation](throttling-diagnosing-workflow.md). OK pour réessayer ? Oui **UnrecognizedClientException** Message : *L’ID de clé d’accès ou le jeton de sécurité n’est pas valide.* La signature de la demande est incorrecte. La cause la plus probable est un identifiant de clé AWS d'accès ou une clé secrète non valide. OK pour réessayer ? Oui **ValidationException** Message : variable selon les erreurs spécifiques rencontrées Cette erreur peut se produire pour différentes raisons, telles qu’un paramètre obligatoire absent, une valeur en dehors des limites ou une incompatibilité des données. Le message d’erreur contient des détails sur la partie spécifique de la demande qui a provoqué l’erreur. OK pour réessayer ? Non ### Code d’état HTTP 5xx Un code d’état HTTP `5xx` indique un problème qui doit être résolu par AWS. Il peut s’agir d’une erreur temporaire, auquel cas vous pouvez retenter votre demande jusqu’à ce qu’elle aboutisse. Sinon, accédez à l’[AWS Service Health Dashboard](https://status.aws.amazon.com/) pour voir si le service rencontre des problèmes opérationnels. Pour plus d’informations, consultez l’article [Comment résoudre les erreurs HTTP 5xx dans Amazon DynamoDB ?](https://aws.amazon.com/premiumsupport/knowledge-center/dynamodb-http-5xx-errors/) **InternalServerError (HTTP 500)** DynamoDB n’a pas pu traiter votre demande. OK pour réessayer ? Oui Vous pouvez rencontrer des erreurs de serveur internes lorsque vous travaillez avec des éléments. Celles-ci sont attendues pendant la durée de vie d’une table. Toute demande en échec peut être relancée immédiatement. Lorsque vous recevez un code d’état 500 lors d’une opération d’écriture, l’opération peut avoir réussi ou échoué. Si l’opération d’écriture est une demande `TransactWriteItem`, il convient de réessayer l’opération. Si l'opération d'écriture est une demande d'écriture à élément unique`PutItem`, telle que`UpdateItem`, ou`DeleteItem`, alors votre application doit lire l'état de l'élément avant de recommencer l'opération, and/or [Exemple de commande CLI d’expression de condition DynamoDB](Expressions.ConditionExpressions.md) afin de s'assurer que l'élément reste dans un état correct après une nouvelle tentative, que l'opération précédente ait réussi ou échoué. Si l’idempotence est une exigence pour l’opération d’écriture, veuillez utiliser [`TransactWriteItem`](transaction-apis.md#transaction-apis-txwriteitems), qui prend en charge les demandes idempotentes en spécifiant automatiquement un `ClientRequestToken` pour désambiguïser plusieurs tentatives d’exécution de la même action. **ServiceUnavailable (HTTP 503)** DynamoDB est actuellement indisponible. (Il doit s’agir d’un état temporaire.) OK pour réessayer ? Oui ## Gestion des erreurs dans votre application Pour que votre application fonctionne correctement, vous devez ajouter une logique destinée à récupérer les erreurs et à y répondre. Les approches classiques incluent l’utilisation de blocs `try-catch` ou d’instructions `if-then`. Ils AWS SDKs effectuent leurs propres tentatives et vérifient les erreurs. Si vous rencontrez une erreur lors de l'utilisation de l'un d'entre eux AWS SDKs, le code d'erreur et sa description peuvent vous aider à résoudre le problème. Vous devez également voir un `Request ID` dans la réponse. Cela `Request ID` peut être utile si vous devez contacter le AWS Support pour diagnostiquer un problème. ## Nouvelles tentatives après erreur et backoff exponentiel Un grand nombre de composants d’un réseau, tels que serveurs DNS, commutateurs, équilibreurs de charge ou autres, peuvent générer des erreurs à n’importe quel moment de la vie d’une requête donnée. La technique habituelle pour traiter ces réponses erronées dans un environnement réseau consiste à implémenter les nouvelles tentatives dans l’application cliente. Cette technique augmente la fiabilité de l’application. Chaque AWS SDK implémente automatiquement une logique de nouvelle tentative. Vous pouvez modifier les paramètres de nouvelle tentative en fonction de vos besoins. Par exemple, imaginons une application Java nécessitant une politique d’interruption immédiate, sans autorisation de nouvelle tentative en cas d’erreur. Avec le AWS SDK pour Java, vous pouvez utiliser la `ClientConfiguration` classe et fournir une `maxErrorRetry` valeur de `0` pour désactiver les nouvelles tentatives. Pour plus d'informations, consultez la documentation du AWS SDK correspondant à votre langage de programmation. Si vous n'utilisez pas de AWS SDK, vous devez réessayer les demandes d'origine qui ont généré des erreurs de serveur (5xx). Cependant, les erreurs client (4xx, autres qu’une exception `ThrottlingException` ou `ProvisionedThroughputExceededException`) indiquent que vous avez besoin de réviser la demande elle-même pour résoudre le problème avant de recommencer. Pour obtenir des recommandations détaillées concernant des scénarios de limitation spécifiques, reportez-vous à la section de résolution des problèmes de limitation de [DynamoDB](TroubleshootingThrottling.md). Outre de simples tentatives, chaque AWS SDK implémente un algorithme de ralentissement exponentiel pour un meilleur contrôle du flux. Le concept sous-jacent vise à utiliser des temps d’attente progressivement plus longs entre les tentatives en cas de réponses d’erreur consécutives. Par exemple, jusqu’à 50 millisecondes avant la première nouvelle tentative, jusqu’à 100 millisecondes avant la deuxième, jusqu’à 200 millisecondes avant la troisième, et ainsi de suite. Cependant, après une minute, si la demande a échoué, le problème peut être que la taille de la demande entraîne un dépassement du débit provisionné, et ne pas être lié au taux de demandes. Définir le nombre maximal de nouvelles tentatives pour qu’elles s’arrêtent au bout d’une minute environ. Si la demande n’aboutit pas, examinez vos options de débit provisionné. **Note** Ils AWS SDKs implémentent une logique de nouvelle tentative automatique et un ralentissement exponentiel. La plupart des algorithmes de backoff exponentiel utilisent l’instabilité (retard aléatoire) pour éviter les conflits successifs. Comme vous ne cherchez pas à éviter de tels conflits dans ces cas-là, vous n’avez pas besoin d’utiliser ce nombre aléatoire. Cependant, si vous utilisez les clients simultanés, l’instabilité peut aider à ce que vos demandes réussissent plus rapidement. Pour plus d’informations, consultez le billet de blog sur [Exponential backoff and jitter](http://www.awsarchitectureblog.com/2015/03/backoff.html). ## Opérations par lot et gestion des erreurs L’API de bas niveau DynamoDB prend en charge les opérations par lot pour les lectures et les écritures. `BatchGetItem` lit les éléments d’une ou de plusieurs tables, et `BatchWriteItem` insère ou supprime des éléments dans une ou plusieurs tables. Ces opérations par lot sont implémentées sous la forme d’encapsuleurs autour des opérations DynamoDB autres que par lot. En d’autres termes, `BatchGetItem` appelle `GetItem` une fois pour chaque élément du lot. De même, `BatchWriteItem` invoque `DeleteItem` ou `PutItem`, le cas échéant, pour chaque élément du lot. Une opération par lot peut supporter la défaillance de requêtes individuelles dans le lot. Par exemple, imaginons une demande `BatchGetItem` de lecture de cinq éléments. Même si certaines demandes `GetItem` sous-jacentes échouent, il ne s’ensuit pas que l’ensemble de l’opération `BatchGetItem` échoue. Cependant, si les cinq opérations de lecture échouent, alors `BatchGetItem` échoue dans son intégralité. Les opérations par lot renvoient des informations sur les demandes individuelles qui échouent pour vous permettre de diagnostiquer le problème et de réessayer l’opération. Pour `BatchGetItem`, les tables et les clés primaires en question sont retournées dans la valeur `UnprocessedKeys` de la réponse. Pour `BatchWriteItem`, les informations similaires sont retournées dans `UnprocessedItems`. La cause la plus probable d’un échec en lecture ou en écriture est la *limitation*. Pour `BatchGetItem`, une ou plusieurs tables de la demande par lot n’ont pas une capacité en lecture suffisamment provisionnée pour prendre en charge l’opération. Pour `BatchWriteItem`, une ou plusieurs des tables n’ont pas une capacité en écriture suffisamment provisionnée. Si DynamoDB renvoie des éléments non traités, vous devez relancer l’opération par lot sur ces éléments. Cependant, *nous vous recommandons vivement d’utiliser un algorithme d’interruption exponentielle*. Si vous recommencez immédiatement l’opération par lot, les demandes en lecture ou en écriture sous-jacentes peuvent continuer à échouer en raison de la limitation sur les tables individuelles. Si vous retardez l’opération par lot à l’aide d’une interruption exponentielle, il est très vraisemblable que les demandes du lot réussiront. **Note** Certains AWS SDKs proposent des clients de niveau supérieur qui gèrent automatiquement les nouvelles tentatives d'articles non traités. Vous n'avez donc pas besoin d'implémenter vous-même cette logique de nouvelle tentative. Par exemple : **Java** [— Le client [DynamoDB amélioré](DynamoDBEnhanced.md) dans la version v2 et le DBMapper Dynamo dans AWS SDK pour Java la version v1 réessayent automatiquement les éléments non traités lors des opérations par lots.](DynamoDBMapper.md) **Python** — La ressource de table boto3 `batch_writer` gère implicitement les tentatives d'éléments non traités pour les opérations d'écriture par lots. Pour de plus amples informations, veuillez consulter [Utilisation de la ressource de table batch\$1writer](programming-with-python.md#programming-with-python-batch-writer). Si vous utilisez un client de bas niveau ou un SDK qui ne fournit pas ce comportement, vous devez implémenter vous-même la logique de nouvelle tentative, comme décrit ci-dessus.