Risoluzione dei blocchi non identificabili per i processi di vacuum in RDS per PostgreSQL - Amazon Relational Database Service
Pagine non valideIncoerenza dell’indiceTasso di transazione eccezionalmente elevato

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à.

Risoluzione dei blocchi non identificabili per i processi di vacuum in RDS per PostgreSQL

Questa sezione esplora ulteriori motivi che possono impedire l’avanzamento del processo di autovacuum. Al momento tali problemi non sono direttamente identificabili tramite la funzione postgres_get_av_diag().

Pagine non valide

Un errore di pagina non valida si verifica quando PostgreSQL rileva una mancata corrispondenza nel checksum di una pagina durante l’accesso a tale pagina. I contenuti sono illeggibili, il che impedisce al processo di autovacuum di bloccare le tuple. Ciò arresta in modo efficace il processo di pulizia. Il seguente errore è scritto nel log di PostgreSQL:

WARNING:  page verification failed, calculated checksum YYYYY but expected XXXX
ERROR:  invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT:  automatic vacuum of table myschema.mytable

Come determinare il tipo di oggetto

ERROR: invalid page in block 4305910 of relation base/16403/186752608 
WARNING: page verification failed, calculated checksum 50065 but expected 60033

Dal messaggio di errore, il percorso base/16403/186752608 fornisce le seguenti informazioni:

  • “base” è il nome della directory all’interno della directory di dati PostgreSQL.

  • “16403” è l’OID del database, che puoi cercare nel catalogo di sistema pg_database.

  • “186752608” è il relfilenode, che puoi utilizzare per cercare lo schema e il nome dell’oggetto nel catalogo di sistema pg_class.

Controllando l’output della seguente query nel database interessato, è possibile determinare il tipo di oggetto. La seguente query recupera le informazioni sull’oggetto per oid: 186752608. Sostituisci l’OID con quello relativo all’errore riscontrato.

SELECT
    relname AS object_name,
    relkind AS object_type,
    nspname AS schema_name
FROM
    pg_class c
    JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
    c.oid = 186752608;

Per ulteriori informazioni, consulta pg_class nella documentazione di PostgreSQL per trovare tutti i tipi di oggetto supportati, indicati nella colonna relkind in pg_class.

Linea guida

La soluzione più efficace per questo problema dipende dalla configurazione dell’istanza Amazon RDS specifica e dal tipo di dati interessati dalla pagina incoerente.

Se il tipo di oggetto è un indice:

Si consiglia di ricreare l’indice.

  • Utilizzo dell’opzione CONCURRENTLY: prima della versione 12 di PostgreSQL, per ricreare un indice era richiesto un blocco di tabella esclusivo, che limitava l’accesso alla tabella. Con la versione 12 di PostgreSQL e le versioni successive, l’opzione CONCURRENTLY consente di eseguire il blocco a livello di riga e ciò migliora la disponibilità della tabella in modo significativo. Il comando è il seguente:

    REINDEX INDEX ix_name CONCURRENTLY;

    Sebbene CONCURRENTLY sia meno dannoso, può essere più lento sulle tabelle particolarmente utilizzate. Se possibile, valuta la possibilità di creare l’indice durante i periodi di traffico ridotto.

    Per ulteriori informazioni, consulta REINDEX nella documentazione di PostgreSQL.

  • Utilizzo dell’opzione INDEX_CLEANUP FALSE: se gli indici sono di grandi dimensioni e si stima che richiedano un lungo lasso di tempo per completare l’operazione, puoi sbloccare l’autovacuum eseguendo un VACUUM FREEZE manuale escludendo gli indici. Questa funzionalità è disponibile in PostgreSQL 12 e versioni successive.

    Bypassare gli indici ti consentirà di saltare il processo di vacuum dell’indice incoerente e mitigare il problema di wraparound. Tuttavia, ciò non risolverà il problema presente alla base e relativo alla pagina non valida. Per risolvere completamente il problema relativo alla pagina non valida, dovrai comunque ricreare l’indice.

Se il tipo di oggetto è una vista materializzata:

Se si verifica un errore di pagina non valida in una vista materializzata, accedi al database interessato e aggiornalo per risolvere la pagina non valida.

Aggiorna la vista materializzata.

REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;

Se l’aggiornamento non riesce, prova a eseguire una nuova creazione:

DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;

L’aggiornamento o la nuova creazione della vista materializzata la ripristina senza influire sui dati della tabella sottostante.

Per tutti gli altri tipi di oggetto:

Per tutti gli altri tipi di oggetto, contatta l’assistenza AWS.

Incoerenza dell’indice

Un indice logicamente incoerente può impedire il progresso del processo di autovacuum. I seguenti errori o errori simili vengono registrati durante la fase di vacuum dell’indice o quando si accede all’indice tramite istruzioni SQL.

ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT:  while vacuuming index index_name of relation schema.table

Linea guida

Ricrea l’indice o salta gli indici utilizzando INDEX_CLEANUP sul VACUUM FREEZE manuale. Per informazioni su come creare nuovamente l’indice, consulta Se il tipo di oggetto è un indice.

  • Utilizzo dell’opzione CONCURRENTLY: prima della versione 12 di PostgreSQL, per ricreare un indice era richiesto un blocco di tabella esclusivo, che limitava l’accesso alla tabella Con la versione 12 di PostgreSQL e le versioni successive, l’opzione CONCURRENTLY consente di eseguire il blocco a livello di riga e ciò migliora la disponibilità della tabella in modo significativo. Il comando è il seguente:

    REINDEX INDEX ix_name CONCURRENTLY;

    Sebbene CONCURRENTLY sia meno dannoso, può essere più lento sulle tabelle particolarmente utilizzate. Se possibile, valuta la possibilità di creare l’indice durante i periodi di traffico ridotto. Per ulteriori informazioni, consulta REINDEX nella documentazione di PostgreSQL.

  • Utilizzo dell’opzione INDEX_CLEANUP FALSE: se gli indici sono di grandi dimensioni e si stima che richiedano un lungo lasso di tempo per completare l’operazione, puoi sbloccare l’autovacuum eseguendo un VACUUM FREEZE manuale escludendo gli indici. Questa funzionalità è disponibile in PostgreSQL 12 e versioni successive.

    Bypassare gli indici ti consentirà di saltare il processo di vacuum dell’indice incoerente e mitigare il problema di wraparound. Tuttavia, ciò non risolverà il problema presente alla base e relativo alla pagina non valida. Per risolvere completamente il problema relativo alla pagina non valida, dovrai comunque ricreare l’indice.

Tasso di transazione eccezionalmente elevato

In PostgreSQL, i tassi di transazione elevati possono influire in modo significativo sulle prestazioni di autovacuum, portando a una pulizia più lenta delle tuple inattive e a un aumento del rischio di wraparound dell’ID di transazione. È possibile monitorare il tasso di transazione misurando la differenza in max(age(datfrozenxid)) tra due periodi di tempo, in genere al secondo. Inoltre, puoi utilizzare le seguenti metriche dei contatori di Approfondimenti sulle prestazioni di RDS per misurare il tasso di transazione (la somma di xact_commit e xact_rollback) che è il numero totale delle transazioni.

Contatore Tipo Unità Parametro

xact_commit

Transazioni

Commit al secondo

db.Transactions.xact_commit

xact_rollback

Transazioni

Rollback al secondo

db.Transactions.xact_rollback

Un aumento rapido indica un carico di transazioni elevato, che può sovraccaricare il processo di autovacuum, con conseguenti aumento di dimensioni, conflitti di blocco e potenziali problemi di prestazioni. Ciò può influire negativamente sul processo di autovacuum in due modi:

  • Attività delle tabelle: la tabella specifica in fase di vacuum potrebbe registrare un volume elevato di transazioni, con conseguenti ritardi.

  • Risorse di sistema: l’intero sistema potrebbe essere sovraccarico e ciò rende difficile per l’autovacuum accedere alle risorse necessarie per garantire un funzionamento efficiente.

Esamina le seguenti strategie per consentire all’autovacuum di funzionare in modo più efficace e tenere il passo con le sue attività:

  1. Riduzione, se possibile, del tasso di transazioni. Possibilità di raggruppare le transazioni simili, ove applicabile.

  2. Concentrazione delle tabelle aggiornate di frequente con operazioni VACUUM FREEZE manuali con frequenza notturna, settimanale o bisettimanale nelle ore non di punta.

  3. Possibilità di aumentare verticalmente la classe di istanza per allocare più risorse di sistema al fine di gestire l’elevato volume di transazioni e l’autovacuum.