View a markdown version of this page

Délai d'expiration des transactions dans Amazon Aurora MySQL - Amazon Aurora
Détails des paramètresComportement en cas d'expirationExemplesRemarques principalesErreur du clientJournal des erreursSurveillance des délais d'expiration des transactionsInteraction avec d'autres timeouts

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élai d'expiration des transactions dans Amazon Aurora MySQL

Le aurora_transaction_timeout paramètre définit la durée maximale d'une transaction. Ce paramètre peut aider à empêcher les transactions de longue durée (actives ou inactives) de bloquer la purge d'InnoDB, ce qui peut entraîner des problèmes de performances. Ce paramètre est disponible dans les versions 8.4.8 et supérieures d'Aurora MySQL.

Détails des paramètres

Le aurora_transaction_timeout paramètre met fin à toute transaction InnoDB dont la durée dépasse la durée spécifiée, y compris les transactions en lecture seule. Vous spécifiez la valeur en secondes. La valeur zéro (valeur par défaut) désactive le délai d'attente.

Le tableau suivant récapitule les détails des paramètres.

Propriété Value
Nom aurora_transaction_timeout
Scope Séance mondiale
Par défaut 0 (désactivé)
Unit Secondes
Répartition dynamique Oui, s'applique uniquement aux nouvelles transactions InnoDB

Vous pouvez définir le aurora_transaction_timeout paramètre au niveau du cluster, de l'instance ou de la session. Pour plus d'informations sur l'utilisation des groupes de paramètres, consultezGroupes de paramètres pour Amazon Aurora.

Comportement en cas d'expiration

Le aurora_transaction_timeout paramètre s'applique aux transactions InnoDB qui exécutent des instructions DML, y compris les transactions en lecture seule. Toutes les instructions de validation implicites, à l'exception de CREATE TABLE .. AS SELECT (CTAS) etLOAD DATA, sont exclues du délai d'attente. La valeur du délai d'attente est capturée lors de l'exécution de la première instruction InnoDB. La valeur reste fixe pendant toute la durée de cette transaction.

À l'expiration du délai, le résultat dépend de l'état de la transaction :

  • Si une requête est active dans la transaction, celle-ci est interrompue et la transaction est annulée. La connexion reste utilisable.

  • S'il n'y a pas de requête active (c'est-à-dire si la transaction est inactive), la connexion est interrompue.

Exemples

Les exemples suivants montrent à quel moment le chronomètre démarre pour différents scénarios de transaction.

Transaction explicite

BEGIN;                    -- Does NOT start InnoDB transaction. No timer.
SELECT * FROM t1;         -- Starts InnoDB transaction. Timer starts HERE (at statement 2).

Le chronomètre commence à l'instruction 2 (la première instruction InnoDB).

autocommit = 0

SET SESSION autocommit=0;  -- No transaction yet
SELECT * FROM t1;          -- Starts InnoDB transaction. Timer starts HERE.
INSERT INTO t1 ...;        -- Same transaction, timer still running from step 2.

Le chronomètre commence à l'instruction 2 (la première instruction InnoDB après la désactivation de la validation automatique).

Procédures stockées

Une procédure stockée s'exécute dans le contexte de transaction de l'appelant. Si l'appelant possède déjà une transaction InnoDB active, le temporisateur était déjà démarré avant l'appel de procédure. Si la procédure est la première chose à toucher InnoDB, le chronomètre démarre à la première instruction InnoDB de la procédure.

BEGIN;
CALL my_proc();  -- If my_proc() does SELECT/INSERT, timer starts at that first InnoDB statement inside the proc

Remarques principales

  • Le délai d'attente est capturé au début de la transaction — La valeur du délai d'attente est capturée lors de l'exécution de la première instruction InnoDB. Tout changement aurora_transaction_timeout effectué au milieu d'une transaction prend effet sur la transaction suivante, et non sur la transaction en cours. Aucun avertissement n'est émis.

  • Les transactions préparées XA sont exclues — Les transactions préparées ne sont pas soumises àaurora_transaction_timeout.

  • Les sessions de transfert d'écriture ne sont pas soumises à un délai d'expiration de transaction — Lorsque le transfert d'écriture est activé, aucun relevé ou transaction contenant un relevé transféré n'est soumis à. aurora_transaction_timeout Les transactions suivantes effectuées au cours de la même session qui n'incluent pas de relevés transférés sont soumises à un délai d'attente normal. Pour contrôler le délai d'inactivité des transactions transférées, vous pouvez utiliser le aurora_fwd_writer_idle_timeout paramètre. Pour de plus amples informations, veuillez consulter Paramètres de configuration pour le transfert d’écriture dans Aurora MySQL.

  • Soyez prudent lorsque les valeurs de délai d'expiration sont élevées  : lorsqu'une transaction de longue durée est annulée, l'annulation peut prendre plusieurs fois plus de temps que les opérations de modification des données d'origine. L'arrêt du processus de base de données n'aide pas car la restauration redémarre au démarrage du serveur. Choisissez une valeur de délai qui équilibre vos besoins en matière de charge de travail et les coûts de restauration. Pour plus d'informations, consultez la section Optimisation de la gestion des transactions InnoDB dans la documentation MySQL.

Erreur du client

Lorsqu'une transaction avec une requête active dépasse le délai d'expiration, le client reçoit l'erreur suivante :

ERROR 63952 (40001): Transaction exceeded maximum allowed duration of <N> seconds and was rolled back. See aurora_transaction_timeout for configuring this behavior.

Lorsqu'une transaction inactive dépasse le délai imparti, la requête suivante reçoit la même erreur que l'erreur MySQL « serveur disparu ». Pour plus d'informations, consultez la section Le serveur MySQL a disparu dans la documentation MySQL.

Journal des erreurs

Un message d'information est écrit dans le journal des erreurs de base de données lorsqu'un délai de transaction se produit :

[Note] Transaction breached timeout threshold and will be rolled back, if still in progress. If idle, the connection will be aborted. Check response for confirmation. connection_id: 4821, trx_id: 28193, user: app_user, timeout: 5 seconds, duration: 7 seconds
Note

Ce message de journal est uniquement destiné à des fins de diagnostic. Fiez-vous à la réponse du client comme indicateur définitif d'une transaction expirée.

Surveillance des délais d'expiration des transactions

Utilisez la variable Aurora_transaction_timeouts status pour suivre le nombre de transactions qui ont expiré depuis le redémarrage de l'instance de base de données.

SHOW GLOBAL STATUS LIKE 'Aurora_transaction_timeouts';

Lorsqu'elle performance_schema est activée, l'erreur de temporisation (ER_AURORA_TRANSACTION_TIMEOUT_ERROR) est également enregistrée dans performance_schema.events_errors_summary_global_by_error les tables associées. Notez que seuls les délais d'expiration des transactions actives incrémentent ce compteur ; les délais des transactions inactives mettent fin à la connexion sans générer d'erreur. ER_AURORA_TRANSACTION_TIMEOUT_ERROR

Interaction avec d'autres timeouts

Cela aurora_transaction_timeout fonctionne parallèlement aux paramètres de temporisation existants. Si une transaction reste ouverte plus longtemps que la durée configuréeaurora_transaction_timeout, elle est résiliée quels que soient les autres paramètres de temporisation. La question de savoir si d'autres délais annulent également la transaction dépend de leur propre implémentation. Pour plus de détails sur ces paramètres, consultez la documentation MySQL.