Lock:Relation - Amazon Aurora
Versioni del motore supportateContextProbabili cause di aumento delle atteseAzioni

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Lock:Relation

L’evento Lock:Relation si verifica quando una query è in attesa di acquisire un blocco su una tabella o vista (relazione) attualmente bloccata da un'altra transazione.

Versioni del motore supportate

Queste informazioni sugli eventi di attesa sono supportate per tutte le versioni di Aurora Postgre. SQL

Context

La maggior parte dei SQL comandi Postgre utilizza implicitamente i blocchi per controllare l'accesso simultaneo ai dati nelle tabelle. È inoltre possibile utilizzare questi blocchi esplicitamente nel codice dell'applicazione con il comando LOCK. Molte modalità di blocco non sono compatibili tra loro e possono bloccare le transazioni quando cercano di accedere allo stesso oggetto. Quando ciò accade, Aurora Postgre SQL genera un evento. Lock:Relation Di seguito sono riportati alcuni esempi comuni:

  • Blocchi esclusivi come ACCESS EXCLUSIVE possono bloccare tutti gli accessi simultanei. Operazioni Data Definition Language (DDL) comeDROP TABLE, TRUNCATEVACUUM FULL, e CLUSTER acquisisci ACCESS EXCLUSIVE blocchi in modo implicito. ACCESS EXCLUSIVEè anche la modalità di blocco predefinita per LOCK TABLE le istruzioni che non specificano una modalità in modo esplicito.

  • L'utilizzo CREATE INDEX (without CONCURRENT) su una tabella è in conflitto con le istruzioni Data Manipulation Language (DML) e UPDATE DELETEINSERT, che acquisiscono ROW EXCLUSIVE blocchi.

Per ulteriori informazioni sui blocchi a livello di tabella e sulle modalità di blocco in conflitto, consulta Explicit Locking nella documentazione di Postgre. SQL

Il blocco di query e transazioni in genere si sblocca in uno dei seguenti modi:

  • Query di blocco: l'applicazione può annullare la query o l'utente può terminare il processo. Il motore può anche forzare la fine della query a causa del timeout dell'istruzione di una sessione o di un meccanismo di rilevamento del deadlock.

  • Blocco della transazione: una transazione smette di bloccarsi quando esegue un’istruzione ROLLBACK o COMMIT. I rollback si verificano automaticamente anche quando le sessioni vengono disconnesse da un client o da problemi di rete o terminano. Le sessioni possono essere terminate quando il motore di database è spento, quando il sistema è fuori memoria e così via.

Probabili cause di aumento delle attese

Quando l'evento Lock:Relation si verifica più frequentemente del normale, può indicare un problema di prestazioni. Le cause tipiche sono:

Sessioni simultanee aumentate con blocchi di tabella in conflitto

Potrebbe esserci un aumento del numero di sessioni simultanee con query che inseriscono o aggiornano la stessa tabella.

Operazioni di manutenzione

Le operazioni di manutenzione Health come VACUUM e ANALYZE possono aumentare significativamente il numero di blocchi in conflitto. VACUUM FULL acquisisce un blocco ACCESS EXCLUSIVE, e ANALYZE acquisisce un blocco SHARE UPDATE EXCLUSIVE. Entrambi i tipi di blocchi possono causare un evento di attesa Lock:Relation. Le operazioni di manutenzione dei dati delle applicazioni, come l'aggiornamento di una vista materializzata, possono anche aumentare le query e le transazioni bloccate.

Blocchi sulle istanze del lettore

È possibile che si verifichi un conflitto tra i blocchi di relazione tenuti dallo scrittore e dai lettori. Attualmente solo i blocchi di relazione ACCESS EXCLUSIVE vengono replicati nelle istanze del lettore. Tuttavia, il blocco di relazione ACCESS EXCLUSIVE sarà in conflitto con qualsiasi blocco di relazione ACCESS SHARE tenuto dal lettore. Questo conflitto può causare un aumento degli eventi di attesa della relazione di blocco sul lettore.

Azioni

Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.

SQLRiduci l'impatto delle istruzioni di blocco

Per ridurre l'impatto delle SQL istruzioni di blocco, modificate il codice dell'applicazione ove possibile. Di seguito sono riportate due tecniche comuni per ridurre i blocchi:

  • Usa l'NOWAITopzione: alcuni SQL comandi, come SELECT e LOCK istruzioni, supportano questa opzione. La direttiva NOWAIT annulla la query richiedente il blocco se il blocco non può essere acquisito immediatamente. Questa tecnica può aiutare a impedire che una sessione di blocco provochi un accumulo di sessioni bloccate dietro di essa.

    Ad esempio: si supponga che la transazione A sia in attesa di un blocco trattenuto dalla transazione B. Ora, se B richiede un blocco su una tabella bloccata dalla transazione C, la transazione A potrebbe essere bloccata fino al completamento della transazione C. Ma se la transazione B utilizza un NOWAIT quando richiede il blocco su C, può fallire rapidamente e garantire che la transazione A non debba attendere indefinitamente.

  • UsaSET lock_timeout: imposta un lock_timeout valore per limitare il tempo di attesa di un'SQListruzione per acquisire un blocco su una relazione. Se il blocco non viene acquisito entro il timeout specificato, la transazione che richiede il blocco viene annullata. Impostare questo valore a livello di sessione.

Riduci al minimo l'effetto delle operazioni di manutenzione

Operazioni di manutenzione come VACUUM e ANALYZE sono importanti. Si consiglia di non spegnerli qualora vengano trovati eventi di attesa Lock:Relation relativi a queste operazioni di manutenzione. I seguenti approcci possono ridurre al minimo l'effetto di queste operazioni:

  • Eseguire manualmente le operazioni di manutenzione durante le ore non di punta.

  • Per ridurre le attese Lock:Relation causate da attività autovacuum, eseguire qualsiasi sintonizzazione automatica necessaria. Per informazioni sulla regolazione dell'autovacuum, consulta Working with Postgre SQL autovacuum on Amazon nella Amazon User Guide. RDS RDS

Verifica la presenza di blocchi del lettore

Puoi vedere come le sessioni simultanee su uno scrittore e sui lettori potrebbero tenere blocchi che si bloccano a vicenda. A questo scopo, puoi eseguire le query che restituiscono il tipo di blocco e la relazione. Nella tabella, puoi trovare una sequenza di interrogazioni relative a due di queste sessioni simultanee, una sessione di scrittura e una sessione di lettura.

Il processo di riproduzione attende la durata di 1 max_standby_streaming_delay prima di annullare la query del lettore. Come mostrato nell'esempio, il timeout di blocco di 100 ms è ben al di sotto del valore di default di max_standby_streaming_delay di 30 secondi. Il timeout di blocco si verifica prima che si verifichi un problema.

Evento di sequenza Sessione Comando o output

Imposta una variabile di ambiente chiamata READER con il valore specificato e tenta di connettersi all'istanza DB con questo endpoint.

Sessione lettore

CLIcomando:

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

psql -h $READER

Output:

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

Imposta una variabile di ambiente chiamata WRITER e tenta di connettersi all'istanza DB con questo endpoint.

Sessione di scrittura

CLIcomando:

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

Output:

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

La sessione writer crea la tabella t1 sull'istanza writer.

Sessione di scrittura

Interrogazione Postger: SQL

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

Se non ci sono domande contrastanti sullo scrittore, il ACCESS EXCLUSIVE blocco viene acquisito immediatamente dallo scrittore.

Sessione di scrittura

ACCESS EXCLUSIVEblocco abilitato

La sessione del lettore imposta un intervallo di timeout di blocco di 100 millisecondi.

Sessione lettore

Interrogazione Postgree: SQL

postgres=> SET lock_timeout=100;
SET

La sessione di lettura tenta di leggere i dati dalla tabella t1 sull'istanza del lettore.

Sessione lettore

Interrogazione Postgree: SQL

postgres=> SELECT * FROM t1;

Output di esempio:

b
---
(0 rows)

La sessione di scrittura elimina t1.

Sessione di scrittura

Interrogazione Postgres: SQL

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

La query scade e viene annullata sul lettore.

Sessione lettore

Interrogazione SQL Postgre:

postgres=> SELECT * FROM t1;

Output di esempio:

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

Per determinare la causa dell'errore. la sessione di lettura interroga e pg_locks pg_stat_activity

Sessione lettore

Interrogazione Postgree: SQL

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;

Il risultato indica che il aurora wal replay processo sta ACCESS EXCLUSIVE bloccando la tabella t1.

Sessione lettore

Risultato della query:

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