Come posso risolvere i problemi relativi agli aggiornamenti di versione principali in Amazon RDS per PostgreSQL o Edizione compatibile con Aurora PostgreSQL?

Breve descrizione

Gli aggiornamenti delle versioni secondarie sono compatibili con le versioni secondarie precedenti e successive della stessa versione principale. Tuttavia, gli aggiornamenti delle versioni principali contengono modifiche al database che non sono retrocompatibili con le applicazioni esistenti. Questi aggiornamenti potrebbero modificare il formato interno delle tabelle di sistema, dei file di dati e dell'archiviazione di dati. Amazon RDS utilizza pg\ _upgrade per eseguire gli aggiornamenti delle versioni principali. Per ulteriori informazioni, consulta pg_upgrade sul sito web di 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 per il 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. Tuttavia, per problemi specifici del motore, è necessario controllare i file di log del database per Amazon RDS per PostgreSQL o Aurora PostgreSQL.

Risoluzione

L'utilità pg\ _upgrade che esegue gli aggiornamenti delle versioni principali produce due log: pg_upgrade_internal.log e pg_upgrade_server.log. Amazon RDS aggiunge un timestamp al nome file per questi log. Visualizza questi log per ottenere ulteriori informazioni sui problemi e gli errori che si sono verificati durante l'aggiornamento. Per ulteriori informazioni, consulta Monitoring Amazon RDS log files (Monitoraggio dei file di log di Amazon RDS) o Monitoring Amazon Aurora log files (Monitoraggio dei file di log di Amazon Aurora).

L'aggiornamento richiede molto tempo

Verifica delle attività di manutenzione in sospeso

Amazon RDS utilizza automaticamente gli aggiornamenti della versione del motore per applicare le attività di manutenzione in sospeso, come una patch del sistema operativo (OS) sull'istanza 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'istanza RDS è contenuta in un'implementazione multi-AZ, la manutenzione del sistema operativo genera un failover. Quando si configura l'istanza in 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 completa un backup completo anziché uno incrementale. Un backup completo può richiedere molto tempo, soprattutto se il database è di grandi dimensioni.

Per evitare questo problema, cerca le attività di manutenzione in sospeso per l'istanza database RDS o per l'istanza database Aurora. In alternativa, esegui il seguente comando describe-pending-maintenance-actions dell'interfaccia della linea di comando AWS (AWS CLI) sull'istanza:

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

Nota: sostituisci example-arn con l'ARN dell'istanza database. Se ricevi messaggi di errore quando esegui i comandi dell'interfaccia della linea di comando AWS (AWS CLI), consulta Troubleshooting errors for the AWS CLI (Risoluzione degli errori per AWS CLI). Inoltre, assicurati di utilizzare la versione più recente dell'interfaccia della linea di comando AWS (AWS CLI).

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

Creazione di uno snapshot prima dell'aggiornamento

Come best practice, crea uno snapshot dell'istanza database RDS o del cluster di database Aurora prima di aggiornare la versione. Se hai già attivato i backup per l'istanza, Amazon RDS crea automaticamente uno snapshot come parte del processo di aggiornamento. Lo snapshot consente di ridurre il tempo del processo di aggiornamento perché Amazon RDS deve solo creare un backup incrementale come parte dell'aggiornamento.

Attesa dell'aggiornamento della replica in lettura

Quando si esegue 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 di pg\ _upgrade sull'istanza database primaria. Quindi, l'aggiornamento dell'istanza database primaria attende il completamento degli aggiornamenti delle repliche in lettura. Finché tutti gli aggiornamenti non sono stati completati, si verifica un'interruzione. Se la finestra del tempo di inattività per l'aggiornamento è ridotta, promuovi o elimina l'istanza di replica, quindi ricrea le repliche in lettura al termine dell'aggiornamento.

Per i cluster di database Aurora, pg_upgrade aggiorna prima l'istanza di scrittura. Quindi, in ogni istanza database reader si verifica un'interruzione mentre pg\ _upgrade esegue l'aggiornamento alla nuova versione principale. Nota che se si aggiorna un database globale Aurora, ci sono ulteriori requisiti e processi.

Risoluzione di transazioni di lunga durata o 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 la seguente 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 query di lunga durata, utilizza pg\ _cancel\ _backend o pg_terminate_backend per terminare la query. Per ulteriori informazioni su queste funzioni, consulta 9.28.2. Server signaling functions.

Accertarsi di disporre di capacità di calcolo sufficiente

L'utilità pg\ _upgrade può richiedere molte risorse di calcolo. Come best practice, esegui un aggiornamento dry-run prima di aggiornare i database di produzione per verificare che la capacità di calcolo o di memoria sia sufficiente. L'aggiornamento dry-run controlla anche se si verificano errori di controllo preliminare o di aggiornamento. Puoi ripristinare uno snapshot dell'istanza di produzione ed eseguire un dry-run con la stessa classe di istanza del database di produzione.

Errore durante l'aggiornamento

Verifica della presenza di classi di istanza database non supportate

Se la classe di istanza dell'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 della presenza di transazioni aperte preparate

Se nel database sono presenti transazioni aperte preparate, l'aggiornamento non va a buon fine. Viene visualizzato il messaggio di errore There are uncommit prepared transactions nel file pg\ _upgrade.log. Effettua il commit o il ripristino di tutte le transazioni aperte preparate prima di avviare un aggiornamento.

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

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

Assicurarsi di utilizzare un tipo di dati supportato

Puoi aggiornare la versione solo per i tipi di dati regclass, 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 questo 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 la seguente 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 della presenza di slot di replica logica

Se l'istanza contiene slot di replica logica, non è possibile aggiornare l'istanza e nel file pg_upgrade.log viene visualizzato 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." (Non è stato possibile aggiornare l'istanza perché uno o più database hanno slot di replica logica. Eliminare tutti gli slot di replica logica e riprovare.)

Gli slot di replica logica sono in genere utilizzati 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 in uso per verificare se è possibile eliminarli. Se gli slot di replica logica sono in uso, non eliminarli. Prima di poter eliminare gli slot di replica logica, è necessario attendere l'aggiornamento della versione.

Se gli slot di replica logica non sono necessari, esegui le query seguenti 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 della presenza di problemi di archiviazione

Se l'istanza esaurisce lo spazio quando viene eseguito lo script pg_upgrade, l'aggiornamento non va a buon fine e viene visualizzato il seguente 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 è possibile utilizzare tipi di dati sconosciuti nelle versioni PostgreSQL 10 e successive. Ad esempio, se un database PostgreSQL versione 9.6 utilizza il tipo di dati sconosciuto, quando esegui l'aggiornamento alla versione 10 viene visualizzato il seguente 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.

Assicurarsi che il nome utente principale sia corretto

Se il nome utente principale inizia con pg_, l'aggiornamento non va a buon fine e viene visualizzato 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 della presenza di parametri incompatibili

L'errore parametri incompatibili si verifica quando il valore di un parametro correlato alla memoria, ad esempio shared\ _buffer o work\ _memory, è troppo alto per la configurazione. Questo errore causa un errore dello script di aggiornamento. Per risolvere il problema, riduci i valori di questi parametri, quindi esegui nuovamente l'aggiornamento.

Aggiornamento delle estensioni prima di eseguire l'aggiornamento

Gli aggiornamenti delle versioni principali non aggiornano le estensioni PostgreSQL. Se di un aggiornamento della versione principale le estensioni non vengono aggiornate, nel file pg_upgrade.log viene visualizzato un errore simile a quello del seguente esempio:

"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'errore di esempio precedente mostra un problema con l'estensione PostGIS. Per risolvere questo problema, esegui la seguente query per verificare le versioni predefinite e installate 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 l'estensione.

Se il valore per installed_version è inferiore al valore di default_version, è necessario aggiornare PostGIS alla versione predefinita. Per aggiornare l'estensione, esegui la seguente query:

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

Nota: sostituisci default_version_number con il valore default_version.

Per ulteriori informazioni, consulta Upgrades of the RDS for PostgreSQL DB engine (Aggiornamenti del motore di database RDS per PostgreSQL) o Upgrading Amazon Aurora PostgreSQL DB clusters (Aggiornamento dei cluster di database di Amazon Aurora PostgreSQL).

Verifica della presenza di problemi nelle viste causati da una modifica del catalogo di sistema della versione di destinazione

Le colonne di alcune viste variano a seconda delle versioni di PostgreSQL. Ad esempio, potresti ricevere un errore simile all'esempio 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 precedente, il problema è 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 errore simile all'esempio 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"."

In questo esempio, l'errore si verifica perché la struttura del catalogo pg\ _constraint è cambiata in PostgreSQL versione 12.

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

Importante: come best practice, utilizza pgdump per eseguire il backup delle viste o acquisire la definizione della vista prima di rimuoverla. Quando si elimina una vista, è necessario ricrearla manualmente dopo l'aggiornamento della versione. Potrebbe essere necessario collaborare con l'amministratore del database.

Dopo l'aggiornamento

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

Informazioni correlate

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