Aggiornamento dei cluster database Amazon Aurora PostgreSQL

Amazon Aurora rende disponibili nuove versioni del motore di database PostgreSQL in Regioni AWS solo dopo test approfonditi. Puoi aggiornare i cluster database Aurora PostgreSQL alla nuova versione quando è disponibile nella tua regione.

A seconda della versione di Aurora PostgreSQL attualmente in esecuzione sul cluster database, un aggiornamento alla nuova versione è un aggiornamento secondario o principale. Ad esempio, l'aggiornamento di un cluster database Aurora PostgreSQL 11.15 ad Aurora PostgreSQL 13.6, è un aggiornamento della versione principale. L'aggiornamento di un cluster database Aurora PostgreSQL 13.3 ad Aurora PostgreSQL 13.7, è un aggiornamento della versione secondaria. Negli argomenti seguenti sono disponibili informazioni su come eseguire entrambi i tipi di aggiornamenti.

Indice

• Panoramica dei processi di aggiornamento di Aurora PostgreSQL
• Ottenere un elenco delle versioni disponibili nel tuo Regione AWS
• Come eseguire l'aggiornamento a una versione principale
  • Test di un aggiornamento del cluster database di produzione a una nuova versione principale
  • Aggiornamento del motore Aurora PostgreSQL a una nuova versione principale
    • Principali aggiornamenti per database globali
• Prima di eseguire un aggiornamento di una versione minore
• Come eseguire aggiornamenti della versione secondaria e applicare patch
  • Aggiornamenti della versione secondaria e applicazione di patch senza tempi di inattività
  • Aggiornamento del motore Aurora PostgreSQL a una nuova versione secondaria
• Aggiornamento estensioni PostgreSQL
• Tecnica alternativa di aggiornamento blu/verde

Panoramica dei processi di aggiornamento di Aurora PostgreSQL

Le differenze tra aggiornamenti della versione principale e secondaria sono le seguenti:

Aggiornamenti della versione secondaria e patch

Aggiornamenti della versione secondaria e patch includono solo le modifiche compatibili con le versioni precedenti delle applicazioni esistenti. Gli aggiornamenti della versione secondaria e patch diventano disponibili solo dopo i test Aurora PostgreSQ e l'approvazione.

Aggiornamenti della versione secondaria possono essere applicati automaticamente da Aurora. Quando crei un nuovo cluster database Aurora PostgreSQL, l'opzione Enable minor version upgrade (Abilita aggiornamento versione secondaria) è preselezionata. A meno che questa opzione non venga disattivata, gli aggiornamenti della versione secondaria vengono applicati automaticamente durante la finestra di manutenzione pianificata. Per ulteriori informazioni sull'opzione Aggiornamento automatico delle versioni minori (AmVU) e su come modificare il cluster database Aurora per utilizzarla, consulta Aggiornamenti automatici delle versioni secondarie per cluster DB Aurora.

Se l'opzione di aggiornamento automatico della versione secondaria non è impostata per il cluster database Aurora PostgreSQL, Aurora PostgreSQL non viene automaticamente aggiornato alla nuova versione secondaria. Invece, quando viene rilasciata una nuova versione secondaria nel tuo cluster Aurora PostgreSQL DB Regione AWS e ne esegue una versione secondaria precedente, Aurora ti chiede di eseguire l'aggiornamento. A questo scopo, viene aggiunto un suggerimento alle attività di manutenzione per il cluster.

Le patch non sono considerate un aggiornamento e non vengono applicate automaticamente. Aurora PostgreSQL richiede di applicare eventuali patch aggiungendo una raccomandazione alle attività di manutenzione per il cluster database Aurora PostgreSQL. Per ulteriori informazioni, consulta Come eseguire aggiornamenti della versione secondaria e applicare patch.

Nota

Anche le patch che risolvono la sicurezza o altri problemi critici vengono aggiunte come attività di manutenzione. Tuttavia, queste patch sono obbligatorie. Assicurati di applicare le patch di sicurezza al cluster database Aurora PostgreSQL quando diventano disponibili nelle attività di manutenzione in sospeso.

Il processo di aggiornamento implica la possibilità di brevi interruzioni poiché ogni istanza nel cluster viene aggiornata alla nuova versione. Tuttavia, dopo Aurora PostgreSQL versioni 14.3.3, 13.7.3, 12.11.3, 11.16.3, 10.21.3 e altre versioni successive di queste versioni secondarie e delle versioni principali più recenti, il processo di aggiornamento utilizza la funzionalità di applicazione di patch senza tempi di inattività (ZDP). Questa funzionalità riduce al minimo le interruzioni e nella maggior parte dei casi le elimina completamente. Per ulteriori informazioni, consulta Aggiornamenti della versione secondaria e applicazione di patch senza tempi di inattività.

Nota

ZDP non è supportato nei seguenti casi:

• Quando i cluster database Aurora PostgreSQL sono configurati come Aurora Serverless v1.

• Quando i cluster Aurora PostgreSQL DB sono configurati come database globale Aurora nel database secondario. Regioni AWS

• Durante l'aggiornamento delle istanze di lettura nel database globale Aurora.

• Durante le patch e gli aggiornamenti del sistema operativo.

ZDP è supportato per i cluster Aurora PostgreSQL DB configurati come. Aurora Serverless v2

Aggiornamenti di una versione principale

A differenza degli aggiornamenti della versione secondaria e delle patch, Aurora PostgreSQL non dispone di un'opzione di aggiornamento automatico della versione principale. Nuove versioni PostgreSQL principali potrebbero contenere modifiche al database non compatibili con le versioni precedenti delle applicazioni esistenti. La nuova funzionalità può causare l'interruzione del corretto funzionamento delle applicazioni esistenti.

Per evitare problemi, è fortemente consigliato seguire il processo descritto in Test di un aggiornamento del cluster database di produzione a una nuova versione principale prima di aggiornare le istanze database nei cluster database Aurora PostgreSQL. Assicurati innanzitutto che le applicazioni possano essere eseguite sulla nuova versione seguendo tale procedura. Quindi, puoi aggiornare manualmente il cluster database Aurora PostgreSQL alla nuova versione.

Il processo di aggiornamento prevede la possibilità di una breve interruzione quando tutte le istanze del cluster vengono aggiornate alla nuova versione. Anche il processo di pianificazione preliminare richiede tempo. Si consiglia di eseguire sempre attività di aggiornamento durante la finestra di manutenzione del cluster o quando le operazioni sono minime. Per ulteriori informazioni, consulta Come eseguire l'aggiornamento a una versione principale.

Nota

Gli aggiornamenti della versione secondaria e quelli della versione principale potrebbero entrambi comportare brevi interruzioni. Per questo motivo, è fortemente consigliato eseguire o pianificare gli aggiornamenti durante la finestra di manutenzione o durante altri periodi di scarso utilizzo.

I cluster di database Aurora PostgreSQL richiedono occasionalmente gli aggiornamenti del sistema operativo. Questi aggiornamenti a volte includono una nuova versione della libreria glibc. Durante gli aggiornamenti, ti consigliamo di seguire le linee guida descritte in Regole di confronto supportate in Aurora PostgreSQL.

Ottenere un elenco delle versioni disponibili nel tuo Regione AWS

È possibile ottenere un elenco di tutte le versioni del motore disponibili come obiettivi di aggiornamento per il cluster Aurora PostgreSQL DB eseguendo una query utilizzando il comando, come segue. Regione AWS describe-db-engine-versions AWS CLI

Per, o: Linux macOS Unix

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
  --output text

Per Windows:

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
  --output text

Ad esempio, per identificare gli obiettivi di aggiornamento validi per un cluster DB Aurora PostgreSQL versione 12.10, esegui il comando seguente: AWS CLI

Per, o: Linux macOS Unix

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version 12.10 \
  --query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
  --output text

Per Windows:

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version 12.10 ^
  --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
  --output text

Nella tabella sono disponibili le destinazioni degli aggiornamenti della versione principale e secondaria per varie versioni di database Aurora PostgreSQL.

Versione di origine corrente	Destinazioni di aggiornamento
16.1	16,2
15,6	16,2
15,5	16,2	16,1	15,6
15,4	16,2	16,1	15,6	15,5
15,3	16,2	16,1	15,6	15,5	15,4
15,2	16,2	16,1	15,6	15,5	15,4	15,3
14,11	16,2	15,6
14,10	16,2	16,1	15,6	15,5
14,9	16,2	16,1	15,6	15,5	15,4	14,11	14,10
14,8	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9
14,7	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8
14,6	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7
14,5	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	14,6
14,4	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	14,6	14,5
14,3	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	14,6	14,5	14,4
13,14	16,2	15,6	14,11
13,13	16,2	16,1	15,6	15,5	14,11	14,10
13,12	16,2	16,1	15,6	15,5	15,4	14,11	14,10	14,9
13,11	16,2	16,1	15,6	15,5	15,4	15,3	14,11	14,10	14,9	14,8
13,10	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	13,14	13,13	13,12	13,11
13,9	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	14,6	13,14	13,11	13,10
13,8	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	14,6	14,5	13,14	13,13	13,12	13,11	13,10	13,9
13,7	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	14,6	14,5	14,4	14,3	13,14	13,13	13,12	13,11	13,10	13,9	13,8
12,18	16,2	15,6	14,11	13,14
12,17	16,2	16,1	15,6	15,5	14,11	14,10	13,13
12,16	16,2	16,1	15,6	15,5	15,4	14,11	14,10	14,9	13,14	13,13	13,12
12,15	16,2	16,1	15,6	15,5	15,4	15,3	14,11	14,10	14,9	14,8	13,14	13,13	13,12	13,11
12,14	16,2	16,1	15,6	15,5	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	13,14	13,13	13,12	13,11	13,10	12,15
12,13	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	14,6	13,14	13,13	13,12	13,11	13,10	13,9	12,17	12,16	12,15	12,14
12,12	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	14,6	14,5	13,14	13,13	13,12	13,11	13,10	13,9	12,17	12,16	12,15	13,8	12,15	12,14	12,13
12,11	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	14,5	14,4	14,3	13,14	13,13	13,12	13,11	13,10	13,9	13,8	13,7	12,15	12,14	12,13	12,12
12,9	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	13,14	13,13	13,12	13,11	13,10	13,9	13,8	13,7	12,17	12,16	12,15	12,14	12,13	12,12	12,11
11,21	16,2	16,1	15,6	15,5	15,4	14,11	14,10	14,9	13,14	13,13	13,12	12,17	12,16
11.9	16,2	16,1	15,6	15,5	15,4	15,3	15,2	14,11	14,10	14,9	14,8	14,7	14,6	13,14	13,13	13,12	13,11	13,10	13,9	12,17	12,16	12,15	12,14	12,13	12,12	12,11	12,09	11,21

Per qualsiasi versione che stai considerando, controlla sempre la disponibilità della classe di istanza database del cluster. Ad esempio, db.r4 non è supportato per Aurora PostgreSQL 13. Se il tuo cluster database Aurora PostgreSQL utilizza attualmente una classe di istanza db.r4, devi passare a db.r5 prima di provare a eseguire l'aggiornamento. Per ulteriori informazioni sulle classi di istanza database, tra cui quali sono basate su Graviton2 e quali su Intel, consulta Aurora Classi di istanze database.

Come eseguire l'aggiornamento a una versione principale

Gli aggiornamenti a una versione principale potrebbero contenere modifiche al database non compatibili con le versioni precedenti del database. La nuova funzionalità in una nuova versione può causare l'interruzione del funzionamento corretto delle applicazioni esistenti. Per evitare problemi, Amazon Aurora non applica automaticamente aggiornamenti alla versione principale. Si consiglia, invece, di pianificare attentamente un aggiornamento alla versione principale seguendo questi passaggi:

1. 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, vedi Ottenere un elenco delle versioni disponibili nel tuo Regione AWS.

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

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

Nota

È possibile eseguire un aggiornamento della versione principale da Babelfish per Aurora PostgreSQL dalle versioni di Aurora PostgreSQL 13 a partire dalla 13.6 alle versioni di Aurora PostgreSQL 14 a partire dalla 14.6. Babelfish per Aurora PostgreSQL 13.4 e 13.5 non supporta l'aggiornamento della versione principale.

È possibile ottenere un elenco delle versioni del motore disponibili come obiettivi di aggiornamento delle versioni principali per il cluster Aurora PostgreSQL DB interrogando l'utente utilizzando il comando, come segue. Regione AWS describe-db-engine-versions AWS CLI

Per, o: Linux macOS Unix

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \
  --output text

Per Windows:

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}" ^
  --output text

In alcuni casi, la versione di destinazione dell'aggiornamento non è una destinazione per la versione corrente. In questi casi, utilizza le informazioni contenute in versions table per eseguire aggiornamenti della versione secondaria fino a quando la versione del cluster non dispone della destinazione scelta nella relativa riga di destinazioni.

Test di un aggiornamento del cluster database di produzione a una nuova versione principale

Ogni nuova versione principale include miglioramenti all'ottimizzatore di query progettati per migliorare le prestazioni. Tuttavia, il carico di lavoro può includere query che restituiscono prestazioni peggiori nella nuova versione. Ecco perché ti consigliamo di testare e rivedere le prestazioni prima di eseguire l'aggiornamento in produzione. È possibile gestire la stabilità del piano di query tra le varie versioni utilizzando l'estensione Query Plan Management (QPM), come descritto in Garantire la stabilità del piano dopo un aggiornamento di versione principale.

Prima di aggiornare i cluster database Aurora PostgreSQL di produzione a una nuova versione principale, è fortemente consigliato eseguire il test dell'aggiornamento per verificare che tutte le applicazioni funzionino correttamente:

1. 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:

   1. Puoi specificare l'istanza database predefinita, il gruppo di parametri del cluster di database o entrambi per la nuova versione del motore di database.

   2. Oppure è possibile creare un gruppo di parametri personalizzato per la nuova versione del motore database.

   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 di un'istanza nella console o utilizzando un comando CLI come describe-db-instanceso. describe-db-clusters

2. Controllare l'utilizzo non supportato:

   • Eseguire il commit o il rollback di tutte le transazioni preparate aperte prima di provare a eseguire un aggiornamento. È possibile utilizzare la seguente query per verificare che sull'istanza non siano presenti transazioni preparate aperte.

     SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

   • Rimuovere tutti gli utilizzi dei tipi di dati reg* prima di tentare un aggiornamento. Ad eccezione di regtype e regclass, non è possibile aggiornare i tipi di dati reg*. L’utilità pg_upgrade (utilizzata da Amazon Aurora per eseguire l'aggiornamento) non può preservare questo tipo di dati. Per ulteriori informazioni su questa utilità, consulta pg_upgrade nella documentazione di PostgreSQL.

     Per verificare che non siano presenti utilizzi di tipi di dati reg* non supportati, utilizzare la query seguente per ogni database.

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

   • Se stai eseguendo l'aggiornamento di un cluster di database Aurora PostgreSQL versione 10.18 o successive e l’estensione pgRouting è installata, rimuovila prima di eseguire l'aggiornamento alla versione 12.4 o successive.

     Se stai eseguendo l'aggiornamento di Aurora PostgreSQL 10.x che ha l'estensione pg_repack versione 1.4.3 installata, rimuovi l'estensione prima di eseguire l'aggiornamento a una versione successiva.

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

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

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

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

   • pgRouting

   • postgis_raster

   • postgis_tiger_geocoder

   • postgis_topology

   • address_standardizer

   • address_standardizer_data_us

   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: Aggiornamento dell'estensione PostGIS.

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

   • chkpass

   • tsearch2

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

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

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

    Nota

    Durante il processo di aggiornamento, Aurora PostgreSQL acquisisce uno snapshot cluster DB se il periodo di conservazione del backup del cluster è maggiore di 0. Non è possibile eseguire un point-in-time ripristino del cluster durante questo processo. Successivamente, puoi eseguire un point-in-time ripristino ai tempi precedenti all'inizio dell'aggiornamento e dopo il completamento dello snapshot automatico dell'istanza. Tuttavia, non è possibile eseguire il point-in-time ripristino di una versione secondaria precedente.

    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 Amazon Aurora.

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

Dopo aver completato un aggiornamento della versione principale, è consigliabile quanto segue:

• Eseguire l'operazione ANALYZE per aggiornare la tabella pg_statistic. È necessario farlo per ogni database su tutte le istanze database di PostgreSQL. Le statistiche di ottimizzazione non vengono trasferite durante un aggiornamento della versione principale, quindi è necessario rigenerare tutte le statistiche per evitare problemi di prestazioni. Esegui il comando senza parametri per generare statistiche per tutte le tabelle regolari del database corrente, come segue:

  ANALYZE VERBOSE;

  Il flag VERBOSE è facoltativo, ma usandolo viene mostrato lo stato di avanzamento. Per ulteriori informazioni, consulta ANALYZE nella documentazione di PostgreSQL.

  Nota

  Esegui ANALYZE sul tuo sistema dopo l'aggiornamento per evitare problemi di prestazioni.

• Se hai eseguito l'aggiornamento a PostgreSQL versione 10, esegui REINDEX su qualsiasi indice hash che hai. Gli indici hash sono stati modificati nella versione 10 e devono essere ricostruiti. Per individuare indici hash non validi, eseguire il seguente 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;

• Ti consigliamo di testare l'applicazione sul database aggiornato con un carico di lavoro analogo per verificare che tutto funzioni come previsto. Dopo la verifica dell'aggiornamento è possibile eliminare l'istanza di test.

Aggiornamento del motore Aurora PostgreSQL a una nuova versione principale

Quando avvii il processo di aggiornamento a una nuova versione principale, Aurora PostgreSQL acquisisce uno snapshot del cluster database Aurora prima di apportare eventuali modifiche al cluster. Questo snapshot viene creato solo per gli aggiornamenti della versione principale, non per gli aggiornamenti della versione secondaria. Al termine del processo di aggiornamento, questo snapshot è disponibile tra gli snapshot manuali elencati in Snapshots nella console RDS. Il nome dello snapshot include preupgrade come prefisso, il nome del cluster database Aurora PostgreSQL, la versione di origine, la versione di destinazione e la data e il timestamp, come illustrato nell'esempio seguente.

preupgrade-docs-lab-apg-global-db-12-8-to-13-6-2022-05-19-00-19

Al termine dell'aggiornamento, puoi utilizzare lo snapshot creato e archiviato da Aurora nell'elenco di snapshot manuali per ripristinare il cluster database alla versione precedente, se necessario.

Suggerimento

In generale, gli snapshot forniscono molti modi per ripristinare il cluster database Aurora in momenti diversi. Per ulteriori informazioni, consultare Ripristino da uno snapshot cluster database e Ripristino di un cluster di database a un determinato momento. Tuttavia, Aurora PostgreSQL non supporta l'utilizzo di uno snapshot per il ripristino a una versione secondaria precedente.

Durante il processo di aggiornamento della versione principale, Aurora alloca un volume e clona il cluster database Aurora PostgreSQL di origine. Se l'aggiornamento non va a buon fine per qualsiasi motivo, Aurora PostgreSQL utilizza il clone per eseguire il rollback dell'aggiornamento. Quando vengono allocati più di 15 cloni di un volume di origine, i cloni successivi diventano copie complete e richiedono più tempo. Di conseguenza anche il processo di aggiornamento richiede più tempo. Se Aurora PostgreSQL esegue il rollback dell'aggiornamento, tenere presente quanto segue:

• È possibile che vengano visualizzate voci di fatturazione e parametri per il volume originale e per il volume clonato allocati durante l'aggiornamento. Aurora PostgreSQL elimina i dati sul volume aggiuntivo quando la finestra di conservazione del backup del cluster supera il termine dell'aggiornamento.

• La successiva copia snapshot tra regioni da questo cluster sarà una copia completa anziché una copia incrementale.

Per aggiornare in modo sicuro le istanze database che compongono il cluster, Aurora PostgreSQL utilizza l'utilità pg_upgrade. Al termine dell'aggiornamento dell'istanza di scrittura, ogni istanza di lettura riscontra una breve interruzione mentre viene aggiornato alla nuova versione principale. Per ulteriori informazioni su questa utilità, consulta pg_upgrade nella documentazione di PostgreSQL.

È possibile aggiornare il cluster Aurora PostgreSQL DB a una nuova versione utilizzando l'API, the AWS Management Console o RDS. AWS CLI

Console

Modificare la versione del motore di un cluster database

1. Accedi AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

2. Nel riquadro di navigazione, scegliere Databases (Database) quindi selezionare il cluster di database da aggiornare.

3. Scegliere Modify (Modifica). Viene visualizzata la pagina Modify DB cluster (Modifica cluster di database).

4. In Engine version (Versione motore) scegliere la nuova versione.

5. Scegliere Continue (Continua) e controllare il riepilogo delle modifiche.

6. Per applicare immediatamente le modifiche, scegliere Apply immediately (Applica immediatamente). In alcuni casi, la chiusura di questa opzione può causare un'interruzione. Per ulteriori informazioni, consulta Modifica di un cluster database Amazon Aurora.

7. Nella pagina di conferma esaminare le modifiche. Se sono corrette, selezionare Modify Cluster (Modifica cluster) per salvare le modifiche.

   Oppure scegliere Back (Indietro) per cambiare le modifiche o Cancel (Annulla) per annullare le modifiche.

AWS CLI

Per aggiornare la versione del motore di un cluster DB, usa il modify-db-cluster AWS CLI comando. Specifica i seguenti parametri:

• --db-cluster-identifier: il nome del cluster di database.

• --engine-version – Numero di versione del motore di database a cui effettuare l'aggiornamento. Per informazioni sulle versioni valide del motore, utilizzate il AWS CLI describe-db-engine-versionscomando.

• --allow-major-version-upgrade – Un flag obbligatorio quando il parametro --engine-version è una versione principale diversa rispetto alla versione principale corrente del cluster database.

• --no-apply-immediately – Applica le modifiche durante la finestra di manutenzione successiva. Per applicare immediatamente le modifiche utilizzare --apply-immediately.

Esempio

Per LinuxmacOS, oUnix:

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --allow-major-version-upgrade \
    --no-apply-immediately

Per Windows:

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --allow-major-version-upgrade ^
    --no-apply-immediately

API RDS

Per aggiornare la versione del motore di un cluster di database, utilizza l'operazione ModifyDBCluster. Specifica i seguenti parametri:

• DBClusterIdentifier – Nome del cluster database, ad esempio mydbcluster.

• EngineVersion – Numero di versione del motore di database a cui effettuare l'aggiornamento. Per informazioni sulle versioni valide del motore, utilizzate l'operazione DescribeDB EngineVersions.

• AllowMajorVersionUpgrade – Un flag obbligatorio quando il parametro EngineVersion è una versione principale diversa rispetto alla versione principale corrente del cluster database.

• ApplyImmediately – Indica se applicare le modifiche immediatamente o durante la finestra di manutenzione successiva. Per applicare le modifiche immediatamente, imposta il valore su true. Per applicare le modifiche durante la finestra di manutenzione successiva imposta il valore su false.

Principali aggiornamenti per database globali

Per un cluster database globale Aurora, il processo di aggiornamento aggiorna tutti i cluster database che compongono contemporaneamente il database globale Aurora. Esegue questa operazione per garantire che ognuno esegua la stessa versione di Aurora PostgreSQL. Inoltre, assicura che le eventuali modifiche apportate alle tabelle di sistema, ai formati di file di dati e così via vengono replicate automaticamente in tutti i cluster secondari.

Per aggiornare un cluster database globale a una nuova versione principale di Aurora PostgreSQL, si consiglia di eseguire il test delle applicazioni nella versione aggiornata, come descritto in Test di un aggiornamento del cluster database di produzione a una nuova versione principale. Assicurati di preparare le impostazioni del gruppo di parametri del cluster DB e del gruppo di parametri DB per ciascuno Regione AWS nel database globale Aurora prima dell'aggiornamento, come descritto instep 1. . Test di un aggiornamento del cluster database di produzione a una nuova versione principale

Se il cluster database globale Aurora PostgreSQL dispone di un Obiettivo del punto di ripristino (RPO) impostato per il parametro rds.global_db_rpo, assicurati di ripristinare il parametro prima dell'aggiornamento. Il processo di aggiornamento della versione principale non funziona se l'RPO è attivato. Per impostazione predefinita, questo parametro è disattivato. Per ulteriori informazioni su database globali Aurora PostgreSQL e RPO, consulta Gestione degli RPO per database globali basati su Aurora PostgreSQL–.

Se verifichi che le applicazioni possano essere eseguite come previsto durante l'implementazione di prova della nuova versione, puoi avviare il processo di aggiornamento. A questo proposito, consulta Aggiornamento del motore Aurora PostgreSQL a una nuova versione principale. Assicurati di scegliere la voce di primo livello dall'elenco Databases (Database) nella console RDS, Database globale, come mostrato nell'immagine seguente.

Come per qualsiasi modifica, puoi confermare che desideri che il processo proceda quando richiesto.

Invece di utilizzare la console, puoi avviare il processo di aggiornamento utilizzando la AWS CLI o l'API RDS. Come per la console, si opera sul cluster database globale Aurora anziché su uno qualsiasi dei suoi componenti, come segue:

• Usa il modify-global-cluster AWS CLI comando per avviare l'aggiornamento del tuo database globale Aurora utilizzando. AWS CLI

• Utilizza l'ModifyGlobalClusterAPI per avviare l'aggiornamento.

Prima di eseguire un aggiornamento di una versione minore

Si consiglia di eseguire le seguenti azioni per ridurre i tempi di inattività durante l'aggiornamento di una versione secondaria:

• La manutenzione del cluster Aurora DB deve essere eseguita durante un periodo di traffico ridotto. Usa Performance Insights per identificare questi periodi di tempo al fine di configurare correttamente le finestre di manutenzione. Per ulteriori informazioni su Performance Insights, consulta Monitoraggio del carico del DB con Performance Insights su Amazon RDS. Per ulteriori informazioni sulla finestra di manutenzione del cluster DB,Impostazione della finestra di manutenzione preferita del cluster database.

• Utilizza AWS SDK che supportano il backoff e il jitter esponenziali come best practice. Per ulteriori informazioni, consulta Exponential Backoff And Jitter.

Come eseguire aggiornamenti della versione secondaria e applicare patch

Gli aggiornamenti e le patch delle versioni minori sono disponibili solo dopo test rigorosi. Regioni AWS Prima di rilasciare aggiornamenti e patch, Aurora PostgreSQL verifica per garantire che problemi di sicurezza noti, bug e altri problemi che emergono dopo il rilascio della versione della community secondaria non compromettano la stabilità generale del parco istanze Aurora PostgreSQL.

Poiché Aurora PostgreSQL rende disponibili nuove versioni secondarie, le istanze che compongono il cluster database Aurora PostgreSQL possono essere aggiornate automaticamente durante la finestra di manutenzione specificata. Affinché ciò accada, l'opzione Enable auto minor version upgrade (Abilita aggiornamento automatico versione secondaria) del cluster database Aurora PostgreSQL deve essere attivata. Per tutte le istanze database che compongono il cluster database Aurora PostgreSQL l'opzione Aggiornamento automatico delle versioni minori (AmVU) deve essere attivata in modo che l'aggiornamento della versione secondaria venga applicato a tutto il cluster.

Suggerimento

Assicurati che l'opzione Enable auto minor version upgrade (Abilita aggiornamento automatico versione secondaria) sia attivata per tutte le istanze database di PostgreSQL che compongono il cluster database Aurora PostgreSQL. Questa opzione deve essere attivata affinché ogni istanza nel cluster database funzioni. Per informazioni su come impostare l'aggiornamento automatico delle versioni secondarie e su come funziona l'impostazione quando viene applicata a livello di cluster e istanza, consulta  Aggiornamenti automatici delle versioni secondarie per cluster DB Aurora.

È possibile verificare il valore dell'opzione Enable auto minor version upgrade per tutti i cluster Aurora PostgreSQL DB utilizzando il comando con la seguente query. describe-db-instances AWS CLI

aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

Questa query restituisce un elenco di tutti i cluster database Aurora e delle relative istanze con un valore true o false per lo stato dell'impostazione AutoMinorVersionUpgrade. Il comando mostrato presuppone che l'utente sia configurato come target AWS CLI predefinito. Regione AWS

Per ulteriori informazioni sull'opzione Aggiornamento automatico delle versioni minori (AmVU) e su come modificare il cluster database Aurora per utilizzarla, consulta Aggiornamenti automatici delle versioni secondarie per cluster DB Aurora.

Puoi aggiornare i cluster database Aurora PostgreSQL alle nuove versioni secondarie rispondendo alle attività di manutenzione o modificando il cluster per utilizzare la nuova versione.

Puoi identificare eventuali aggiornamenti o patch disponibili per i cluster database Aurora PostgreSQL utilizzando la console RDS e aprendo il menu Recommendations (Consigli). Qui è disponibile un elenco dei diversi problemi di manutenzione come Old minor versions (Versioni secondarie precedenti). A seconda dell'ambiente di produzione, puoi scegliere di pianificare l'aggiornamento o eseguire un'azione immediata, scegliendo Apply now (Applica ora) come mostrato di seguito.

Per ulteriori informazioni su come gestire un cluster database Aurora, incluso come applicare manualmente le patch e gli aggiornamenti della versione secondaria, consulta Manutenzione di un cluster database Amazon Aurora.

Aggiornamenti della versione secondaria e applicazione di patch senza tempi di inattività

L'aggiornamento di un cluster database Aurora PostgreSQL comporta la possibilità di un'interruzione. Durante il processo di aggiornamento, il database viene arrestato. Se si avvia l'aggiornamento mentre il database è occupato, si perdono tutte le connessioni e le transazioni elaborate dal cluster database. Se si aspetta che il database sia inattivo per eseguire l'aggiornamento, potrebbe essere necessario attendere a lungo.

La funzione ZDP (applicazione delle patch senza tempi di inattività) migliora il processo di aggiornamento. Grazie a ZDP, è possibile applicare aggiornamenti della versione secondaria e patch con un impatto minimo sul cluster database Aurora PostgreSQL. ZDP viene utilizzato quando si applicano patch o aggiornamenti di versioni secondarie più recenti a versioni di Aurora PostgreSQL e altre versioni successive di queste versioni secondarie e le versioni principali più recenti. Ovvero, l'aggiornamento a nuove versioni secondarie da una qualsiasi di queste versioni in poi utilizza ZDP.

La tabella seguente mostra le versioni di Aurora PostgreSQL e le classi di istanze database in cui è disponibile ZDP:

Versione	Classi di istanza db.r*	Classi di istanza db.t*	Classi di istanza db.x*	Classe di istanza db.serverless
10.21.0 e versioni successive alla 10.21	Sì	Sì	Sì	N/D
11.16.0 e versioni successive alla 11.16	Sì	Sì	Sì	N/D
11.17 e versioni successive	Sì	Sì	Sì	N/D
12.11.0 e versioni successive alla 12.11	Sì	Sì	Sì	N/D
12.12 e versioni successive	Sì	Sì	Sì	N/D
13.7.0 e versioni successive alla 13.7	Sì	Sì	Sì	N/D
13.8 e versioni successive	Sì	Sì	Sì	Sì
14.3.1 o versioni successive alla 14.3	Sì	Sì	Sì	N/D
14.4.0 e versioni successive alla 14.4	Sì	Sì	Sì	N/D
14.5 e versioni successive	Sì	Sì	Sì	Sì
15.3 e versioni successive	Sì	Sì	Sì	Sì

ZDP funziona preservando le connessioni client correnti al cluster database Aurora PostgreSQL durante il processo di aggiornamento di Aurora PostgreSQL. Tuttavia, nei seguenti casi, le connessioni verranno interrotte per l'applicazione di patch senza tempi di inattività:

• Sono in esecuzione query o transazioni di lunga durata.

• Sono in esecuzione istruzioni DDL (Data Definition Language).

• Si utilizzando blocchi di tabelle o tabelle temporanee.

• Vengono ascoltate tutte le sessioni sui canali di notifica.

• È in uso un cursore nello stato "WITH HOLD".

• Si utilizzano le connessioni TLSv1.3 o TLSv1.1.

Durante il processo di aggiornamento tramite l'applicazione di patch senza tempi di inattività, il motore di database cerca un punto idoneo per sospendere tutte le nuove transazioni. Questa azione protegge il database durante le patch e gli aggiornamenti. Per assicurarsi che le applicazioni funzionino senza problemi con transazioni sospese, è consigliabile integrare la logica dell'esecuzione di nuovi tentativi nel codice. Questo approccio garantisce che il sistema sia in grado di gestire qualsiasi breve periodo di inattività senza errori e di riprovare le nuove transazioni dopo l'aggiornamento.

Quando l'applicazione di patch senza tempi di inattività è completata, le sessioni dell'applicazione vengono conservate, ad eccezione di quelle con connessioni eliminate; il motore di database viene riavviato mentre l'aggiornamento è ancora in corso. Il riavvio del motore di database può causare una riduzione temporanea della velocità di trasmissione effettiva, che dura in genere alcuni secondi o al massimo circa un minuto.

In alcuni casi, l'applicazione di patch senza tempi di inattività (ZDP) potrebbe non avere esito positivo. Ad esempio, le modifiche ai parametri che si trovano nello stato pending sul cluster di database Aurora PostgreSQL o le sue istanze possono interferire con l'applicazione di patch senza tempi di inattività.

Puoi trovare parametri ed eventi per le operazioni ZDP nella pagina Events (Eventi) nella console. Gli eventi includono l'avvio dell'aggiornamento ZDP e il completamento dell'aggiornamento. In questo caso puoi individuare il tempo richiesto dal processo e il numero di connessioni conservate e interrotte che si sono verificate durante il riavvio. Puoi individuare i dettagli nel registro degli errori del database.

Aggiornamento del motore Aurora PostgreSQL a una nuova versione secondaria

Puoi aggiornare il cluster Aurora PostgreSQL DB a una nuova versione secondaria utilizzando la console, l'o l'API RDS. AWS CLI Prima di eseguire l'aggiornamento, si consiglia di seguire le stesse best practice consigliate per gli aggiornamenti della versione principale. Come per le nuove versioni principali, anche le nuove versioni secondarie possono contenere miglioramenti all'ottimizzatore, ad esempio correzioni, che possono causare regressioni del piano di query. Per garantire la stabilità del piano, si consiglia di utilizzare l'estensione Query Plan Management (QPM) come descritto in Garantire la stabilità del piano dopo un aggiornamento di versione principale.

Console

Aggiornare la versione del motore del cluster database Aurora PostgreSQL

1. Accedi AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

2. Nel riquadro di navigazione, scegliere Databases (Database) quindi selezionare il cluster di database da aggiornare.

3. Scegliere Modify (Modifica). Viene visualizzata la pagina Modify DB cluster (Modifica cluster di database).

4. In Engine version (Versione motore) scegliere la nuova versione.

5. Scegliere Continue (Continua) e controllare il riepilogo delle modifiche.

6. Per applicare immediatamente le modifiche, scegliere Apply immediately (Applica immediatamente). In alcuni casi, la chiusura di questa opzione può causare un'interruzione. Per ulteriori informazioni, consulta Modifica di un cluster database Amazon Aurora.

7. Nella pagina di conferma esaminare le modifiche. Se sono corrette, selezionare Modify Cluster (Modifica cluster) per salvare le modifiche.

   Oppure scegliere Back (Indietro) per cambiare le modifiche o Cancel (Annulla) per annullare le modifiche.

AWS CLI

Per aggiornare la versione del motore di un cluster DB, usa il modify-db-cluster AWS CLI comando con i seguenti parametri:

• --db-cluster-identifier – Nome del cluster database Aurora PostgreSQL.

• --engine-version – Numero di versione del motore di database a cui effettuare l'aggiornamento. Per informazioni sulle versioni valide del motore, utilizzate il AWS CLI describe-db-engine-versionscomando.

• --no-apply-immediately – Applica le modifiche durante la finestra di manutenzione successiva. Per applicare immediatamente le modifiche, utilizza invece --apply-immediately.

Per LinuxmacOS, oUnix:

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --no-apply-immediately

Per Windows:

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --no-apply-immediately

API RDS

Per aggiornare la versione del motore di un cluster di database, utilizza l'operazione ModifyDBCluster. Specifica i seguenti parametri:

• DBClusterIdentifier – Nome del cluster database, ad esempio mydbcluster.

• EngineVersion – Numero di versione del motore di database a cui effettuare l'aggiornamento. Per informazioni sulle versioni valide del motore, utilizzate l'operazione DescribeDB EngineVersions.

• ApplyImmediately – Indica se applicare le modifiche immediatamente o durante la finestra di manutenzione successiva. Per applicare le modifiche immediatamente, imposta il valore su true. Per applicare le modifiche durante la finestra di manutenzione successiva imposta il valore su false.

Aggiornamento estensioni PostgreSQL

L'aggiornamento del cluster di database Aurora PostgreSQL a una nuova versione principale o secondaria non aggiorna contemporaneamente le estensioni PostgreSQL. Per la maggior parte delle estensioni, l'estensione viene aggiornata dopo il completamento dell'aggiornamento della versione principale o secondaria. Tuttavia, in alcuni casi, l'estensione viene aggiornata prima di aggiornare il motore di database Aurora PostgreSQL. Per ulteriori informazioni, consulta list of extensions to update in Test di un aggiornamento del cluster database di produzione a una nuova versione principale.

L'installazione delle estensioni PostgreSQL richiede privilegi rds_superuser. In genere, un rds_superuser delega le autorizzazioni su estensioni specifiche agli utenti (ruoli) pertinenti, per facilitare la gestione di una determinata estensione. Ciò significa che il compito di aggiornare tutte le estensioni nel cluster database Aurora PostgreSQL potrebbe coinvolgere molti utenti (ruoli) diversi. Tenerlo presente se si desidera automatizzare il processo di aggiornamento utilizzando gli script. Per ulteriori informazioni sui privilegi e sui ruoli PostgreSQL, consulta Sicurezza con Amazon Aurora PostgreSQL.

Nota

Per informazioni sull'aggiornamento dell'estensione PostGIS, consulta Gestione dei dati spaziali con estensione PostGIS (Passaggio 6: Aggiornamento dell'estensione PostGIS).

Per aggiornare l'estensione pg_repack, rimuovi l'estensione e quindi crea la nuova versione nell'istanza database aggiornata. Per ulteriori informazioni, consulta pg_repack installation nella documentazione pg_repack.

Per aggiornare un'estensione dopo un aggiornamento del motore, utilizza il comando ALTER EXTENSION UPDATE.

ALTER EXTENSION extension_name UPDATE TO 'new_version';

Per elencare le estensioni attualmente installate, usa il catalogo PostgreSQL pg_extension nel seguente comando.

SELECT * FROM pg_extension;

Per visualizzare l'elenco delle versioni delle estensioni specifiche disponibili per l'installazione, utilizza la vista PostgreSQL pg_available_extension_versions nel seguente comando.

SELECT * FROM pg_available_extension_versions;

Tecnica alternativa di aggiornamento blu/verde

In alcune situazioni, la priorità principale è eseguire il passaggio immediato dal cluster precedente a quello aggiornato. In tali situazioni, è possibile utilizzare un processo in più fasi che esegue i cluster vecchi e nuovi. side-by-side Qui, i dati vengono replicati dal cluster precedente a quello nuovo fino a quando il nuovo cluster non prende il controllo. Per informazioni dettagliate, vedi Utilizzo delle implementazioni blu/verde Amazon RDS per gli aggiornamenti del database.