Come posso risolvere i problemi relativi agli aggiornamenti di versione principali in RDS per PostgreSQL?

Ultimo aggiornamento: 20/06/2022

L'aggiornamento di versione del motore per Amazon Relational Database Service (Amazon RDS) per PostgreSQL è bloccato o non è riuscito.

Breve descrizione

Quando Amazon RDS supporta una nuova versione di un motore di database, è possibile aggiornare le istanze database alla nuova versione. Per le istanze database si può eseguire un aggiornamento di versione di grado secondario o principale. Gli aggiornamenti di versione secondari vengono utilizzati per correggere vulnerabilità di sicurezza e bug. Tali aggiornamenti di solito non aggiungono alcuna nuova funzionalità. Le versioni secondarie non modificano il formato di archiviazione interno e sono sempre compatibili con le versioni secondarie precedenti e successive della medesima versione principale. Tuttavia, gli aggiornamenti di versione principali contengono modifiche al database che non sono retrocompatibili con le applicazioni esistenti. Tali aggiornamenti potrebbero modificare il formato interno delle tabelle di sistema, dei file di dati e dell'archiviazione di dati. Per eseguire gli aggiornamenti di versione principali, RDS utilizza la funzionalità pg_upgrade di PostgreSQL.

Durante il processo di aggiornamento di versione principale, Amazon RDS per PostgreSQL esegue una procedura di verifica preliminare per identificare eventuali problemi che potrebbero causare la non riuscita dell'aggiornamento. La procedura di verifica preliminare ricerca la presenza di potenziali condizioni di incompatibilità in tutti i database. Qualora venga rilevato un problema durante il processo di verifica preliminare, viene creato un registro eventi che indica la non riuscita della verifica preliminare dell'aggiornamento. È possibile trovare informazioni relative al processo di verifica preliminare per tutti i database nell'istanza nel registro di aggiornamento pg_upgrade_precheck.log. Amazon RDS aggiunge un timestamp al nome del file. Gli eventi RDS potrebbero anche fornire i motivi dell'errore dell'aggiornamento. Tuttavia, per problemi specifici del motore, è necessario controllare i file di registro del database. Per ulteriori informazioni, consulta Visualizzazione ed elenco dei file di log del database.

Durante un aggiornamento di versione principale, RDS completa le seguenti fasi:

  1. Crea uno snapshot dell'istanza prima dell'aggiornamento. Ciò avviene solo se si imposta il periodo di conservazione del backup per l'istanza database su un numero maggiore di zero.
  2. Chiude l'istanza.
  3. Utilizza la funzionalità pg_upgrade per eseguire il processo di aggiornamento sull'istanza.
  4. Crea un'istantanea dell'istanza dopo l'aggiornamento.

Risoluzione

Sebbene tali aggiornamenti siano gestiti da RDS, è possibile che durante un aggiornamento di versione si verifichino i seguenti problemi:

  • L'aggiornamento richiede più tempo.
  • L'aggiornamento non riesce.

L'aggiornamento richiede più tempo

Attività di manutenzione in sospeso: eventuali attività di manutenzione in sospeso, come l'applicazione di una patch del sistema operativo sull'istanza RDS, vengono implementate automaticamente insieme agli aggiornamenti di versione del motore. In tal caso, la patch del sistema operativo viene applicata per prima, seguita dall'aggiornamento di versione. Pertanto, l'esecuzione di attività di manutenzione del sistema operativo comporta un prolungamento del tempo necessario per completare l'aggiornamento.

Inoltre, se l'istanza RDS è in un'implementazione multi-AZ, la manutenzione del sistema operativo comporta un failover. Quando si configura l'istanza in multi-AZ, il backup per l'istanza viene solitamente creato sull'istanza secondaria. In caso di failover, dopo l'aggiornamento viene creato un backup su una nuova istanza secondaria. Questo backup sulla nuova istanza secondaria potrebbe non essere il più recente. Pertanto, potrebbe essere innescato un backup completo anziché un backup incrementale. La creazione di un backup completo può richiedere molto tempo, soprattutto se il database è molto grande.

Per evitare tale problema, assicurati di cercare le attività di manutenzione in sospeso nella sezione Manutenzione in sospeso nella scheda Manutenzione e backup all'interno della console RDS. In alternativa, utilizza il comando describe-pending-maintenance-actions dell'Interfaccia della linea di comando AWS (AWS CLI) sulla tua istanza.

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

Assicurati di completare queste attività di manutenzione prima di eseguire gli aggiornamenti di versione del motore di database.

Nessuno snapshot creato prima dell'aggiornamento: prima di eseguire l'aggiornamento, è consigliabile creare uno snapshot dell'istanza di RDS. Se hai già abilitato i backup per la tua istanza, uno snapshot viene creato in automatico contestualmente al processo di aggiornamento. La creazione di uno snapshot prima dell'aggiornamento riduce il tempo necessario per il completamento del processo di aggiornamento, perché in tal caso durante il processo viene creato solo un backup incrementale.

Aggiornamenti delle repliche di lettura: quando si esegue un aggiornamento di versione principale dell'istanza database primaria, vengono aggiornate automaticamente anche tutte le repliche di lettura nella stessa regione. Dopo l'avvio del flusso di lavoro di aggiornamento, le repliche di lettura attendono il completamento di pg_upgrade sull'istanza database primaria. Successivamente, l'aggiornamento dell'istanza primaria attende il completamento degli aggiornamenti delle repliche di lettura. Si verifica un'interruzione fino al completamento di tutti gli aggiornamenti. Se la finestra di inattività per l'aggiornamento è limitata, è possibile promuovere o eliminare l'istanza di replica e ricreare le repliche di lettura dopo il completamento dell'aggiornamento.

Transazioni a esecuzione prolungata o carico di lavoro elevato prima dell'aggiornamento: le transazioni a esecuzione prolungata o un carico di lavoro elevato in esecuzione sul database appena prima dell'aggiornamento potrebbero aumentare il tempo necessario per chiudere il database e sommarsi al tempo di aggiornamento.

Per identificare le transazioni a esecuzione prolungata, 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;

Capacità di calcolo insufficiente: la funzionalità pg_upgrade può richiedere un uso intensivo di calcolo. Pertanto, è consigliabile eseguire un aggiornamento di test prima di aggiornare i database di produzione. È possibile ripristinare uno snapshot dell'istanza di produzione ed eseguire un test con la stessa classe di istanza del database di produzione.

L'aggiornamento non riesce

Classi di istanze database non supportate: l'aggiornamento potrebbe non riuscire se la classe di istanza dell'istanza database non è compatibile con la versione di PostgreSQL a cui si sta eseguendo l'aggiornamento. Assicurati di verificare la compatibilità della classe di istanza con la versione del motore. Per ulteriori informazioni, consulta Motori DB supportati per classi di istanza database.

Transazioni preparate aperte: le transazioni preparate aperte sul database potrebbero causare errori di aggiornamento. Prima di avviare un aggiornamento, assicurati di eseguire il commit o il rollback di tutte le transazioni preparate aperte.

Utilizza la seguente query per verificare se la tua istanza presenta transazioni preparate aperte:

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

In tal caso, l'errore nel file pg_upgrade.log è simile al seguente:

------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with 
the requested major engine version upgrade and try the upgrade again.

*There are uncommitted prepared transactions. Please commit or rollback 
all prepared transactions.*

Tipi di dati non supportati: l'aggiornamento non riesce e si verifica un errore se si tenta di aggiornare il database con tipi di dati non supportati, ad esempio i seguenti:

  • regcollation
  • regconfig
  • regdictionary
  • regnamespace
  • regoper
  • regoperator
  • regproc
  • regprocedure

Nota: i tipi di dati regclass, regrole e regtype sono supportati.

La funzionalità di aggiornamento PostgreSQL pg_upgrade non supporta l'aggiornamento di database comprensivi di colonne di tabelle che utilizzano i tipi di dati di sistema di riferimento OID reg*. Prima di tentare un aggiornamento, assicurati di rimuovere tutti gli usi dei tipi di dati reg*, ad eccezione di regclass, regrole e regtype.

Esegui la seguente query per verificare l'utilizzo di tipi di dati reg* non supportati:

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');

Slot di replica logica: non è possibile eseguire un aggiornamento se l'istanza presenta slot di replica logica. Gli slot di replica logica sono in genere utilizzati per la migrazione di AWS Database Migration Service (AMS DMS) e per la replica di tabelle da database a data lake, strumenti di business intelligence e altre destinazioni. Prima di eseguire l'aggiornamento, assicurati di conoscere lo scopo degli slot di replica logica in uso e controlla che possano essere eliminati.

Se gli slot di replica logica sono ancora in uso, non devi eliminarli. In tal caso, non è possibile procedere con l'aggiornamento.

L'errore correlato nel file di registro pg_upgrade è simile al seguente:

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

Se gli slot di replica logica non sono necessari, esegui le seguenti query per eliminarli:

SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);

Problemi di archiviazione: durante l'esecuzione dello script pg_upgrade, l'istanza potrebbe esaurire lo spazio. Ciò determina la non riuscita dello script e la visualizzazione di un messaggio di errore simile al seguente:

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 tale problema, prima di iniziare l'aggiornamento, assicurati che l'istanza disponga di spazio di archiviazione sufficiente a seconda del numero di database e file di dati.

Tipi di dati sconosciuti: le versioni 10 e successive di PostgreSQL non supportano tipi di dati sconosciuti. Se un database PostgreSQL versione 9.6 utilizza il tipo di dati sconosciuto, l'aggiornamento alla versione 10 presenta un messaggio di errore simile al seguente:

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

Si tratta di una limitazione di PostgreSQL e l'automazione RDS non modifica le colonne che utilizzano il tipo di dati sconosciuto. Potrebbe essere necessario modificare manualmente tali colonne prima dell'aggiornamento.

Esegui la seguente query per trovare eventuali colonne nel tuo database con tipo di dati sconosciuto:

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

Dopo aver identificato le colonne, puoi rimuoverle o modificarle in un tipo di dati supportato.

Errore di aggiornamento delle repliche di lettura: se l'istanza RDS dispone di repliche di lettura, eventuali errori di aggiornamento delle repliche di lettura potrebbero causare il blocco dell'aggiornamento dell'istanza primaria. L'errore di aggiornamento delle repliche di lettura potrebbe anche causare il fallimento dell'aggiornamento dell'istanza primaria. Una replica di lettura non riuscita viene posta nello stato ripristino incompatibile e la replica viene terminata sull'istanza database.

Un aggiornamento delle repliche di lettura potrebbe non riuscire per i seguenti motivi:

  • La replica di lettura non è stata in grado di recuperare il ritardo con l'istanza database primaria anche dopo il tempo di attesa.
  • La replica di lettura si trovava in uno stato del ciclo di vita terminale o incompatibile: ad esempio storage pieno o ripristino incompatibile.
  • All'avvio dell'aggiornamento dell'istanza database primaria, sulla replica di lettura era in esecuzione un aggiornamento di versione secondario separato.
  • La replica di lettura utilizzava parametri incompatibili.
  • La replica di lettura non è stata in grado di comunicare con l'istanza database primaria per sincronizzare la cartella dati.

Per risolvere tale problema, è possibile eliminare la replica di lettura e ricreare una nuova replica di lettura basata sull'istanza primaria aggiornata dopo l'aggiornamento dell'istanza primaria.

Nome utente master errato: se il nome utente master inizia con "pg_", l'aggiornamento non riesce 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 tale problema, crea un altro utente con il ruolo rds_superuser. Puoi contattare il Supporto AWS per aggiornare l'utente come nuovo utente master.

Errore relativo a un parametro non compatibile: questo errore si verifica se un parametro relativo alla memoria, ad esempio shared_buffer o work_memory, è impostato su un valore superiore e ha causato un errore dello script di aggiornamento. Per risolvere il problema, riduci i valori di tali parametri e prova a eseguire nuovamente l'aggiornamento.

Estensioni non aggiornate prima dell'aggiornamento: un aggiornamento di versione principale non aggiorna alcuna estensione PostgreSQL. Se non hai aggiornato le estensioni prima di eseguire un aggiornamento di versione principale, il file pg_upgrade.log presenta il seguente errore:

The Logs indicates that the RDS instance ''xxxx'' 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.

Questo messaggio di errore indica un problema con l'estensione PostGIS.

In tal caso, verifica le versioni predefinite e installate per PostGIS e le sue estensioni dipendenti eseguendo la seguente query:

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

Se il valore di installed_version è minore di quello di default_version, è necessario aggiornare la versione installata di PostGIS e della sua estensione dipendente alla versione predefinita. A tale scopo, esegui la seguente query:

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

Per ulteriori informazioni, consulta Aggiornamento estensioni PostgreSQL.

Problema nelle viste a causa di modifiche nel catalogo di sistema della versione di destinazione: le colonne in determinate viste variano tra le diverse versioni di PostgreSQL.

Ad esempio, potrebbero essere visualizzati messaggi di errore simili 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.

Tale errore si verifica quando si aggiorna il database dalla versione 9.5 alla versione 9.6. L'errore è causato dalla vista pg_stat_activity, perché nella versione 9.6 la colonna waiting viene sostituita con le colonne wait_event_type e wait_event.

pg_restore: from TOC entry xxx; xxx xxxx 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'errore si verifica perché la struttura del catalogo pg_constraint è cambiata nella versione 12 di PostgreSQL.

È possibile risolvere tali problemi eliminando le viste basate sui cataloghi di sistema della versione di destinazione.

Nota: presta attenzione quando elimini tali viste. Assicurati di consultare l'amministratore del database.

Altre considerazioni

  • Assicurati di seguire le indicazioni Best practice per l'aggiornamento di Amazon RDS alle versioni principale e secondarie di PostgreSQL per ridurre la maggior parte dei problemi che potrebbero verificarsi durante gli aggiornamenti di versione del motore per le istanze RDS per PostgreSQL.
  • La funzionalità pg_upgrade produce due registri: pg_upgrade_internal.log e pg_upgrade_server.log. Amazon RDS aggiunge un timestamp al nome del file per tali registri. Esamina i registri per ottenere maggiori informazioni sui problemi e sugli errori riscontrati durante l'aggiornamento. Per ulteriori informazioni, consulta Monitoraggio dei file di log di Amazon RDS.
  • Al termine dell'aggiornamento, aggiorna la tabella pg_statistics eseguendo ANALYZE su tutti i database utente. Un aggiornamento principale non trasferisce il contenuto della tabella pg_statistics alla nuova versione. Se si salta tale fase, le query potrebbero subire un rallentamento.

Questo articolo è stato utile?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?