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à.
Autovacuum esegue vuoti aggressivi e abbassa l'età della transazione portandola al di sotto della soglia specificata dal IDs parametro dell'istanza. autovacuum_freeze_max_age RDS Puoi tenere traccia di questa età utilizzando il CloudWatch parametro MaximumUsedTransactionIDs Amazon.
Per trovare l'impostazione di autovacuum_freeze_max_age (che ha un valore predefinito di 200 milioni di transazioniIDs) per la tua RDS istanza Amazon, puoi utilizzare la seguente query:
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';Tieni presente che verifica la presenza di bloccanti del vuoto aggressivi postgres_get_av_diag() solo quando l'età supera la soglia di aspirazione automatica adattiva di Amazon RDS di 500 milioni di transazioni. IDs postgres_get_av_diag()Per rilevare i bloccanti, il blocker deve avere almeno 500 milioni di transazioni.
La postgres_get_av_diag() funzione identifica i seguenti tipi di bloccanti:
Argomenti
Dichiarazione attiva
In PostgreSQL, un'istruzione attiva è un'SQListruzione che viene attualmente eseguita dal database. Ciò include domande, transazioni o qualsiasi operazione in corso. Durante il monitoraggio tramitepg_stat_activity, la colonna dello stato indica che il processo con il corrispondente PID è attivo.
La postgres_get_av_diag() funzione visualizza un output simile al seguente quando identifica un'istruzione che è un'istruzione attiva.
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}Azione consigliata
Seguendo le indicazioni riportate nella suggestion colonna, l'utente può connettersi al database in cui è presente l'istruzione attiva e, come specificato nella suggested_action colonna, è consigliabile esaminare attentamente l'opzione per terminare la sessione. Se l'interruzione è sicura, è possibile utilizzare la pg_terminate_backend() funzione per terminare la sessione. Questa azione può essere eseguita da un amministratore (come l'account RDS principale) o da un utente con il privilegio richiestopg_terminate_backend().
avvertimento
Una sessione terminata annullerà (ROLLBACK) le modifiche apportate. A seconda delle tue esigenze, potresti voler eseguire nuovamente l'istruzione. Tuttavia, si consiglia di eseguire questa operazione solo dopo che il processo di aspirazione automatica ha terminato l'aggressiva operazione di aspirazione.
Inattivo in transazione
Un'istruzione di transazione inattiva si riferisce a qualsiasi sessione che ha aperto una transazione esplicita (ad esempio emettendo una BEGIN dichiarazione), eseguito del lavoro e ora è in attesa che il client esegua altro lavoro o segnali la fine della transazione emettendo un COMMITROLLBACK, o END (il che risulterebbe implicito). COMMIT
La postgres_get_av_diag() funzione visualizza un output simile al seguente quando identifica un'istruzione come bloccante. idle in transaction
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}Azione consigliata
Come indicato nella suggestion colonna, è possibile connettersi al database in cui è presente la sessione di transazione inattiva e terminare la sessione utilizzando la pg_terminate_backend() funzione. L'utente può essere il tuo utente amministratore (account RDS principale) o un utente con il pg_terminate_backend() privilegio.
avvertimento
Una sessione terminata annullerà (ROLLBACK) le modifiche apportate. A seconda delle tue esigenze, potresti voler eseguire nuovamente l'istruzione. Tuttavia, si consiglia di eseguire questa operazione solo dopo che il processo di aspirazione automatica ha terminato l'aggressiva operazione di aspirazione.
Transazione preparata
Postgre SQL consente transazioni che fanno parte di una strategia di commit in due fasi chiamata transazioni preparate.max_prepared_transactions parametro su un valore diverso da zero. Le transazioni preparate sono progettate per garantire che una transazione sia duratura e rimanga disponibile anche dopo arresti anomali del database, riavvii o disconnessioni del client. Analogamente alle normali transazioni, a esse viene assegnato un ID di transazione e possono influire sull'autovacuum. Se lasciato in uno stato preparato, l'autovacuum non può bloccarsi e può comportare la modifica dell'ID della transazione.
Quando le transazioni vengono lasciate preparate a tempo indeterminato senza essere risolte da un gestore delle transazioni, diventano transazioni preparate orfane. L'unico modo per risolvere questo problema è eseguire il commit o il rollback della transazione utilizzando rispettivamente i ROLLBACK
PREPARED comandi COMMIT PREPARED or.
Nota
Tieni presente che un backup eseguito durante una transazione preparata conterrà ancora quella transazione dopo il ripristino. Consulta le seguenti informazioni su come individuare e chiudere tali transazioni.
La postgres_get_av_diag() funzione visualizza il seguente output quando identifica un blocker che è una transazione preparata.
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}Azione suggerita
Come indicato nella colonna dei suggerimenti, connettiti al database in cui si trova la transazione preparata. In base alla suggested_action colonna, esamina attentamente se eseguire una delle due COMMIT oROLLBACK, quindi, l'azione appropriata.
Per monitorare le transazioni preparate in generale, Postgre SQL offre una visualizzazione del catalogo chiamata. pg_prepared_xacts È possibile utilizzare la seguente query per trovare le transazioni preparate.
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;Slot di replica logica
Lo scopo di uno slot di replica è conservare le modifiche non utilizzate fino a quando non vengono replicate su un server di destinazione. Per ulteriori informazioni, consulta la replica logica di PostgresSQL.
Esistono due tipi di slot di replica logica.
Slot di replica logica inattivi
Quando la replica viene terminata, i log delle transazioni non utilizzati non possono essere rimossi e lo slot di replica diventa inattivo. Sebbene uno slot di replica logica inattivo non sia attualmente utilizzato da un abbonato, rimane sul server, con conseguente conservazione dei WAL file e impedimento della rimozione dei vecchi log delle transazioni. Ciò può aumentare l'utilizzo del disco e in particolare impedire ad Autovacuum di ripulire le tabelle interne del catalogo, poiché il sistema deve impedire che le informazioni vengano sovrascritte. LSN Se non viene risolto, ciò può comportare un aumento del volume del catalogo, un peggioramento delle prestazioni e un aumento del rischio che si verifichi un vuoto incompleto, con conseguenti potenziali interruzioni delle transazioni.
Slot di replica logica attivi ma lenti
A volte la rimozione delle tuple morte del catalogo viene ritardata a causa del peggioramento delle prestazioni della replica logica. Questo ritardo nella replica rallenta l'aggiornamento del catalogo catalog_xmin e può portare a un aumento esponenziale del catalogo e a un vuoto avvolgente.
La postgres_get_av_diag() funzione visualizza un output simile al seguente quando trova uno slot di replica logico da bloccare.
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}Azione consigliata
Per risolvere questo problema, controllate la configurazione di replica per individuare eventuali problemi con lo schema o i dati di destinazione che potrebbero interrompere il processo di applicazione. I motivi più comuni sono i seguenti:
-
Colonne mancanti
-
Tipo di dati incompatibile
-
Mancata corrispondenza dei dati
-
Tabella mancante
Se il problema è legato a problemi di infrastruttura:
-
Problemi di rete: come posso risolvere i problemi con un RDS database Amazon in uno stato di rete incompatibile
? . -
Il database o l'istanza DB non sono disponibili per i seguenti motivi:
-
L'istanza di replica ha esaurito lo storage: consulta le istanze Amazon RDS DB che hanno esaurito lo storage
per informazioni sull'aggiunta di storage. -
Parametri incompatibili: recensione Come posso correggere un'istanza Amazon RDS DB bloccata nello stato di
parametri incompatibili? per ulteriori informazioni su come risolvere il problema.
-
Se l'istanza è attiva o esterna alla AWS rete AWS EC2, consulta l'amministratore per risolvere i problemi relativi alla disponibilità o all'infrastruttura.
Eliminazione dello slot inattivo
avvertimento
Attenzione: prima di eliminare uno slot di replica, assicuratevi attentamente che non sia in corso alcuna replica, che sia inattivo e che si trovi in uno stato irreversibile. L'eliminazione prematura di uno slot potrebbe interrompere la replica o causare la perdita di dati.
Dopo aver verificato che lo slot di replica non è più necessario, eliminalo per consentire il proseguimento dell'autovacuum. Questa condizione active = 'f' garantisce che venga eliminato solo uno slot inattivo.
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'Repliche di lettura
Quando l'hot_standby_feedbackimpostazione è abilitata per le repliche di RDS lettura di Amazon, impedisce che l'autovacuum sul database primario rimuova le righe morte che potrebbero essere ancora necessarie per le query in esecuzione sulla replica di lettura. Ciò influisce su tutti i tipi di repliche fisiche di lettura, comprese quelle gestite con o senza slot di replica. Questo comportamento è necessario perché le query in esecuzione sulla replica in standby richiedono che tali righe rimangano disponibili sulla replica principale, evitando conflitti e annullamenti delle query.
Leggi la replica con lo slot di replica fisico
Le repliche di lettura con slot di replica fisici migliorano significativamente l'affidabilità e la stabilità della replica in For Postgre. RDS SQL Questi slot assicurano che il database primario conservi i file Write-Ahead Log essenziali fino a quando la replica non li elabora, mantenendo la coerenza dei dati anche durante le interruzioni della rete.
A partire dalla SQL versione 14 RDS di Postgre, tutte le repliche utilizzano slot di replica. Nelle versioni precedenti, solo le repliche interregionali utilizzavano slot di replica.
La postgres_get_av_diag() funzione visualizza un output simile al seguente quando trova una replica di lettura con uno slot di replica fisico come blocco.
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}Leggi la replica con la replica in streaming
Amazon RDS consente di configurare repliche di lettura senza uno slot di replica fisico nelle versioni precedenti, fino alla versione 13. Questo approccio riduce il sovraccarico consentendo al gestore principale di riciclare WAL i file in modo più aggressivo, il che è vantaggioso in ambienti con spazio su disco limitato e può essere utilizzato occasionalmente. ReplicaLag Tuttavia, senza uno slot, lo standby deve rimanere sincronizzato per evitare la perdita di file. WAL Amazon RDS utilizza WAL file archiviati per aiutare la replica a recuperare il ritardo in caso di ritardo, ma questo processo richiede un monitoraggio attento e può essere lento.
La postgres_get_av_diag() funzione visualizza un output simile al seguente quando trova una replica di lettura in streaming come blocco.
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}Azione consigliata
Come consigliato nella suggested_action colonna, esamina attentamente queste opzioni per sbloccare l'autovacuum.
-
Termina la query: seguendo le indicazioni nella colonna dei suggerimenti, puoi connetterti alla replica di lettura, come specificato nella colonna suggested_action. È consigliabile esaminare attentamente l'opzione per terminare la sessione. Se l'interruzione è ritenuta sicura, è possibile utilizzare la funzione per terminare la sessione.
pg_terminate_backend()Questa azione può essere eseguita da un amministratore (come l'account RDS principale) o da un utente con il privilegio pg_terminate_backend () richiesto.È possibile eseguire il seguente SQL comando sulla replica di lettura per terminare la query che impedisce all'aspirapolvere sul primario di ripulire le vecchie righe. Il valore di
backend_xminè riportato nell'output della funzione:SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint =backend_xmin; -
Disabilita il feedback in modalità hot standby: valuta la possibilità di disattivare il
hot_standby_feedbackparametro se causa ritardi significativi nel vuoto.Il
hot_standby_feedbackparametro consente a una replica di lettura di informare il primario sulla sua attività di interrogazione, impedendo al primario di cancellare le tabelle o le righe in uso in standby. Se da un lato ciò garantisce la stabilità delle query in standby, dall'altro può ritardare in modo significativo lo svuotamento della memoria principale. La disattivazione di questa funzione consente al primario di procedere con l'aspirazione senza attendere che lo standby si riprenda. Tuttavia, ciò può comportare l'annullamento delle query o il mancato funzionamento dello standby se tenta di accedere alle righe che sono state cancellate dal sistema primario. -
Eliminare la replica di lettura se non è più necessaria: se la replica di lettura non è più necessaria, è possibile eliminarla. Ciò rimuoverà il sovraccarico di replica associato e consentirà al principale di riciclare i log delle transazioni senza essere ostacolato dalla replica.
Tabelle temporanee
Le tabelle temporaneeTEMPORARY parola chiave, risiedono nello schema temporaneo, ad esempio pg_temp_xxx, e sono accessibili solo alla sessione che le ha create. Le tabelle temporanee vengono eliminate al termine della sessione. Tuttavia, queste tabelle sono invisibili al processo di autovacuum SQL di Postgre e devono essere pulite manualmente dalla sessione che le ha create. Il tentativo di aspirare la tabella temporanea da un'altra sessione non ha alcun effetto.
In circostanze insolite, una tabella temporanea esiste senza che una sessione attiva ne sia proprietaria. Se la sessione proprietaria termina inaspettatamente a causa di un arresto anomalo irreversibile, di un problema di rete o di un evento simile, è possibile che la tabella temporanea non venga ripulita, lasciandola come tabella «orfana». Quando il processo Postgre SQL autovacuum rileva una tabella temporanea orfana, registra il seguente messaggio:
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"La postgres_get_av_diag() funzione visualizza un output simile al seguente quando identifica una tabella temporanea come bloccante. Affinché la funzione mostri correttamente l'output relativo alle tabelle temporanee, deve essere eseguita all'interno dello stesso database in cui esistono tali tabelle.
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}Azione consigliata
Segui le istruzioni fornite nella suggestion colonna dell'output per identificare e rimuovere la tabella temporanea che impedisce l'esecuzione di autovacuum. Utilizzate il comando seguente per eliminare la tabella temporanea riportata da. postgres_get_av_diag() Sostituisci il nome della tabella in base all'output fornito dalla postgres_get_av_diag() funzione.
DROP TABLE my_temp_schema.my_temp_table;La seguente query può essere utilizzata per identificare le tabelle temporanee:
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;