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 della versione secondaria o del livello di patch di un cluster di database Aurora MySQL
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:
+ [Aggiornamento di Aurora MySQL modificando la versione del motore](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md) (per Aurora MySQL versione 2 e 3)
+ [Abilitazione degli aggiornamenti automatici tra versioni secondarie di Aurora MySQL](AuroraMySQL.Updates.AMVU.md)
Per informazioni su come l'applicazione di patch senza tempi di inattività può ridurre le interruzioni durante il processo di aggiornamento, consulta [Utilizzo dell'applicazione di patch senza tempi di inattività](AuroraMySQL.Updates.ZDP.md).
Per informazioni sull’esecuzione di un aggiornamento a una versione secondaria per il cluster di database Aurora MySQL, consulta i seguenti argomenti.
**Topics**
+ [Operazioni preliminari all’aggiornamento a una versione secondaria](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [Controlli preliminari per gli aggiornamenti a versioni secondarie per Aurora MySQL](#AuroraMySQL.minor-upgrade-prechecks)
+ [Aggiornamento di Aurora MySQL modificando la versione del motore](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md)
+ [Abilitazione degli aggiornamenti automatici tra versioni secondarie di Aurora MySQL](AuroraMySQL.Updates.AMVU.md)
+ [Utilizzo dell'applicazione di patch senza tempi di inattività](AuroraMySQL.Updates.ZDP.md)
+ [Tecnica di aggiornamento alternativa blue/green](#AuroraMySQL.UpgradingMinor.BlueGreen)
## 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 questo supporto per il backoff e il jitter esponenziali come best practice. Per ulteriori informazioni, consulta [Backoff esponenziale e jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/).
## Controlli preliminari per gli aggiornamenti a versioni secondarie per Aurora MySQL
Quando avvii un aggiornamento a una versione secondaria, Amazon Aurora esegue automaticamente dei controlli preliminari.
Questi controlli preliminari sono obbligatori. Non puoi scegliere di saltarli. I controlli preliminari offrono i seguenti vantaggi:
+ Ti consentono di evitare tempi di inattività non pianificati durante l'aggiornamento.
+ Se sono presenti incompatibilità, Amazon Aurora impedisce l’aggiornamento e fornisce un log per ottenere informazioni sulle stesse. Puoi quindi utilizzare il log per preparare il database per l’aggiornamento riducendo le incompatibilità. Per informazioni dettagliate sulla rimozione di eventuali incompatibilità, consulta [Preparazione dell’installazione per l’aggiornamento](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) nella documentazione di MySQL.
I controlli preliminari vengono eseguiti prima dell'arresto dell'istanza database per l'aggiornamento, il che significa che non generano alcun tempo di inattività durante l'esecuzione. Se i controlli preliminari rilevano un’incompatibilità, Aurora annulla automaticamente l’aggiornamento prima che l’istanza database venga arrestata. Aurora genera anche un evento per l’incompatibilità. Per ulteriori informazioni sugli eventi di Amazon Aurora, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md).
Aurora memorizza informazioni dettagliate su ciascuna incompatibilità nel file di log `PrePatchCompatibility.log`. Nella maggior parte dei casi, la voce di log include un collegamento alla documentazione MySQL utile per correggere l'incompatibilità. Per ulteriori informazioni sulla visualizzazione dei file di log, consultare [Visualizzazione ed elenco dei file di log del database](USER_LogAccess.Procedural.Viewing.md).
A causa della natura dei controlli preliminari, questi analizzano gli oggetti nel database. Questa analisi comporta il consumo di risorse e incrementa il tempo di completamento dell'aggiornamento.
# Aggiornamento di Aurora MySQL modificando la versione del motore
L’aggiornamento della versione secondaria di un cluster di database Aurora MySQL applica correzioni aggiuntive e nuove funzionalità a un cluster esistente.
Questo tipo di aggiornamento si applica ai cluster Aurora MySQL in cui la versione originale e la versione aggiornata sono entrambi nella versione principale di Aurora MySQL, ossia 2 o 3. Il processo è semplice e veloce perché non comporta alcuna conversione dei metadati di Aurora MySQL o la riorganizzazione dei dati della tabella.
Puoi eseguire questo tipo di aggiornamento modificando la versione del motore del cluster di database utilizzando la Console di gestione AWS, l'AWS CLI, o l'API RDS. Ad esempio, se nel cluster è in esecuzione Aurora MySQL 3.x, scegli una versione 3.x superiore.
Se si sta eseguendo un aggiornamento secondario su un Database globale Aurora, è necessario aggiornare tutti i cluster secondari prima di aggiornare il cluster primario.
**Nota**
Per eseguire un aggiornamento della versione secondaria ad Aurora MySQL versione 3.04.\$1 o successive, o alla versione 2.12\$1, utilizza la seguente procedura:
Rimuovi tutte le regioni secondarie dal cluster globale. Seguire la procedura riportata in [Rimozione di un cluster da un database globale Amazon Aurora](aurora-global-database-detaching.md).
Aggiorna la versione del motore della regione primaria alla versione 3.04.\$1 o successive o alla versione 2.12.\$1, in base alle esigenze. Seguire la procedura riportata in [To modify the engine version of a DB cluster](#modify-db-cluster-engine-version).
Aggiungi le regioni secondarie al cluster globale. Seguire la procedura riportata in [Aggiunta di una Regione AWS a un database globale Amazon Aurora](aurora-global-database-attaching.md).
**Per modificare la versione del motore di un cluster di database**
+ **Utilizzando la console** – Modificare le proprietà del cluster. Nella finestra **Modify DB cluster (Modifica il cluster di database)** cambia la versione del motore Aurora MySQL nella casella **DB engine version (Versione motore database)**. Se non hai familiarità con la procedura generale per la modifica di un cluster, segui le istruzioni riportate in [Modifica del cluster di database tramite la console, la CLI e l'API](Aurora.Modifying.md#Aurora.Modifying.Cluster).
+ **Utilizzando la AWS CLI**: richiamare il comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) della AWS CLI e specificare il nome del cluster di database per l'opzione `--db-cluster-identifier` e la versione del motore per l'opzione `--engine-version`.
Ad esempio, per eseguire l'aggiornamento ad Aurora MySQL versione 3.04.1, imposta l'opzione `--engine-version` su `8.0.mysql_aurora.3.04.1`. Specifica l'opzione `--apply-immediately` per aggiornare immediatamente la versione del motore per il cluster di database.
+ **Con l'API RDS** – Chiama l'operazione API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) e specifica il nome del cluster di database per il parametro `DBClusterIdentifier` e la versione del motore per il parametro `EngineVersion`. Imposta il parametro `ApplyImmediately` su `true` per aggiornare immediatamente la versione del motore per il cluster di database.
# Abilitazione degli aggiornamenti automatici tra versioni secondarie di Aurora MySQL
Per un cluster di database Amazon Aurora MySQL, puoi specificare che Aurora aggiorni automaticamente il cluster di database alle nuove versioni secondarie. Puoi farlo impostando la proprietà `AutoMinorVersionUpgrade` (**Aggiornamento automatico versione secondaria** nella Console di gestione AWS) del cluster di database.
Gli aggiornamenti automatici vengono eseguiti durante le finestre di manutenzione. Se le singole istanze database nel cluster database hanno finestre di manutenzione diverse dalla finestra di manutenzione del cluster, la finestra di manutenzione del cluster ha la precedenza.
L'aggiornamento automatico della versione secondaria non si applica ai seguenti tipi di cluster Aurora MySQL:
+ Cluster che fanno parte di un database globale Aurora
+ Cluster con repliche tra regioni
La durata dell'interruzione varia a seconda del carico di lavoro, della dimensione del cluster, della quantità di dati di log binari e se Aurora può utilizzare la funzionalità ZDP (zero-downtime patching). Aurora riavvia il cluster di database, pertanto potrebbe verificarsi un breve periodo di indisponibilità prima di riprendere l'utilizzo del cluster. In particolare, la quantità di dati dei log binari influisce sui tempi di ripristino. L'istanza database elabora i dati del log binario durante il ripristino. Pertanto un volume elevato di dati dei log binari aumenta il tempo di recupero.
**Nota**
Aurora esegue gli aggiornamenti automatici se tutte le istanze database nel tuo cluster di database hanno l’impostazione `AutoMinorVersionUpgrade` abilitata. Per informazioni su come effettuare tale impostazione, e sul relativo funzionamento quando 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).
Quindi, se esiste un percorso di aggiornamento per le istanze del cluster di database a una versione secondaria del motore di database con l’opzione `AutoUpgrade` impostata su true, l’aggiornamento verrà eseguito. L’impostazione `AutoUpgrade` è dinamica e viene configurata da RDS.
Gli aggiornamenti automatici delle versioni secondarie vengono eseguiti sulla versione secondaria predefinita.
È possibile utilizzare un comando CLI come il seguente per verificare lo stato dell'impostazione `AutoMinorVersionUpgrade` per tutte le istanze database nei cluster Aurora MySQL.
```
aws rds describe-db-instances \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
```
Questo comando genera un output simile al seguente:
```
[
{
"DBInstanceIdentifier": "db-t2-medium-instance",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": true
},
{
"DBInstanceIdentifier": "db-t2-small-original-size",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": false
},
{
"DBInstanceIdentifier": "instance-2020-05-01-2332",
"DBClusterIdentifier": "cluster-57-2020-05-01-4615",
"AutoMinorVersionUpgrade": true
},
... output omitted ...
```
In questo esempio, l'impostazione **Abilita aggiornamento automatico versione secondaria** è disattivata per il cluster di database `cluster-57-2020-06-03-6411`, perché è disattivata per una delle istanze database del cluster.
# Utilizzo dell'applicazione di patch senza tempi di inattività
L'esecuzione di aggiornamenti per i cluster Aurora MySQL DB comporta la possibilità di un'interruzione quando il database viene spento e durante l'aggiornamento. Per impostazione predefinita, se si avvia l'aggiornamento mentre il database è occupato, si perdono tutte le connessioni e le transazioni elaborate dal cluster di database. Se si aspetta che il database sia inattivo per eseguire l'aggiornamento, potrebbe essere necessario attendere a lungo.
L'applicazione di patch senza tempi di inattività si basa sul miglior tentativo per preservare le connessioni client attraverso un aggiornamento Aurora MySQL. Se l'applicazione di patch senza tempi di inattività viene completata correttamente, le sessioni delle applicazioni vengono conservate e il motore del database si riavvia mentre l'aggiornamento è in corso. Il riavvio del motore del database può causare un calo del throughput della durata di alcuni secondi fino a circa un minuto.
ZDP non si applica a quanto segue:
+ Patch e aggiornamenti del sistema operativo
+ Aggiornamenti di una versione principale
ZDP è disponibile per tutte le versioni di Aurora MySQL e le classi di istanze database supportate.
ZDP non è supportato per i database globali Aurora Serverless v1 o Aurora.
**Nota**
Consigliamo di utilizzare le classi di istanza database T solo per i server di sviluppo e test o altri server non di produzione. Per ulteriori informazioni sulle classi di istanza T, consulta [Utilizzo delle classi di istanza T per lo sviluppo e i test](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
È possibile visualizzare i parametri degli attributi importanti durante ZDP nel log degli errori MySQL. È inoltre possibile visualizzare informazioni su quando Aurora MySQL utilizza ZDP o sceglie di non utilizzare ZDP nella pagina **Eventi** nella Console di gestione AWS.
In Aurora MySQL, Aurora può eseguire una patch senza tempi di inattività indipendentemente dal fatto che la replica dei log binari sia abilitata o meno. Se la replica dei log binari è abilitata, Aurora MySQL elimina automaticamente la connessione alla destinazione binlog durante un'operazione di applicazione di patch senza tempi di inattività. Aurora MySQL si riconnette automaticamente alla destinazione binlog e riprende la replica al termine del riavvio.
ZDP funziona anche in combinazione con i miglioramenti del riavvio in Aurora MySQL. L'applicazione di patch all'istanza database scrittore applica automaticamente le patch ai lettori contemporaneamente. Dopo aver applicato la patch, Aurora ripristina le connessioni sia sulle istanze DB dello scrittore che del lettore.
L'applicazione di patch senza tempi di inattività potrebbe non essere completata correttamente nelle condizioni seguenti:
+ Durante l'esecuzione di query o transazioni di lunga durata. Se Aurora è in grado di eseguire l’applicazione di patch senza tempi di inattività, qualsiasi transazione aperta è annullata, ma le relative connessioni vengono mantenute.
+ Sono in uso tabelle temporanee, blocchi utente temporanei e blocchi tabella temporanei, per esempio durante l’esecuzione di istruzioni DDL (Data Definition Language). Aurora interrompe queste connessioni.
+ Esistono modifiche ai parametri in attesa.
Se non è disponibile alcuna finestra temporale appropriata per l'esecuzione dell'applicazione di patch senza tempi di inattività a causa di una o più di queste condizioni, viene ripristinato il comportamento standard dell'applicazione delle patch.
Sebbene le connessioni rimangano intatte a seguito di un'operazione ZDP riuscita, alcune variabili e funzionalità vengono reinizializzate. I seguenti tipi di informazioni non vengono conservati tramite un riavvio causato da zero-downtime patching:
+ Variabili globali. Aurora ripristina le variabili di sessione, ma non ripristina le variabili globali dopo il riavvio.
+ Variabili di stato. In particolare, il valore di attività riportato dallo stato del motore viene ripristinato dopo un riavvio che utilizza i meccanismi ZDR o ZDP.
+ `LAST_INSERT_ID`.
+ Stato `auto_increment` in memoria per le tabelle. Lo stato di incremento automatico in memoria viene reinizializzato. Per ulteriori informazioni sui valori di incremento automatico, consulta il [Manuale di riferimento di MySQL](https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization).
+ Informazioni diagnostiche dalle tabelle `INFORMATION_SCHEMA` e `PERFORMANCE_SCHEMA`. Queste informazioni diagnostiche vengono visualizzate anche nell'output di comandi come `SHOW PROFILE` e `SHOW PROFILES`.
Le seguenti attività relative a zero-downtime restart sono riportate nella pagina **Eventi**:
+ Tentativo di aggiornare il database senza tempi di inattività.
+ Tentativo di aggiornare il database senza tempi di inattività terminato. L'evento riporta quanto tempo è durato il processo. L'evento segnala inoltre quante connessioni sono state mantenute durante il riavvio e quante connessioni sono state interrotte. È possibile consultare il registro degli errori del database per visualizzare ulteriori dettagli su ciò che è successo durante il riavvio.
## Tecnica di aggiornamento alternativa blue/green
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).