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:
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à.
Per informazioni sull’esecuzione di un aggiornamento a una versione secondaria per il cluster di database Aurora MySQL, consulta i seguenti argomenti.
Argomenti
Operazioni preliminari all’aggiornamento a una versione secondaria
Controlli preliminari per gli aggiornamenti a versioni secondarie per Aurora MySQL
Aggiornamento di Aurora MySQL modificando la versione del motore
Abilitazione degli aggiornamenti automatici tra versioni secondarie di Aurora MySQL
Utilizzo dell'applicazione di patch senza tempi di inattività
Operazioni preliminari all’aggiornamento a una versione secondaria
Si consiglia di eseguire le seguenti azioni per ridurre i tempi di inattività durante un aggiornamento a una versione secondaria:
La manutenzione del cluster di database Aurora deve essere eseguita durante un periodo di traffico ridotto. Usa 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. Per ulteriori informazioni sulla finestra di manutenzione del cluster di database, consulta Impostazione della finestra di manutenzione preferita del cluster database.
-
Utilizza AWS SDK che supportano il jitter e il backoff esponenziali come best practice. Per ulteriori informazioni, consulta Backoff esponenziale e 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
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.
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.
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 alternativa di aggiornamento blu/verde
In alcune situazioni, la priorità principale è eseguire il passaggio immediato dal cluster precedente a quello aggiornato. In tali situazioni, è possibile utilizzare un processo in più fasi che esegue i cluster vecchi e nuovi affiancati. Qui, i dati vengono replicati dal cluster precedente a quello nuovo fino a quando il nuovo cluster non prende il controllo. Per informazioni dettagliate, consultare Utilizzo delle implementazioni blu/verde Amazon Aurora per gli aggiornamenti del database.
