Come posso risolvere i problemi relativi agli aggiornamenti di versione principali in Amazon RDS per PostgreSQL e Aurora per PostgreSQL?
L'aggiornamento della versione del mio motore per Amazon Relational Database Service (Amazon RDS) per PostgreSQL o Amazon Aurora edizione compatibile con 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. Questi aggiornamenti di solito non aggiungono nuove funzionalità e non modificano il formato di archiviazione interno. Sono sempre compatibili con le versioni minori precedenti e successive della stessa versione principale. Tuttavia, gli aggiornamenti di versione principali contengono modifiche al database che non sono compatibili retroattivamente 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, Amazon RDS utilizza l'utilità pg_upgrade di PostgreSQL.
Durante un aggiornamento di versione principale di un'istanza PostgreSQL, Amazon RDS esegue una procedura di verifica preliminare. Questa procedura identifica eventuali problemi che potrebbero non consentire di completare l'aggiornamento. Ricerca la presenza di potenziali condizioni di incompatibilità in tutti i database. Se Amazon RDS identifica un problema durante il processo di verifica preliminare, crea un log eventi per la verifica preliminare non riuscita. Per ulteriori informazioni sul processo di verifica preliminare per tutti i database, consulta il log di aggiornamento di 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 log del database.
Per ulteriori informazioni, consulta la sezione Visualizzazione ed elenco dei file di log del database per RDS per PostgreSQL. Oppure, consulta la sezione Visualizzazione ed elenco dei file di log del database per Aurora per PostgreSQL.
Durante un aggiornamento di versione principale, RDS completa questi passaggi:
- 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.
- Chiude l'istanza.
- Utilizza la funzionalità pg_upgrade per eseguire il processo di aggiornamento sull'istanza.
- Crea un'istantanea dell'istanza dopo l'aggiornamento.
Risoluzione
Sebbene tali aggiornamenti siano gestiti da Amazon RDS, è possibile che durante un aggiornamento di versione si verifichino i seguenti problemi:
- L'aggiornamento richiede molto tempo.
- L'aggiornamento non riesce.
L'aggiornamento richiede molto tempo
Attività di manutenzione in sospeso: tutte le attività di manutenzione in sospeso vengono eseguite automaticamente con gli aggiornamenti della versione del motore. Ciò potrebbe includere l'applicazione di una patch del sistema operativo all'istanza RDS. In questo caso, prima viene applicata la patch del sistema operativo, quindi viene aggiornata la versione del motore. Pertanto, l'esecuzione delle 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 questo problema, cerca le attività di manutenzione in sospeso nella sezione Pending maintenance (Manutenzione in sospeso) della console RDS. Per Aurora per PostgreSQL, consulta la sezione Visualizzazione della manutenzione in sospeso.
In alternativa, utilizza il 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: completa queste attività di manutenzione prima di eseguire gli aggiornamenti della versione del motore del database.
Nessuno snapshot creato prima dell'aggiornamento: prima di eseguire l'aggiornamento, è consigliabile creare uno snapshot dello snapshot del cluster RDS o Aurora per PostgreSQL. Se hai già abilitato i backup per l'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 questo modo durante il processo di aggiornamento viene creato solo un backup incrementale.
Aggiornamenti delle repliche di lettura di RDS per PostgreSQL: quando esegui un aggiornamento di versione principale dell'istanza del database primaria, vengono aggiornate automaticamente 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 del 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, puoi promuovere o eliminare l'istanza di replica. Quindi, ricreate le repliche di lettura dopo il completamento dell'aggiornamento.
Per aggiornare in sicurezza le istanze del database che costituiscono il cluster, Aurora per PostgreSQL utilizza l'utilità pg_upgrade. Una volta completato l'aggiornamento dell'autore, ogni istanza del lettore subisce una breve interruzione durante l'aggiornamento alla nuova versione principale.
Transazioni a esecuzione prolungata o carico di lavoro elevato prima dell'aggiornamento: le transazioni a esecuzione prolungata o un carico di lavoro elevato prima dell'aggiornamento potrebbero aumentare il tempo necessario per chiudere il database e prolungare il tempo di aggiornamento.
Per identificare le transazioni a esecuzione prolungata, 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;
Capacità di calcolo insufficiente: la funzionalità pg_upgrade può richiedere un uso intensivo di calcolo. Pertanto, è consigliabile eseguire un aggiornamento di prova 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 l'elenco dei motori del database supportati per le classi di istanze del database per RDS per PostgreSQL. In alternativa, consulta l'elenco dei motori del database supportati per le classi di istanze del database per Aurora per PostgreSQL.
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.
Esegui questa 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 a questo:
------------------------------------------------------------------------ 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, rimuovi tutti i casi dei tipi di dati reg*, ad eccezione di regclass, regrole e regtype.
Esegui questa 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 vengono in genere utilizzati per la migrazione di AWS Database Migration Service (AMS DMS). Vengono anche utilizzati per replicare tabelle dai database ai 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 log pg_upgrade è simile a questo esempio:
"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 queste 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 l'insuccesso dello script e la visualizzazione di un messaggio di errore simile a questo:
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 iniziare l'aggiornamento.
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 unknown (sconosciuto), l'aggiornamento alla versione 10 presenta un messaggio di errore come questo:
"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 unknown (sconosciuto). Potrebbe essere necessario modificare manualmente tali colonne prima dell'aggiornamento.
Esegui questa query per trovare eventuali colonne nel tuo database con tipo di dati unknown (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 della replica di lettura (solo RDS per PostgreSQL): l'istanza PostgreSQL dispone di repliche di lettura, quindi gli errori di aggiornamento della replica di lettura potrebbero causare il blocco dell'aggiornamento dell'istanza primaria. L'errore di aggiornamento delle repliche di lettura potrebbe anche causare l'insuccesso dell'aggiornamento dell'istanza primaria. Una replica di lettura non riuscita viene posta nello stato incompatible-restore (ripristino incompatibile) e la replica viene terminata sull'istanza del database.
L'aggiornamento di una replica di lettura potrebbe non riuscire per uno di questi motivi:
- La replica di lettura non è in grado di recuperare il ritardo con l'istanza del 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-full (spazio di archiviazione pieno) o incompatible-restore (ripristino incompatibile).
- All'avvio dell'aggiornamento dell'istanza del database primaria, sulla replica di lettura è in esecuzione un aggiornamento di versione secondario separato.
- La replica di lettura utilizza parametri incompatibili.
- La replica di lettura non è in grado di comunicare con l'istanza del database primaria per sincronizzare la cartella dei dati.
Per risolvere questo problema, elimina la replica di lettura. Quindi, ricrea una nuova replica di lettura basata sull'istanza primaria aggiornata dopo l'aggiornamento dell'istanza primaria.
Nome dell'utente principale errato: se il nome dell'utente principale 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 principale.
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. Ciò può causare l'insuccesso 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 questo 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.
Esegui questa query per verificare le versioni predefinite e installate per PostGIS e le sue estensioni dipendenti:
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 è inferiore a quello di default_version, è necessario aggiornare la versione di PostGIS alla versione predefinita. Per fare ciò, esegui questa query:
ALTER EXTENSION extension_name UPDATE TO 'default_version_number';
Per ulteriori informazioni, consulta le sezioni Aggiornamento delle estensioni PostgreSQL per RDS per PostgreSQL o Aggiornamento delle estensioni PostgreSQL per Aurora 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, potresti visualizzare un messaggio di errore come questo:
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.
Puoi 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
- La funzionalità pg_upgrade produce due log: pg_upgrade_internal.log e pg_upgrade_server.log. Amazon RDS aggiunge un timestamp al nome del file per tali registri. Esamina i log per ottenere maggiori informazioni sui problemi e sugli errori riscontrati durante l'aggiornamento. Per ulteriori informazioni, consulta le sezioni Monitoraggio dei file di log di Amazon RDS per RDS per PostgreSQL oppure Monitoraggio dei file di log di Amazon Aurora per Aurora per PostgreSQL.
- 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 salti questo passaggio, le query potrebbero subire un rallentamento.
- Se hai effettuato l'aggiornamento alla versione 10 di PostgreSQL, esegui REINDEX su qualsiasi indice hash di cui disponi. Gli indici hash sono stati modificati nella versione 10 e devono essere ricostruiti. Per individuare indici hash non validi, esegui questo SQL per ogni database che contiene indici hash:
SELECT idx.indrelid::regclass AS table_name, idx.indexrelid::regclass AS index_name FROM pg_catalog.pg_index idx JOIN pg_catalog.pg_class cls ON cls.oid = idx.indexrelid JOIN pg_catalog.pg_am am ON am.oid = cls.relam WHERE am.amname = 'hash' AND NOT idx.indisvalid;
Informazioni correlate
Panoramica dell'aggiornamento di PostgreSQL
Panoramica dei processi di aggiornamento di Aurora PostgreSQL
Contenuto pertinente
- AWS UFFICIALEAggiornata 9 mesi fa