Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # 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. **Contents** + [Panoramica dei processi di aggiornamento di Aurora PostgreSQL](#USER_UpgradeDBInstance.PostgreSQL.Overview) + [Ottenere un elenco di versioni disponibili nel tuo Regione AWS](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md) + [Esecuzione di un aggiornamento alla versione principale](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md) + [Test di un aggiornamento del cluster database di produzione a una nuova versione principale](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary) + [Raccomandazioni successive all’aggiornamento](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.postupgrade) + [Aggiornamento del motore Aurora PostgreSQL a una nuova versione principale](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.Upgrading.Manual) + [Principali aggiornamenti per database globali](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.GlobalDB) + [Esecuzione di un aggiornamento a una versione secondaria](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md) + [Operazioni preliminari all’aggiornamento a una versione secondaria](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor) + [Come eseguire aggiornamenti della versione secondaria e applicare patch](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor) + [Aggiornamenti della versione secondaria e applicazione di patch senza tempi di inattività](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp) + [Limitazioni dell’applicazione di patch senza tempo di inattività](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations) + [Aggiornamento del motore Aurora PostgreSQL a una nuova versione secondaria](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.MinorUpgrade) + [Aggiornamento estensioni PostgreSQL](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md) + [Tecnica di blue/green aggiornamento alternativa](#USER_UpgradeDBInstance.Upgrading.BlueGreen) ## 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. Aurora può applicare aggiornamenti della versione secondaria automaticamente. Quando crei un nuovo cluster di database Aurora PostgreSQL, l’opzione **Abilita aggiornamento versione secondaria** è abilitata in modo predefinito. A meno che questa opzione non venga disattivata manualmente, Aurora applica periodicamente aggiornamenti automatici della versione secondaria 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 i cluster di database Aurora](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU). Se l’aggiornamento automatico della versione secondaria non è abilitato per il cluster di database Aurora PostgreSQL, Aurora PostgreSQL non viene automaticamente aggiornato a una nuova versione secondaria. Invece, quando una nuova versione secondaria viene rilasciata nella Regione AWS e il cluster database Aurora PostgreSQL sta eseguendo una versione secondaria precedente, Aurora richiede 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](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor). 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. Gli aggiornamenti automatici delle versioni secondarie vengono eseguiti sulla versione secondaria predefinita. 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à](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp). Per ulteriori informazioni sulle funzionalità e le limitazioni supportate di ZDP, consulta [Limitazioni dell’applicazione di patch senza tempo di inattività](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations). **Aggiornamenti a versioni principali** 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](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary) 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 implica la possibilità di brevi interruzioni poiché tutte le istanze nel 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 [Esecuzione di un aggiornamento alla versione principale](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md). **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 [Collation supportate in Aurora PostgreSQL RDS per ](PostgreSQL-Collations.md). # Ottenere un elenco di 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](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI Per Linux, macOS o 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 Linux, macOS o 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 seguente sono disponibili le destinazioni degli aggiornamenti della versione principale e secondaria per differenti versioni di database Aurora PostgreSQL. Per mantenere la compatibilità, non tutte le versioni sono offerte come obiettivi di aggiornamento. Aurora PostgreSQL introduce nuove funzionalità e correzioni di bug con ogni versione trimestrale secondaria. Per ulteriori informazioni sulle versioni secondarie di Aurora PostgreSQL, consulta [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html). | Versione di origine corrente | Destinazioni di aggiornamento | | --- | --- | | 17.7 | Nessuno | | 17,6 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) | | 17,5 | [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) | | 17,4 | [17,7, 17,6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x)[, [17,5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x) | | 16,11 | Nessuno | | 16,10 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) | | 16,9 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x) | | 16,8 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) | | 16,6 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) | | 16,4 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x) | | 16,3 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) | | 16,2 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) | | 16,1 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x) | | 15,15 | Nessuno | | 15,14 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [15,15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x) | | 15,13 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x) | | 15,12 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x) | | 15,10 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) | | 15,11 | [17,7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16,11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) | | 14,20 | Nessuno | 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 cluster Aurora PostgreSQL DB utilizza attualmente una classe di istanza db.r4, è necessario modificarla per utilizzare una classe di istanza DB supportata prima di poter eseguire l'aggiornamento ad Aurora PostgreSQL 13. Per ulteriori informazioni sulle classi di istanze del database Aurora PostgreSQL disponibili, incluse quelle basate su Graviton2 e quelle basate su Intel, consulta. [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md) # Esecuzione di un aggiornamento alla 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 di versioni disponibili nel tuo Regione AWS](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md). 1. 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](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary). 1. 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](#USER_UpgradeDBInstance.Upgrading.Manual). **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](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI Per Linux, macOS o 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](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md#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](AuroraPostgreSQL.Optimize.BestPractice.md#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade). 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. 1. Oppure è possibile creare un gruppo di parametri personalizzato per la nuova versione del motore database. 1. Verifica la presenza di database non validi ed elimina quelli esistenti. La colonna `datconnlimit` nel catalogo `pg_database` include il valore `-2` per contrassegnare come non validi tutti i database che sono stati interrotti durante un’operazione `DROP DATABASE`. Utilizza 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. Utilizza l’istruzione `DROP DATABASE invalid_db_name` per eliminare i database non validi. Per eliminare tutti i database non validi, puoi utilizzare la seguente istruzione dinamica. ``` SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec ``` 1. 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\$1* prima di tentare un aggiornamento. Ad eccezione di `regtype` e `regclass`, non è possibile aggiornare i tipi di dati *reg\$1*. L’utilità pg\$1upgrade (utilizzata da Amazon Aurora per eseguire l'aggiornamento) non può preservare questo tipo di dati. Per ulteriori informazioni su questa utilità, consulta [pg\$1upgrade](https://www.postgresql.org/docs/current/pgupgrade.html) nella documentazione di PostgreSQL. Per verificare che non siano presenti utilizzi di tipi di dati *reg\$1* 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. 1. 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`. 1. 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 altri obiettivi. 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](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md). 1. 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](USER_CreateSnapshotCluster.md) per ulteriori informazioni. 1. 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](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md). Per ulteriori informazioni sull'aggiornamento di PostGIS, consulta [Passaggio 6: Aggiornamento dell'estensione PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update). 1. 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` 1. 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'); ``` 1. 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](aurora-restore-snapshot.md#aurora-restore-snapshot.Restoring) o [Clonazione di un volume per un cluster di database Amazon Aurora](Aurora.Managing.Clone.md). Per ulteriori informazioni, consulta [Aggiornamento del motore Aurora PostgreSQL a una nuova versione principale](#USER_UpgradeDBInstance.Upgrading.Manual). 1. 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](#USER_UpgradeDBInstance.Upgrading.Manual). **Nota** Durante il processo di aggiornamento, Aurora PostgreSQL accetta uno snapshot del cluster di database. 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](USER_LogAccess.md). 1. Aggiornare le estensioni PostgreSQL. Un processo di aggiornamento PostgreSQL non aggiorna alcuna estensione PostgreSQL. Per ulteriori informazioni, consulta [Aggiornamento estensioni PostgreSQL](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md). ## Raccomandazioni successive all’aggiornamento 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](https://www.postgresql.org/docs/10/sql-analyze.html) nella documentazione di PostgreSQL. Quando analizzi tabelle specifiche invece di utilizzare ANALYZE VERBOSE, esegui il comando ANALYZE per ogni tabella come segue: ``` ANALYZE table_name; ``` Per le tabelle partizionate, analizza sempre la tabella principale. Il seguente processo: + Campiona automaticamente le righe in tutte le partizioni + Aggiorna le statistiche per ogni partizione in modo ricorsivo + Mantiene le statistiche di pianificazione essenziali a livello principale Sebbene le tabelle principale non memorizzino dati effettivi, la loro analisi è fondamentale per l’ottimizzazione delle query. L’esecuzione di ANALYZE solo su singole partizioni può portare a prestazioni di query scadenti poiché lo strumento di ottimizzazione non disporrà delle statistiche complete necessarie per una pianificazione efficiente tra le partizioni. **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 di cui disponi. 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 **Snapshot** 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](aurora-restore-snapshot.md) e [Ripristino di un cluster di database a un determinato momento](aurora-pitr.md). 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\$1upgrade. 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\$1upgrade](https://www.postgresql.org/docs/current/pgupgrade.html) nella documentazione di PostgreSQL. È possibile aggiornare il cluster Aurora PostgreSQL DB a una nuova versione utilizzando l'API, the Console di gestione AWS o RDS. AWS CLI ### Console **Modificare la versione del motore di un cluster database** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel riquadro di navigazione, scegliere **Databases (Database)** quindi selezionare il cluster di database da aggiornare. 1. Scegliere **Modify (Modifica)**. Viene visualizzata la pagina **Modify DB cluster (Modifica cluster di database)**. 1. In **Engine version (Versione motore)** scegliere la nuova versione. 1. Scegliere **Continue (Continua)** e controllare il riepilogo delle modifiche. 1. 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](Aurora.Modifying.md). 1. 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](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 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-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)comando. + `--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`. **Example** Per Linux, macOS o Unix: ``` 1. aws rds modify-db-cluster \ 2. --db-cluster-identifier mydbcluster \ 3. --engine-version new_version \ 4. --allow-major-version-upgrade \ 5. --no-apply-immediately ``` Per Windows: ``` 1. aws rds modify-db-cluster ^ 2. --db-cluster-identifier mydbcluster ^ 3. --engine-version new_version ^ 4. --allow-major-version-upgrade ^ 5. --no-apply-immediately ``` ### API RDS Per aggiornare la versione del motore di un cluster DB, utilizzate l'DBClusteroperazione [Modifica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). 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 [Descrivi DBEngine le versioni](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html). + `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](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary). 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 in[step 1.](#step-1). [Test di un aggiornamento del cluster database di produzione a una nuova versione principale](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary) 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–](aurora-global-database-disaster-recovery.md#aurora-global-database-manage-recovery). 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](#USER_UpgradeDBInstance.Upgrading.Manual). Assicurati di scegliere la voce di primo livello dall'elenco **Databases** (Database) nella console RDS, **Database globale**, come mostrato nell'immagine seguente. ![\[Immagine della console che mostra un database globale Aurora, un cluster database Aurora Serverless e un altro cluster database Aurora PostgreSQL\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-database-plus-other.png) Come per qualsiasi modifica, puoi confermare che desideri che il processo proceda quando richiesto. ![\[Immagine della console che mostra la richiesta di conferma del processo di aggiornamento per un cluster di database Aurora PostgreSQL\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-apg-upgrade-2.png) 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](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) AWS CLI comando per avviare l'aggiornamento del tuo database globale Aurora utilizzando. AWS CLI + Utilizza l'[ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html)API per avviare l'aggiornamento. # Esecuzione di un aggiornamento a una versione secondaria Puoi utilizzare i seguenti metodi per aggiornare la versione secondaria di un cluster di database o per applicare le patch a un cluster di database: **Topics** + [Operazioni preliminari all’aggiornamento a una versione secondaria](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor) + [Come eseguire aggiornamenti della versione secondaria e applicare patch](#USER_UpgradeDBInstance.PostgreSQL.Minor) + [Aggiornamenti della versione secondaria e applicazione di patch senza tempi di inattività](#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp) + [Limitazioni dell’applicazione di patch senza tempo di inattività](#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations) + [Aggiornamento del motore Aurora PostgreSQL a una nuova versione secondaria](#USER_UpgradeDBInstance.MinorUpgrade) ## Operazioni preliminari all’aggiornamento a una versione secondaria Consigliamo di eseguire le seguenti azioni per ridurre il tempo di inattività durante un aggiornamento di una versione secondaria: + La manutenzione del cluster di database Aurora deve essere eseguita durante un periodo di traffico ridotto. Utilizza Approfondimenti sulle prestazioni per identificare questi periodi di tempo al fine di configurare correttamente le finestre di manutenzione. Per ulteriori informazioni su Approfondimenti sulle prestazioni, consulta [Monitoraggio del carico DB con Performance Insights su Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html). Per ulteriori informazioni sulla finestra di manutenzione dei cluster di database, [Impostazione della finestra di manutenzione preferita del cluster database](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora). + Usa AWS SDKs il supporto del backoff e del jitter esponenziali come best practice. Per ulteriori informazioni, consulta [Backoff esponenziale e jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/). ## Come eseguire aggiornamenti della versione secondaria e applicare patch Gli aggiornamenti e le patch delle versioni minori diventano 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 Community secondaria non compromettano la stabilità del parco istanze Aurora PostgreSQL. Se si attiva **Abilita aggiornamento automatico versione secondaria**, Aurora PostgreSQL effettua periodicamente aggiornamenti automatici di versioni secondarie, il cluster di database viene aggiornato durante la finestra di manutenzione specificata. Assicurati che l’opzione **Abilita aggiornamento automatico versione secondaria** sia attivata per tutte le istanze nel cluster di database Aurora PostgreSQL. Per informazioni su come impostare **Aggiornamento automatico della versione secondaria** e su come funziona l’impostazione quando viene applicata a livello di cluster e istanza, consulta [Aggiornamenti automatici delle versioni secondarie per i cluster di database Aurora](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU). Controlla il valore dell'opzione **Abilita l'aggiornamento automatico della versione secondaria** per tutti i cluster Aurora PostgreSQL DB utilizzando il comando seguente. [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) 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 presuppone che tu abbia configurato come target AWS CLI quello predefinito. Regione AWS Per ulteriori informazioni sull’opzione Aggiornamento automatico della versione secondaria (AmVU) e su come modificare il cluster database Aurora per utilizzarla, consulta [Aggiornamenti automatici delle versioni secondarie per i cluster di database Aurora](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU). 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** (Raccomandazioni). 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. ![\[Immagine della console che mostra la raccomandazione per eseguire l'aggiornamento a una versione secondaria più recente.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/apg-maintenance-upgrade-minor.png) 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 di database Amazon Aurora](USER_UpgradeDBInstance.Maintenance.md). ## 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\$1 | Classi di istanza db.t\$1 | Classi di istanza db.x\$1 | Classe di istanza db.serverless | | --- | --- | --- | --- | --- | | 10.21 e versioni successive | Sì | Sì | Sì | N/D | | 11.16 e versioni successive | Sì | Sì | Sì | N/D | | 11.17 e versioni successive | Sì | Sì | Sì | N/D | | 12.11 e versioni successive | Sì | Sì | Sì | N/D | | 12.12 e versioni successive | Sì | Sì | Sì | N/D | | 13.7 e versioni successive | Sì | Sì | Sì | N/D | | 13.8 e versioni successive | Sì | Sì | Sì | Sì | | 14.3 e versioni successive | Sì | Sì | Sì | N/D | | 14.4 e versioni successive | Sì | Sì | Sì | N/D | | 14.5 e versioni successive | Sì | Sì | Sì | Sì | | 15.3 e versioni successive | Sì | Sì | Sì | Sì | | 16.1 e versioni successive | Sì | Sì | Sì | Sì | 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. ## Limitazioni dell’applicazione di patch senza tempo di inattività Le seguenti limitazioni si applicano all’applicazione di patch senza tempi di inattività: + ZDP cerca di preservare le connessioni client correnti all’istanza database di scrittura 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". + TLSv1.1 le connessioni sono in uso. A partire dalle versioni di Aurora PostgreSQL successive alla 16.1, 15.3, 14.8, 13.11, 12.15 e 11.20, ZDP è supportato con connessioni 1.3. TLSv1 + ZDP non è supportato nei seguenti casi: + Quando i cluster database Aurora PostgreSQL sono configurati come Aurora Serverless v1. + Durante l’aggiornamento di qualsiasi istanza di lettura Aurora. + Durante l’aggiornamento di qualsiasi istanza di lettura Aurora che fa parte di un cluster di database globale Aurora in una Regione secondaria. + Durante i patch e gli aggiornamenti del sistema operativo. ## 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](AuroraPostgreSQL.Optimize.BestPractice.md#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade). ### Console **Aggiornare la versione del motore del cluster database Aurora PostgreSQL** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel riquadro di navigazione, scegliere **Databases (Database)** quindi selezionare il cluster di database da aggiornare. 1. Scegliere **Modify (Modifica)**. Viene visualizzata la pagina **Modify DB cluster (Modifica cluster di database)**. 1. In **Engine version (Versione motore)** scegliere la nuova versione. 1. Scegliere **Continue (Continua)** e controllare il riepilogo delle modifiche. 1. 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](Aurora.Modifying.md). 1. 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](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 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-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)comando. + `--no-apply-immediately` – Applica le modifiche durante la finestra di manutenzione successiva. Per applicare immediatamente le modifiche, utilizza invece `--apply-immediately`. Per Linux, macOS o Unix: ``` 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 DB, utilizzate l'DBClusteroperazione [Modifica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). 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 [Descrivi DBEngine le versioni](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html). + `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](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#upgrade-extensions) in [Test di un aggiornamento del cluster database di produzione a una nuova versione principale](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary). 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](AuroraPostgreSQL.Security.md). **Nota** Per informazioni sull'aggiornamento dell'estensione PostGIS, consulta [Gestione dei dati spaziali con estensione PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md) ([Passaggio 6: Aggiornamento dell'estensione PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)). Per aggiornare l'estensione `pg_repack`, rimuovi l'estensione e quindi crea la nuova versione nell'istanza database aggiornata. Per ulteriori informazioni, consulta [pg\$1repack installation](https://reorg.github.io/pg_repack/) 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\$1extension](https://www.postgresql.org/docs/current/catalog-pg-extension.html) 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\$1available\$1extension\$1versions](https://www.postgresql.org/docs/current/view-pg-available-extension-versions.html) nel seguente comando. ``` SELECT * FROM pg_available_extension_versions; ``` ## Tecnica di blue/green aggiornamento alternativa 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 di Amazon Blue/Green Aurora Deployments per gli aggiornamenti del database](blue-green-deployments.md).