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à.
# Come eseguire un aggiornamento in loco
Ti consigliamo di rivedere il materiale di background in [Come funziona l'aggiornamento della versione principale di Aurora MySQL in loco](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence).
Esegui eventuali operazioni di pianificazione e test pre-aggiornamento, come descritto in [Pianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning).
## Console
Nell'esempio seguente viene aggiornato il cluster database `mydbcluster-cluster` ad Aurora MySQL versione 3.04.1.
**Per aggiornare la versione principale di un cluster di database Aurora MySQL**
1. Accedi alla 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. Se è stato utilizzato un gruppo di parametri personalizzato con il cluster di database originale, crea un gruppo di parametri corrispondente compatibile con la nuova versione principale. Apportare le modifiche necessarie ai parametri di configurazione nel nuovo gruppo di parametri. Per ulteriori informazioni, consulta [Come gli aggiornamenti in loco influiscono sui gruppi di parametri per un cluster](#AuroraMySQL.Upgrading.ParamGroups).
1. Nel riquadro di navigazione, scegliere **Databases (Database)**.
1. Scegliere il cluster di database che si desidera modificare.
1. Scegliere **Modify (Modifica)**.
1. Per **Versione**, scegli una versione principale di Aurora MySQL.
In genere consigliamo di utilizzare la versione secondaria più recente della versione principale. In questo caso viene scelta la versione predefinita corrente.
![\[Aggiornamento locale di un cluster di database Aurora MySQL da versione 2 a versione 3\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. Scegli **Continua**.
1. Nella pagina successiva specificare quando eseguire l'aggiornamento. Scegliere **During the next scheduled maintenance window (Durante la successiva finestra di manutenzione programmata)** o **Immediately (Immediatamente)**.
1. (Facoltativo) Esaminare periodicamente la pagina **Events (Eventi)** nella console RDS durante l'aggiornamento. In questo modo è possibile monitorare lo stato di avanzamento dell'aggiornamento e identificare eventuali problemi. Se l'aggiornamento incontra dei problemi, consulta [Risoluzione dei problemi relativi all'aggiornamento in loco di Aurora MySQL](AuroraMySQL.Upgrading.Troubleshooting.md) per la procedura da intraprendere.
1. Se all'inizio di questa procedura è stato creato un nuovo gruppo di parametri, associa il gruppo di parametri personalizzati al cluster aggiornato. Per ulteriori informazioni, consulta [Come gli aggiornamenti in loco influiscono sui gruppi di parametri per un cluster](#AuroraMySQL.Upgrading.ParamGroups).
**Nota**
Per eseguire questo passaggio, è necessario riavviare nuovamente il cluster per applicare il nuovo gruppo di parametri.
1. (Facoltativo) Dopo avere completato i test successivi all'aggiornamento, eliminare lo snapshot manuale che Aurora ha creato all'inizio dell'aggiornamento.
## AWS CLI
Per aggiornare la versione principale di un cluster di database Aurora MySQL, utilizzare il comando AWS CLI CLI [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) con i seguenti parametri obbligatori:
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` o `--no-apply-immediately`
Se il cluster utilizza gruppi di parametri personalizzati, includere anche una o entrambe le opzioni seguenti:
+ `--db-cluster-parameter-group-name`, se il cluster utilizza un gruppo di parametri cluster personalizzato
+ `--db-instance-parameter-group-name`, se alcune istanze del cluster utilizzano un gruppo di parametri database personalizzato
Nell'esempio seguente viene aggiornato il cluster database `sample-cluster` ad Aurora MySQL versione 3.04.1. L'aggiornamento avviene immediatamente, invece di attendere la successiva finestra di manutenzione.
**Example**
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 8.0.mysql_aurora.3.04.1 \
--allow-major-version-upgrade \
--apply-immediately
```
Per Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 8.0.mysql_aurora.3.04.1 ^
--allow-major-version-upgrade ^
--apply-immediately
```
È possibile combinare altri comandi della CLI con `modify-db-cluster` per creare un processo end-to-end automatizzato per l'esecuzione e la verifica degli aggiornamenti. Per maggiori informazioni ed esempi, vedi [Esercitazione sull'aggiornamento in loco di Aurora MySQL](AuroraMySQL.Upgrading.Tutorial.md).
**Nota**
Se il cluster fa parte di un database globale Aurora, la procedura di aggiornamento in loco è leggermente diversa. Si chiama l'operazione del comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) invece di `modify-db-cluster`. Per ulteriori informazioni, consulta [Principali aggiornamenti in loco per database globali](#AuroraMySQL.Upgrading.GlobalDB).
## API RDS
Per aggiornare la versione principale di un cluster di database Aurora MySQL, utilizza l'operazione [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) dell'API RDS con i seguenti parametri obbligatori:
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately` ( impostato su `true` o `false`)
**Nota**
Se il cluster fa parte di un database globale Aurora, la procedura di aggiornamento in loco è leggermente diversa. Si chiama l'operazione [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html) invece di `ModifyDBCluster`. Per ulteriori informazioni, consulta [Principali aggiornamenti in loco per database globali](#AuroraMySQL.Upgrading.GlobalDB).
## Come gli aggiornamenti in loco influiscono sui gruppi di parametri per un cluster
I gruppi di parametri di Aurora hanno diversi insiemi di impostazioni di configurazione per i cluster compatibili con MySQL 5.7 o 8.0. Quando si esegue un aggiornamento locale, il cluster aggiornato e tutte le relative istanze devono utilizzare i corrispondenti gruppi di parametri cluster e istanza corrispondenti.
Il cluster e le istanze potrebbero utilizzare i gruppi di parametri compatibili con 5.7 predefiniti. In tal caso, il cluster e l'istanza aggiornati iniziano con i gruppi di parametri compatibili con 8.0 predefiniti. Se il cluster e le istanze utilizzano gruppi di parametri personalizzati, accertarsi di creare i gruppi di parametri compatibili con 8.0 corrispondenti. Accertarsi inoltre di specificarli durante il processo di aggiornamento.
**Nota**
Per la maggior parte delle impostazioni dei parametri, è possibile scegliere il gruppo di parametri personalizzati in due punti. Quando si crea il cluster o quando si associa il gruppo di parametri al cluster in un secondo momento.
Tuttavia, se si utilizza un'impostazione non predefinita per il parametro `lower_case_table_names`, è necessario impostare il gruppo di parametri personalizzati con questa impostazione in anticipo. Quindi specificare il gruppo di parametri quando si esegue il ripristino dello snapshot per creare il cluster. Qualsiasi modifica al parametro `lower_case_table_names` non ha effetto dopo la creazione del cluster.
È opportuno utilizzare la stessa impostazione per `lower_case_table_names` durante l'aggiornamento da Aurora MySQL versione 2 alla versione 3.
Con un Database globale Aurora basato su Aurora MySQL, è possibile eseguire un aggiornamento in loco da Aurora MySQL versione 2 alla versione 3 solo se il parametro `lower_case_table_names` è impostato sull’opzione predefinita e il database globale viene riavviato. Per ulteriori informazioni sui metodi disponibili all'uso, consulta [Aggiornamenti di una versione principale](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major).
## Modifiche delle proprietà del cluster tra versioni di Aurora MySQL
Quando esegui l'aggiornamento da Aurora MySQL versione 2 alla versione 3, assicurati di modificare le applicazioni o gli script utilizzati per configurare o gestire i cluster e le istanze database Aurora MySQL.
Inoltre, modifica il codice che manipola i gruppi di parametri per tenere conto del fatto che i nomi dei gruppi di parametri predefiniti sono diversi per i cluster compatibili con 5.7 e 8.0. I nomi dei gruppi di parametri predefiniti per i cluster di Aurora MySQL versione 2 e 3 sono `default.aurora-mysql5.7` e `default.aurora-mysql8.0`, rispettivamente.
Ad esempio, è possibile che si disponga di codice simile al seguente applicabile al cluster prima di un aggiornamento.
```
# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1
```
Dopo avere aggiornato la versione principale del cluster, è necessario modificare tale codice nel modo seguente.
```
# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1
```
## Principali aggiornamenti in loco per database globali
Per un database globale Aurora, è possibile aggiornare il cluster di database globale. Aurora aggiorna automaticamente tutti i cluster nello stesso momento e assicura che tutti eseguano la stessa versione del motore. Questo requisito è dovuto al fatto che tutte le modifiche apportate alle tabelle di sistema, ai formati di file di dati e così via vengono replicate automaticamente in tutti i cluster secondari.
Segui le istruzioni in [Come funziona l'aggiornamento della versione principale di Aurora MySQL in loco](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence). Quando specifichi cosa aggiornare, assicurati di scegliere il cluster di database globale anziché uno dei cluster in esso contenuti.
Se utilizzi il plugin Console di gestione AWS, scegli l'articolo con il ruolo **Global database (Database globale)**.
![\[Aggiornamento del cluster di database globale\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
Se si utilizza la AWS CLI o l'API RDS, avviare il processo di aggiornamento chiamando il comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) o l'operazione [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html). Utilizzare uno di questi anziché `modify-db-cluster` o `ModifyDBCluster`.
**Nota**
Non è possibile specificare un gruppo di parametri personalizzato per il cluster di database globale mentre si esegue un aggiornamento della versione principale del database globale Aurora. Creare i gruppi di parametri personalizzati in ciascuna regione del cluster globale. Applicarli quindi manualmente ai cluster regionali dopo l'aggiornamento.
Per aggiornare la versione principale di un cluster database globale Aurora MySQL mediante la AWS CLI, utilizza il comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) con i seguenti parametri obbligatori:
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
Nell'esempio seguente il cluster database globale viene aggiornato ad Aurora MySQL versione 3.04.2.
**Example**
Per Linux, macOS o Unix:
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.04.2 \
--allow-major-version-upgrade
```
Per Windows:
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine aurora-mysql ^
--engine-version 8.0.mysql_aurora.3.04.2 ^
--allow-major-version-upgrade
```
## Aggiornamenti in loco per cluster di database con repliche di lettura tra Regioni
È possibile aggiornare un cluster di database Aurora con una replica di lettura tra Regioni utilizzando la procedura di aggiornamento in loco, ma occorre tenere a mente alcune considerazioni:
+ È necessario prima aggiornare il cluster di database della replica di lettura. Se si tenta di eseguire prima l’aggiornamento del cluster primario, si riceverà un messaggio di errore del tipo seguente:
Unable to upgrade DB cluster test-xr-primary-cluster because the associated Aurora cross-Region replica test-xr-replica-cluster isn’t patched yet. Upgrade the Aurora cross-Region replica and try again.
Ciò significa che il cluster di database primario non può avere una versione del motore di database superiore a quella del cluster di replica.
+ Prima di aggiornare il cluster di database primario, interrompi il carico di lavoro di scrittura e disabilita tutte le nuove richieste di connessione all’istanza database di scrittura del cluster primario.
+ Quando aggiorni il cluster primario, scegli un gruppo di parametri del cluster di database personalizzato con il parametro `binlog_format` impostato su un valore che supporti la replica con registrazione di log binari, ad esempio `MIXED`.
Per ulteriori informazioni sull'utilizzo di registrazione binaria con Aurora, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). Per ulteriori informazioni sulla modifica dei parametri di configurazione di Aurora MySQL, consulta [Parametri di configurazione Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md) e [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md).
+ Non lasciar passare troppo tempo tra l’aggiornamento del cluster di replica e l’aggiornamento del cluster di database primario. Si consiglia di non attendere oltre la finestra di manutenzione successiva.
+ Dopo aver aggiornato il cluster di database primario, riavvia la relativa istanza database di scrittura. Il gruppo di parametri del cluster di database personalizzato che abilita la replica binlog non ha effetto finché l’istanza database di scrittura non viene riavviata.
+ Non riavviare il carico di lavoro di scrittura e non abilitare le connessioni all’istanza database di scrittura prima di aver verificato che la replica tra Regioni sia stata riavviata e che il ritardo di replica nella Regione AWS sia pari a 0.