Esecuzione di un aggiornamento della versione principale

Scegli la versione principale desiderata dall'elenco delle destinazioni disponibili tra quelle elencate per la versione nella tabella. È possibile ottenere un elenco preciso delle versioni disponibili nella Regione AWS versione corrente utilizzando il AWS CLI. Per informazioni dettagliate, consultare Ottenere un elenco di versioni disponibili nel Regione AWS.

Verifica che le applicazioni funzionino come previsto su un'implementazione di prova della nuova versione. Per informazioni sul processo completo, consulta Test di un aggiornamento del cluster database di produzione a una nuova versione principale.

Dopo aver verificato che le applicazioni funzionano come previsto nell'implementazione di prova, puoi aggiornare il cluster. Per informazioni dettagliate, consultare Aggiornamento del motore Aurora PostgreSQL a una nuova versione principale.

Tieni a portata di mano un gruppo di parametri compatibile con la versione.

Se utilizzi un'istanza database personalizzata o un gruppo di parametri del cluster database, puoi scegliere tra due opzioni:

Se associ una nuova istanza database o gruppo di parametri del cluster di database come una parte della richiesta di aggiornamento, devi riavviare il database al termine dell'aggiornamento per applicare i parametri. Se, per applicare le modifiche del gruppo di parametri, un'istanza deve essere riavviata, lo stato del gruppo di parametri è pending-reboot. È possibile visualizzare lo stato del gruppo di parametri dell'istanza nella console oppure utilizzando un comando CLI come describe-db-instances o describe-db-clusters.

Verifica la presenza di database non validi ed elimina quelli esistenti.

La datconnlimit colonna del pg_database catalogo include il valore -2 per contrassegnare come non validi tutti i database che sono stati interrotti durante un'operazione. DROP DATABASE Utilizzate la seguente query per verificare se esistono database non validi.

SELECT
    datname
FROM
    pg_database
WHERE
    datconnlimit = - 2;

Se la query restituisce nomi di database, questi database non sono validi. Utilizzate l'DROP DATABASE invalid_db_nameistruzione per eliminare i database non validi. È possibile utilizzare la seguente istruzione dinamica per eliminare tutti i database non validi.

SELECT
    'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
    pg_database
WHERE
    datconnlimit = -2 \gexec

Controllare l'utilizzo non supportato:

Controllare i database template1 e template0.

Per un aggiornamento corretto, i database template1 e template0 devono esistere e devono essere elencati come modello. Per eseguire questa verifica, utilizzare il seguente comando:

SELECT datname, datistemplate FROM pg_database; 
                        
datname    | datistemplate
-----------+---------------
template0  | t
rdsadmin   | f
template1  | t
postgres   | f

Nell'output del comando, il valore datistemplate per i database template1 e template0 deve essere t.

Rimuovi slot di replica logica.

Il processo di aggiornamento non può continuare se il cluster database Aurora PostgreSQL utilizza slot di replica logici. Gli slot di replica logica vengono in genere utilizzati per attività di migrazione dei dati a breve termine, come la migrazione dei dati utilizzando AWS DMS o per replicare tabelle dal database ai data lake, agli strumenti di BI o ad altre destinazioni. Prima di eseguire l'aggiornamento, assicurati di conoscere lo scopo degli eventuali slot di replica logica esistenti e verifica che sia corretto eliminarli. Puoi verificare gli slot di replica logica utilizzando la seguente query:

SELECT * FROM pg_replication_slots;

Se gli slot di replica logica sono ancora in uso, non devono essere eliminati e non è possibile procedere con l'aggiornamento. Tuttavia, se gli slot di replica logica non sono necessari, è possibile eliminarli utilizzando il seguente SQL:

SELECT pg_drop_replication_slot(slot_name);

Negli scenari di replica logica che utilizzano l'estensione pglogical devono inoltre essere eliminati gli slot dal nodo publisher per un corretto aggiornamento della versione principale su quel nodo. Tuttavia, è possibile riavviare il processo di replica dal nodo sottoscrittore dopo l'aggiornamento. Per ulteriori informazioni, consulta Riconnessione della replica logica dopo un aggiornamento principale.

Eseguire un backup.

Il processo di aggiornamento crea uno snapshot del cluster di database durante l'aggiornamento. Se desideri eseguire anche un backup manuale prima del processo di aggiornamento, consulta Creazione di uno snapshot del cluster database per ulteriori informazioni.

Aggiornare alcune estensioni alla versione più recente disponibile prima di eseguire l'aggiornamento della versione principale. Le estensioni da aggiornare includono le seguenti:

Esegui il comando seguente per ogni estensione attualmente installata.

ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';

Per ulteriori informazioni, consulta Aggiornamento estensioni PostgreSQL. Per ulteriori informazioni sull'aggiornamento di PostGIS, consulta Passaggio 6: Aggiorna l'GISestensione Post.

Se si esegue l'aggiornamento alla versione 11.x, eliminare le estensioni che non supporta prima di eseguire l'aggiornamento della versione principale. Le estensioni da eliminare includono:

Eliminare i tipi di dati unknown, a seconda della versione di destinazione.

La versione 10 di PostgreSQL non supporta il tipo di dati unknown. Se un database versione 9.6 utilizza il tipo di dati unknown, un aggiornamento alla versione 10 mostra un messaggio di errore del tipo seguente:

Database instance is in a state that cannot be upgraded: PreUpgrade checks failed: 
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 trovare il tipo di dati unknown nel database in modo da poter rimuovere tali colonne o modificarle in un tipo di dati supportato, utilizza il seguente codice SQL per ciascun database.

SELECT n.nspname, c.relname, a.attname
    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 = 'pg_catalog.unknown'::pg_catalog.regtype AND
    c.relkind IN ('r','m','c') AND
    c.relnamespace = n.oid AND
    n.nspname !~ '^pg_temp_' AND
    n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema');

Esegui un aggiornamento di prova.

Si consiglia di testare un aggiornamento della versione principale su un duplicato del database di produzione prima di eseguire l'aggiornamento sul database di produzione. È possibile monitorare i piani di esecuzione sull'istanza di test duplicata per eventuali regressioni del piano di esecuzione e valutarne le prestazioni. Per creare un'istanza di test duplicata, è possibile ripristinare il proprio database da uno snapshot recente o clonare il database. Per ulteriori informazioni, consulta Ripristino da uno snapshot o Clonazione di un volume per un cluster di database Amazon Aurora.

Per ulteriori informazioni, consulta Aggiornamento del motore Aurora PostgreSQL a una nuova versione principale.

Aggiornare la propria istanza di produzione.

Dopo aver testato correttamente l'aggiornamento a una versione principale, dovrebbe essere possibile aggiornare il database di produzione senza problemi. Per ulteriori informazioni, consulta Aggiornamento del motore Aurora PostgreSQL a una nuova versione principale.

Per informazioni su un aggiornamento in corso, è possibile utilizzare Amazon RDS per visualizzare due log prodotti dall'utilità. Questi sono pg_upgrade_internal.log e pg_upgrade_server.log. Amazon Aurora RDS accoda un timestamp al nome file per questi log. Puoi visualizzare questi log come qualsiasi altro log. Per ulteriori informazioni, consulta Monitoraggio dei file di log di Aurora.

Aggiornare le estensioni PostgreSQL. Un processo di aggiornamento PostgreSQL non aggiorna alcuna estensione PostgreSQL. Per ulteriori informazioni, consulta Aggiornamento estensioni PostgreSQL.