Lock:Relation - Amazon Aurora
Versions de moteur prises en chargeContexteCauses probables de l'allongement des temps d'attenteActions

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.

Lock:Relation

L'événement Lock:Relation se produit lorsqu'une requête attend d'acquérir un verrou sur une table ou une vue (relation) actuellement verrouillée par une autre transaction.

Versions de moteur prises en charge

Ces informations sur les événements d'attente sont prises en charge pour toutes les versions d'Aurora PostgreSQL.

Contexte

La plupart des SQL commandes Postgre utilisent implicitement des verrous pour contrôler l'accès simultané aux données des tables. Vous pouvez également utiliser ces verrous explicitement dans le code de votre application grâce à la commande LOCK. De nombreux modes de verrouillage ne sont pas compatibles entre eux et peuvent bloquer des transactions lorsqu'ils tentent d'accéder au même objet. Lorsque cela se produit, Aurora Postgre SQL génère un Lock:Relation événement. Voici quelques exemples courants :

  • Des verrous exclusifs tels que ACCESS EXCLUSIVE peuvent bloquer tous les accès simultanés. Opérations du langage de définition des données (DDL) telles queDROP TABLE, TRUNCATEVACUUM FULL, et CLUSTER acquérir des ACCESS EXCLUSIVE verrous implicitement. ACCESS EXCLUSIVEest également le mode de verrouillage par défaut pour les LOCK TABLE instructions qui ne spécifient pas de mode de manière explicite.

  • L'utilisation CREATE INDEX (without CONCURRENT) sur une table entre en conflit avec les instructions du langage de manipulation des données (DML) UPDATEDELETE, etINSERT, qui acquièrent des ROW EXCLUSIVE verrous.

Pour plus d'informations sur les verrous au niveau des tables et les modes de verrouillage conflictuels, consultez Explicit Locking dans la documentation SQL Postgre.

Le déblocage lié aux requêtes et transactions de blocage s'effectue généralement de l'une des manières suivantes :

  • Requête de blocage – L'application peut annuler la requête ou l'utilisateur peut mettre fin au processus. Le moteur peut également forcer la requête à se terminer en raison de l'expiration du délai d'attente d'une instruction de la session ou d'un mécanisme de détection de blocage.

  • Transaction de blocage – Une transaction met fin à son blocage lorsqu'elle exécute une instruction ROLLBACK ou COMMIT. Les restaurations sont également automatiques lorsque les sessions sont déconnectées par un client ou suite à des problèmes de réseau, ou lorsqu'elles sont interrompues. Les sessions peuvent être interrompues lorsque le moteur de base de données est arrêté, lorsque le système est à court de mémoire, etc.

Causes probables de l'allongement des temps d'attente

Lorsque l'événement Lock:Relation se produit plus fréquemment que la normale, il peut indiquer un problème de performances. Les causes sont généralement les suivantes :

Augmentation du nombre de sessions simultanées avec des verrous de table conflictuels

Le nombre de sessions simultanées peut augmenter lorsque des requêtes verrouillent la même table avec des modes de verrouillage conflictuels.

Opérations de maintenance

Les opérations de maintenance liées à l'état comme VACUUM et ANALYZE peuvent considérablement augmenter le nombre de verrous en conflit. VACUUM FULL acquiert un verrou ACCESS EXCLUSIVE, et ANALYZE acquiert un verrou SHARE UPDATE EXCLUSIVE. Ces deux types de verrous peuvent provoquer un événement d'attente Lock:Relation. Les opérations de maintenance des données d'application telles que l'actualisation d'une vue matérialisée peuvent également augmenter le nombre de requêtes et de transactions bloquées.

Verrous sur les instances de lecture

Il peut y avoir un conflit entre les verrous relationnels des volumes en écriture et des volumes en lecture. Actuellement, seuls les verrous relationnels ACCESS EXCLUSIVE sont répliqués vers les instances de lecture. Cependant, le verrou relationnel ACCESS EXCLUSIVE entrera en conflit avec tout verrou relationnel ACCESS SHARE détenu par le volume en lecture. Cela peut entraîner une augmentation des événements d'attente de relation de verrouillage sur le volume en lecture.

Actions

Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente.

Réduisez l'impact du blocage SQL des déclarations

Pour réduire l'impact des SQL instructions de blocage, modifiez le code de votre application dans la mesure du possible. Voici deux techniques courantes pour réduire les blocages :

  • Utiliser l'NOWAIToption — Certaines SQL commandes, telles que les LOCK instructions SELECT et, prennent en charge cette option. La directive NOWAIT annule la requête liée à la demande de verrou si le verrou ne peut pas être acquis immédiatement. Cette technique permet d'éviter qu'une session de blocage ne provoque un empilement de sessions bloquées derrière elle.

    Par exemple, supposons que la transaction A attende un verrou détenu par la transaction B. Si B demande un verrou sur une table qui est verrouillée par la transaction C, la transaction A peut être bloquée jusqu'à ce que la transaction C se termine. Mais si la transaction B utilise NOWAIT lorsqu'elle demande le verrou sur C, elle peut échouer rapidement et faire en sorte que la transaction A n'ait pas à attendre indéfiniment.

  • Utiliser SET lock_timeout — Définissez une lock_timeout valeur pour limiter le temps d'attente d'une SQL instruction avant de verrouiller une relation. Si le verrou n'est pas acquis dans le délai spécifié, la transaction demandant le verrou est annulée. Définissez cette valeur au niveau de la session.

Minimisez l'effet des opérations de maintenance

Les opérations de maintenance telles que VACUUM et ANALYZE sont importantes. Nous vous recommandons de ne pas les désactiver parce que vous trouvez des événements d'attente Lock:Relation liés à ces opérations de maintenance. Les approches suivantes peuvent minimiser l'effet de ces opérations :

  • Exécutez les opérations de maintenance manuellement pendant les heures creuses.

  • Pour réduire les attentes Lock:Relation causées par les tâches autovacuum, procédez aux réglages nécessaires de la fonction autovacuum. Pour plus d'informations sur le réglage de l'aspirateur automatique, consultez la section Utilisation de l'aspirateur SQL automatique Postgre sur Amazon RDS dans le guide de l'utilisateur Amazon RDS.

Recherchez les verrous de lecture

Vous pouvez déterminer comment des sessions ouvertes simultanément sur un dispositif d'écriture et un lecteur peuvent détenir des verrous qui se bloquent mutuellement. Une façon de le faire est d'exécuter des requêtes qui renvoient le type de verrou et la relation. Dans le tableau, vous pouvez trouver une séquence de requêtes pour deux sessions simultanées de ce type, une session de rédaction et une session de lecture.

Le processus de rediffusion attend la durée de max_standby_streaming_delay avant d'annuler la requête du lecteur. Comme le montre l'exemple, le délai de verrouillage de 100 ms est bien inférieur au délai max_standby_streaming_delay par défaut de 30 secondes. Le verrouillage s'arrête avant que cela ne devienne un problème.

Événement séquentiel Session Commande ou sortie

Définit une variable d'environnement appelée READER avec la valeur spécifiée et essaie de se connecter à l'instance de base de données avec ce point de terminaison.

Session de lecture

CLIcommande :

export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com

psql -h $READER

Sortie :

psql (15devel, server 10.14)
Type "help" for help.

Définit une variable d'environnement appelée WRITER et essaie de se connecter à l'instance de base de données avec ce point de terminaison.

Session d'écriture

CLIcommande :

export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER

Sortie :

psql (15devel, server 10.14) 
Type "help" for help.

La session Writer crée la table t1 sur l'instance Writer.

Session d'écriture

SQLRequête Postgre :

postgres=> CREATE TABLE t1(b integer);
CREATE TABLE

S'il n'y a pas de requêtes contradictoires sur le rédacteur, le ACCESS EXCLUSIVE verrou est immédiatement acquis sur le rédacteur.

Session d'écriture

ACCESS EXCLUSIVEverrouillage activé

La session du lecture définit un intervalle d'expiration de 100 millisecondes pour le verrou.

Session de lecture

SQLRequête Postgre :

postgres=> SET lock_timeout=100;
SET

La session de lecture essaie de lire les données de la table t1 sur l'instance de lecteur.

Session de lecture

SQLRequête Postgre :

postgres=> SELECT * FROM t1;

Exemple de sortie :

b
---
(0 rows)

La session Writer perd t1.

Session d'écriture

SQLRequête Postgre :

postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>

La requête expire et est annulée sur le lecteur.

Session de lecture

SQLRequête Postgre :

postgres=> SELECT * FROM t1;

Exemple de sortie :

ERROR:  canceling statement due to lock timeout
LINE 1: SELECT * FROM t1;
                      ^

Pour déterminer la cause de l'erreur, la session du lecteur interroge et pg_locks pg_stat_activity

Session de lecture

SQLRequête Postgre :

postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;

Le résultat indique que le aurora wal replay processus ACCESS EXCLUSIVE bloque la table t1.

Session de lecture

Résultat de la requête :

 locktype | relation |        mode         |   backend_type
----------+----------+---------------------+-------------------
 relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)