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.
## 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).