Come posso risolvere i problemi relativi agli aggiornamenti della versione principale in Amazon RDS per PostgreSQL o Aurora compatibile con PostgreSQL?

Breve descrizione

Gli aggiornamenti della versione principale contengono modifiche al database che non sono retrocompatibili con le applicazioni esistenti. Gli aggiornamenti potrebbero inoltre modificare il formato interno delle tabelle di sistema, dei file di dati e dell'archiviazione dei dati. Amazon RDS utilizza pg_upgrade per eseguire gli aggiornamenti della versione principale. Per ulteriori informazioni, consulta pg_upgrade sul sito web PostgreSQL.

Durante un aggiornamento della versione principale, Amazon RDS esegue una procedura di controllo preliminare che identifica i problemi che potrebbero causare un errore di aggiornamento. A questo scopo, esegue la verifica della presenza di potenziali condizioni di incompatibilità in tutti i database. Se Amazon RDS identifica un problema durante il processo di controllo preliminare, crea un evento del log relativo al controllo preliminare non riuscito. Gli eventi del log includono il nome del file, il timestamp e i motivi dell'errore di aggiornamento. Per informazioni sul processo di controllo preliminare per tutti i database, controlla il log pg_upgrade_precheck.log. Per problemi specifici del motore, devi controllare i file di log del database per Amazon RDS per PostgreSQL o per Aurora PostgreSQL.

Risoluzione

L'utilità pg_upgrade che esegue gli aggiornamenti della versione principale produce i log pg_upgrade_internal.log e pg_upgrade_server.log. Amazon RDS aggiunge un timestamp al nome file per i log. Esamina i log per ottenere ulteriori informazioni sui problemi e gli errori riscontrati durante l'aggiornamento. Per ulteriori informazioni, consulta Monitoraggio dei file di log di Amazon RDS o Monitoraggio dei file di log di Aurora.

Aggiornamenti di lunga durata

Verifica la presenza di attività di manutenzione in sospeso

Se ricevi errori quando esegui i comandi dell'Interfaccia della linea di comando AWS (AWS CLI), consulta Risoluzione degli errori relativi ad AWS CLI. Inoltre, assicurati di utilizzare la versione più recente di AWS CLI.

Amazon RDS utilizza automaticamente gli aggiornamenti della versione del motore per applicare le attività di manutenzione in sospeso, ad esempio una patch del sistema operativo sull'istanza Amazon RDS. Amazon RDS applica per prima l'attività in sospeso, quindi aggiorna la versione del motore. Se Amazon RDS deve eseguire attività di manutenzione del sistema operativo, l'aggiornamento richiede più tempo.

Se l'Amazon istanza RDS è contenuta in un'implementazione multi-AZ, la manutenzione del sistema operativo genera un failover. Quando configuri l'istanza in un ambiente multi-AZ, Amazon RDS crea in genere il backup dell'istanza sull'istanza secondaria. In caso di failover, Amazon RDS crea un backup su una nuova istanza secondaria dopo l'aggiornamento. Poiché questo backup sulla nuova istanza secondaria potrebbe non essere quello più recente, Amazon RDS esegue un backup completo anziché un backup incrementale. Un backup completo può richiedere molto tempo, soprattutto se il database è di grandi dimensioni.

Per evitare il problema, cerca le attività di manutenzione in sospeso per l'istanza database RDS o l'istanza database Aurora. Oppure esegui questo comando AWS CLI describe-pending-maintenance actions sull'istanza:

aws rds describe-pending-maintenance-actions --resource-identifier example-arn

Nota: sostituisci example-arn con l'ARN della tua istanza database.

Completa le attività di manutenzione in sospeso prima di eseguire gli aggiornamenti della versione del motore di database.

Crea uno snapshot prima dell'aggiornamento

Prima di aggiornare la versione, è consigliabile creare uno snapshot dell'istanza database RDS o del cluster di database Aurora. Se hai già attivato i backup per l'istanza, Amazon RDS crea automaticamente uno snapshot come parte del processo di aggiornamento. Gli snapshot riducono la durata del processo di aggiornamento perché per eseguirlo Amazon RDS deve solo creare un backup incrementale.

Attendi l'aggiornamento della replica in lettura

Quando esegui un aggiornamento della versione principale dell'istanza database primaria, Amazon RDS aggiorna automaticamente tutte le repliche in lettura nella stessa Regione AWS. Dopo l'avvio del flusso di lavoro di aggiornamento, le repliche in lettura attendono il completamento corretto di pg_upgrade sull'istanza database primaria. Quindi l'aggiornamento dell'istanza database primaria attende il completamento degli aggiornamenti delle repliche in lettura. L'istanza database si arresta fino al completamento di tutti gli aggiornamenti. Se la finestra del tempo di inattività per l'aggiornamento è ridotta, promuovi o elimina l'istanza di replica e ricrea le repliche in lettura al termine dell'aggiornamento.

Per i cluster di database Aurora, pg_upgrade aggiorna prima l'istanza di scrittura. Quindi ogni istanza database di lettura si chiude quando pg_upgrade la aggiorna alla nuova versione principale.

Nota: se aggiorni un database globale Aurora, ci sono ulteriori requisiti e processi.

Risolvi le transazioni di lunga durata o il carico di lavoro elevato prima dell'aggiornamento

Le transazioni di lunga durata o il carico di lavoro elevato possono aumentare il tempo richiesto da Amazon RDS per arrestare il database e aggiornare il motore di database.

Per identificare le transazioni di lunga durata, esegui questa query:

SQL>SELECT pid, datname, application_name, state, age(query_start, clock_timestamp()), usename, query
FROM pg_stat_activity
WHERE query NOT ILIKE '%pg_stat_activity%' AND
usename!='rdsadmin'
ORDER BY query_start desc;

Se identifichi una transazione di lunga durata, uilizza pg_cancel_backend o pg_terminate_backend per interromperla. Per ulteriori informazioni su pg_cancel_backend e pg_terminate_backend, consulta Server signaling functions (Funzioni di segnalazione del server) sul sito web PostgreSQL.

Accertati che la capacità di calcolo sia sufficiente

L'utilità pg_upgrade può richiedere molte risorse di calcolo. Per verificare se disponi di una capacità di calcolo o di memoria sufficiente, è consigliabile eseguire un aggiornamento di prova prima di aggiornare i database di produzione. L'aggiornamento di prova verifica anche se è possibile riscontrare errori di controllo preliminare o di aggiornamento. Puoi ripristinare lo snapshot dell'istanza di produzione ed eseguire un test con la stessa classe di istanza del database di produzione.

Errori di aggiornamento

Verifica della presenza di classi di istanza database non supportate

Se la classe di istanza database non è compatibile con la versione di PostgreSQL a cui si sta effettuando l'aggiornamento, l'aggiornamento non va a buon fine. Verifica la compatibilità della versione del motore con la classe di istanza per Amazon RDS o Amazon Aurora.

Verifica la presenza di transazioni preparate aperte

Se nel database sono presenti transazioni preparate aperte, l'aggiornamento non va a buon fine. Ricevi l'errore "There are uncommitted prepared transactions" nel file pg_upgrade.log. Prima di iniziare l'aggiornamento, esegui il commit o il rollback di tutte le transazioni preparate aperte.

Per verificare se ci sono transazioni aperte preparate sull'istanza, esegui questa query:

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

Utilizza un tipo di dati supportato

Puoi aggiornare la versione solo per i tipi di datiregclass, regrole e regtype. L'utilità pg_upgrade non è in grado di aggiornare i database che includono colonne di tabelle che utilizzano i tipi di riferimento Identificatore oggetto (OID) reg*. Se utilizzi un tipo di dati regcollation, regconfig, regdictionary, regnamespace, regoper, regoperator, regproc o regprocedure, l'aggiornamento non va a buon fine.

Per risolvere il problema, rimuovi tutti gli usi dei tipi di dati reg*, ad eccezione di regclass, regrole e regtype, prima di aggiornare il motore di dati. Per verificare la presenza di tipi di dati reg* non supportati nelle tabelle, esegui questa query:

SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a  WHERE c.oid = a.attrelid
      AND NOT a.attisdropped
      AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
                         'pg_catalog.regprocedure'::pg_catalog.regtype,
                         'pg_catalog.regoper'::pg_catalog.regtype,
                         'pg_catalog.regoperator'::pg_catalog.regtype,
                         'pg_catalog.regconfig'::pg_catalog.regtype,
                         'pg_catalog.regdictionary'::pg_catalog.regtype)
      AND c.relnamespace = n.oid
      AND n.nspname NOT IN ('pg_catalog', 'information_schema');

Verifica la presenza di slot di replica logica

Se l'istanza contiene slot di replica logica, non puoi aggiornare l'istanza e nel file pg_upgrade.log ricevi il seguente messaggio di errore:

"The instance could not be upgraded because one or more databases have logical replication slots. Please drop all logical replication slots and try again."

In genere si utilizzano slot di replica logica per la migrazione di AWS Database Migration Service (AMS DMS). Vengono anche utilizzati per replicare tabelle da database a data lake, strumenti di business intelligence e altre destinazioni. Assicurati di conoscere lo scopo degli slot di replica logica che utilizzi per determinare se puoi eliminarli. Se gli slot di replica logica sono in uso, non eliminarli. Devi attendere l'aggiornamento della versione prima di poter eliminare gli slot di replica logica.

Se gli slot di replica logica non sono necessari, esegui questi comandi per eliminarli:

SELECT * FROM pg_replication_slots;

SELECT pg_drop_replication_slot(slot_name);

Nota: sostituisci slot_name con il nome dello slot di replica logica.

Verifica la presenza di problemi di archiviazione

Se l'istanza esaurisce lo spazio quando viene eseguito lo script pg_upgrade, l'aggiornamento non riesce e ricevi il seguente messaggio di errore:

"pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] could not execute query: ERROR: could not create file "base/12345/12345678": No space keyword" left on device"

Per risolvere questo problema, assicurati che l'istanza disponga di spazio di archiviazione libero sufficiente prima di avviare l'aggiornamento.

Verifica della presenza di tipi di dati sconosciuti

Non puoi utilizzare tipi di dati sconosciuti in PostgreSQL versione 10 e successive. Ad esempio, se un database PostgreSQL versione 9.6 utilizza il tipo di dati sconosciuti, quando esegui l'aggiornamento alla versione 10 ricevi il seguente messaggio di errore:

"The instance could not be upgraded because the 'unknown' data type is used in user tables. Please remove all usages of the 'unknown' data type and try again."

Per risolvere questo problema, rimuovi manualmente le colonne che utilizzano il tipo di dati sconosciuto o modificale in un tipo di dati supportato. Per trovare le colonne del database che utilizzano il tipo di dati sconosciuto, esegui la seguente query:

SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

(Solo RDS per PostgreSQL) Verifica della presenza di un errore di aggiornamento della replica in lettura

Se l'istanza PostgreSQL dispone di repliche in lettura, gli errori di aggiornamento delle repliche in lettura potrebbero causare un blocco o un errore dell'aggiornamento dell'istanza primaria. Amazon RDS imposta lo stato di una replica in lettura non riuscita su Ripristino incompatibile e quindi interrompe la replica sull'istanza database.

Un aggiornamento della replica in lettura potrebbe non riuscire per uno dei seguenti motivi:

• La replica in lettura non riesce a raggiungere l'istanza database primaria nemmeno dopo il tempo di attesa.
• La replica in lettura si trova in uno stato del ciclo di vita terminale o incompatibile, ad esempio Storage pieno o Ripristino incompatibile.
• Quando si avvia l'aggiornamento dell'istanza database primaria, sulla replica in lettura è in esecuzione un aggiornamento separato della versione secondaria.
• La replica in lettura utilizza parametri incompatibili.
• La replica in lettura non riesce a comunicare con l'istanza database primaria per sincronizzare la cartella dati.

Per risolvere questo problema, elimina la replica in lettura. Quindi ricrea una nuova replica in lettura basata sull'istanza primaria aggiornata dopo l'aggiornamento.

Assicurati che il nome utente principale sia corretto

Se il nome utente principale inizia con pg_, l'aggiornamento non va a buon fine e ricevi il seguente messaggio di errore:

"PreUpgrade checks failed: The instance could not be upgraded because one or more role names start with 'pg_'. Please rename all roles with names that start with 'pg_' and try again".

Per risolvere questo problema, crea un altro utente con il ruolo rds\ _superuser che non inizi con pg\ _.

Verifica la presenza di parametri incompatibili

L'errore "incompatible parameters" si verifica quando il valore di un parametro correlato alla memoria, ad esempio shared_buffer o work_memory, è troppo elevato per la configurazione. Questo errore causa l'esito negativo dello script di aggiornamento. Per risolvere il problema, riduci i valori dei parametri ed esegui nuovamente l'aggiornamento.

Aggiorna le estensioni prima dell'aggiornamento

Gli aggiornamenti della versione principale non aggiornano le estensioni PostgreSQL. Se non aggiorni le estensioni prima di un aggiornamento della versione principale, nel file pg_upgrade.log ricevi un messaggio di errore simile al seguente:

"The Logs indicates that the RDS instance ''abcd'' has older version of PostGIS extension or its dependent extensions (address_standardizer,address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster) installed as against the current version required for the upgrade."

L'esempio di errore precedente mostra un problema con l'estensione PostGIS. Per risolverlo, esegui questa query per verificare la versione predefinita e quella installata per PostGIS e le relative estensioni dipendenti:

SELECT name, default_version, installed_versionFROM pg_available_extensions WHERE installed_version IS NOT NULL AND
name LIKE 'postgis%' OR name LIKE 'address%';

Nota: sostituisci postgis% con la tua estensione.

Se il valore installed_version è inferiore al valore default_version, devi aggiornare PostGIS alla versione predefinita. Per aggiornare l'estensione, esegui questo comando:

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

Nota: sostituisci default_version_number con il valore default_version.

Per ulteriori informazioni, consulta Aggiornamenti del motore di database RDS per PostgreSQL o Aggiornamento dei cluster di database Amazon Aurora PostgreSQL.

Verifica le modifiche nel catalogo di sistema della versione di destinazione che causano problemi nelle viste

Le colonne di alcune viste variano a seconda delle versioni di PostgreSQL. Ad esempio, potresti ricevere un messaggio di errore simile al seguente:

"PreUpgrade checks failed: The instance could not be upgraded because one or more databases have views or materialized views which depend on 'pg_stat_activity'. Please drop them and try again."

Questo errore si verifica quando aggiorni il database dalla versione 9.5 alla 9.6. Nell'esempio di messaggio precedente, l'errore è causato dalla vista pg_stat_activity. Nella versione 9.6, PostgreSQL ha sostituito la colonna waiting con le colonne wait_event_type e wait_event.

Oppure potresti ricevere un messaggio di errore simile al seguente:

"pg_restore: from TOC entry abc; abc abcd VIEW sys_user_constraints art pg_restore: error: could not execute query: ERROR: column c.consrc does not exist LINE 18: "c"."consrc" AS "search_condition", ^ HINT: Perhaps you meant to reference the column "c.conkey" or the column "c.conbin"."

L'esempio di messaggio precedente mostra che l'errore si è verificato perché la struttura del catalogo pg_constraint è cambiata nella versione 12 di PostgreSQL.

Per risolvere questi problemi, elimina le viste basate sui cataloghi di sistema della versione di destinazione.

Importante: prima di eliminare le viste, è consigliabile utilizzare pgdump per eseguirne il backup o acquisirne la definizione. Quando elimini una vista, l'utente o l'amministratore del database deve ricrearla manualmente dopo l'aggiornamento della versione.

Completamento dell'aggiornamento

Al termine dell'aggiornamento, esegui ANALYZE su tutti i database utente per aggiornare la tabella pg_statistics. Un aggiornamento della versione principale non sposta il contenuto della tabella pg_statistics nella nuova versione. Se non sposti il contenuto, le query potrebbero risultare lente.

Informazioni correlate

Overview of the Aurora PostgreSQL upgrade processes (Panoramica dei processi di aggiornamento di Aurora PostgreSQL)