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.
Comprendre la politique de nouvelle tentative avec le chauffeur sur Amazon QLDB
Important
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez Migrer un Amazon QLDB Ledger vers Amazon Aurora SQL Postgre
Le QLDB pilote Amazon utilise une politique de nouvelle tentative pour gérer les exceptions transitoires en réessayant de manière transparente une transaction ayant échoué. Ces exceptions, telles que CapacityExceededException etRateExceededException, se corrigent généralement d'elles-mêmes après un certain temps. Si la transaction qui a échoué avec l'exception est réessayée après un délai approprié, elle a de fortes chances de réussir. Cela permet d'améliorer la stabilité de l'application qui l'utiliseQLDB.
Types d'erreurs réessayables
Le chauffeur réessaie automatiquement une transaction si et seulement si l'une des exceptions suivantes se produit au cours d'une opération dans le cadre de cette transaction :
-
CapacityExceededException— Renvoyé lorsque la demande dépasse la capacité de traitement du registre.
-
InvalidSessionException— Renvoyé lorsqu'une session n'est plus valide ou si elle n'existe pas.
-
LimitExceededException— Renvoie si une limite de ressources, telle que le nombre de sessions actives, est dépassée.
-
OccConflictException— Renvoyé lorsqu'une transaction ne peut pas être écrite dans le journal en raison d'un échec lors de la phase de vérification du contrôle de simultanéité optimiste (OCC).
-
RateExceededException— Renvoyé lorsque le taux de demandes dépasse le débit autorisé.
Politique de nouvelle tentative par défaut
La politique de nouvelle tentative consiste en une condition de nouvelle tentative et une stratégie d'interruption. La condition de nouvelle tentative définit le moment où une transaction doit être réessayée, tandis que la stratégie d'interruption définit le temps d'attente avant de réessayer la transaction.
Lors de la création d'une instance du pilote, la politique de réessai par défaut indique de réessayer jusqu'à quatre fois et d'utiliser une stratégie de réduction exponentielle. La stratégie de réduction exponentielle utilise un délai minimum de 10 millisecondes et un délai maximum de 5 000 millisecondes, avec une instabilité égale. Si la transaction ne peut pas être validée avec succès dans le cadre de la politique de nouvelle tentative, nous vous recommandons de réessayer la transaction à un autre moment.
Le concept du recul exponentiel consiste à utiliser des temps d'attente de plus en plus longs entre les tentatives pour des réponses d'erreur consécutives. Pour plus d'informations, consultez le billet de AWS blog Exponential Backoff and Jitter
