Aggiornamento della versione principale di un cluster di database Amazon Aurora MySQL - Amazon Aurora
Aggiornamento da Aurora MySQL versione 2 alla versione 3Procedure di aggiornamento a una versione principale di Aurora MySQLCome funziona l'aggiornamento della versione principale di Aurora MySQL in locoPianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL

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 principale di un cluster di database Amazon Aurora MySQL

In un numero di versione di Aurora MySQL come 3.04.1, il 3 rappresenta la versione principale. Aurora MySQL versione 2 è compatibile con MySQL 5.7. Aurora MySQL versione 3 è compatibile con MySQL 8.0.

L'aggiornamento tra le versioni principali richiede una pianificazione e test più estesi rispetto all'aggiornamento a una versione secondaria. Il processo può richiedere un tempo considerevole. Al termine dell'aggiornamento, è possibile che sia necessario compiere ulteriori operazioni. Ad esempio, ciò potrebbe verificarsi a causa di differenze nella compatibilità SQL o della modalità di funzionamento di alcune caratteristiche correlate a MySQL. Oppure potrebbe verificarsi a causa delle diverse impostazioni dei parametri tra la vecchia e la nuova versione.

Indice

Aggiornamento da Aurora MySQL versione 2 alla versione 3

Se si dispone di un cluster compatibile con MySQL 5.7 e si desidera aggiornarlo a un cluster compatibile con MySQL 8.0, è possibile eseguire un processo di aggiornamento sul cluster stesso. Questo tipo di aggiornamento è un aggiornamento in loco, a differenza degli aggiornamenti che si eseguono creando un nuovo cluster. Questa tecnica mantiene lo stesso endpoint e altre caratteristiche del cluster. L'aggiornamento è relativamente veloce perché non richiede la copia di tutti i dati in un nuovo volume cluster. Questa stabilità consente di ridurre al minimo eventuali modifiche di configurazione nelle applicazioni. Inoltre, consente di ridurre la quantità di test per il cluster aggiornato. Questo perché il numero di istanze database e le relative classi di istanza rimangono identiche.

Il meccanismo di aggiornamento utilizzato comporta l'arresto del cluster di database durante l'operazione. Aurora esegue un arresto pulito e completa le operazioni in sospeso, come il rollback delle transazioni e l'eliminazione degli annullamenti. Per ulteriori informazioni, consulta Come funziona l'aggiornamento della versione principale di Aurora MySQL in loco.

Il metodo di aggiornamento locale è conveniente, in quanto è semplice da eseguire e riduce al minimo le modifiche alla configurazione delle applicazioni associate. Ad esempio, un aggiornamento in loco conserva gli endpoint e il set di istanze database per il cluster. Tuttavia, il tempo necessario per un aggiornamento in loco può variare a seconda delle proprietà dello schema e dell'attività del cluster. Pertanto, a seconda delle esigenze del cluster, è possibile scegliere tra le tecniche di aggiornamento:

Per informazioni generali su Aurora MySQL versione 3 e sulle nuove funzionalità, consultare Aurora My SQL versione 3 compatibile con My 8.0 SQL.

Per informazioni dettagliate sulla pianificazione di un aggiornamento, consultare Pianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL e Come eseguire un aggiornamento in loco.

Procedure di aggiornamento a una versione principale di Aurora MySQL

Non tutti i tipi o le versioni di cluster Aurora MySQL possono utilizzare il meccanismo di aggiornamento in loco. È possibile conoscere la procedura di aggiornamento appropriata per ogni cluster Aurora MySQL consultando la tabella seguente.

Tipo di cluster di database Aurora MySQL Può utilizzare l'aggiornamento in loco? Azione

Cluster con provisioning MySQL Aurora, versione 2

Sì

L'aggiornamento sul posto è supportato per i cluster Aurora MySQL compatibili con MySQL 5.7.

Per informazioni sull’aggiornamento ad Aurora MySQL versione 3, consulta Pianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL e Come eseguire un aggiornamento in loco.

Cluster con provisioning MySQL Aurora, versione 3

Non applicabile

Utilizza una procedura di aggiornamento della versione secondaria per eseguire l'aggiornamento tra le versioni di Aurora MySQL versione 3.

Aurora Serverless v1 cluster

Non applicabile

Aurora Serverless v1 è supportato per Aurora MySQL solo nella versione 2.

Aurora Serverless v2 cluster

Non applicabile

 Aurora Serverless v2 è supportato per Aurora MySQL solo nella versione 3.

Cluster in un database globale Aurora

Sì

Per eseguire l'aggiornamento di Aurora MySQL versione 2 alla versione 3, segui la procedura per eseguire un aggiornamento locale per i cluster in un database globale Aurora. Esegui l'aggiornamento sul cluster globale. Aurora esegue l'aggiornamento del cluster primario e di tutti i cluster secondari nel database globale nello stesso momento.

Se utilizzi l'API AWS CLI o RDS, chiama il modify-global-cluster comando o l'ModifyGlobalClusteroperazione anziché o. modify-db-cluster ModifyDBCluster

È possibile eseguire un aggiornamento sul posto da Aurora MySQL versione 2 alla versione 3 solo lower_case_table_names se il parametro è impostato come predefinito e si riavvia il database globale. Per ulteriori informazioni, consulta Aggiornamenti di una versione principale.

Cluster di query parallele

Sì

È possibile eseguire l'aggiornamento locale.

Cluster che costituisce la destinazione della replica del log binario

Probabile

Se la replica del log binario proviene da un cluster Aurora MySQL, è possibile eseguire un aggiornamento locale. Non è possibile eseguire l'aggiornamento se la replica del log binario proviene da un'istanza MySQL RDS o da un'istanza database MySQL on-premise. In tal caso, è possibile eseguire l'aggiornamento utilizzando il meccanismo di ripristino degli snapshot.

Cluster con zero istanze database

No

Utilizzando AWS CLI o l'API RDS, è possibile creare un cluster Aurora MySQL senza istanze DB collegate. Allo stesso modo, è inoltre possibile rimuovere tutte le istanze database da un cluster Aurora MySQL lasciando intatti i dati nel volume del cluster. Sebbene il cluster non abbia istanze database collegate, non è possibile eseguire l'aggiornamento in loco.

Il meccanismo di aggiornamento richiede un'istanza di scrittura nel cluster per eseguire conversioni sulle tabelle di sistema, sui file di dati e così via. In questo caso, utilizza l'API AWS CLI o l'API RDS per creare un'istanza writer per il cluster. Dopodiché è possibile eseguire l'aggiornamento in loco.

Cluster con backtrack abilitato

Sì

È possibile eseguire un aggiornamento sul posto per un cluster Aurora MySQL che utilizza la funzionalità Backtrack. Tuttavia, dopo l'aggiornamento, non è possibile eseguire il backtrack del cluster a un momento precedente l'aggiornamento.

Come funziona l'aggiornamento della versione principale di Aurora MySQL in loco

Aurora MySQL esegue l'aggiornamento della versione principale come processo in più fasi. È possibile controllare lo stato corrente di un aggiornamento. Alcuni passaggi dell'aggiornamento forniscono anche informazioni sullo stato di avanzamento. All'inizio di ciascuna fase, Aurora MySQL registra un evento. È possibile esaminare gli eventi man mano che si verificano nella pagina Events (Eventi) della console RDS. Per maggiori informazioni sull'utilizzo degli eventi, consulta Utilizzo delle notifiche di RDS eventi di Amazon.

Importante

Una volta avviato, il processo viene eseguito fino a quando l'aggiornamento va a buon fine o non riesce. Non è possibile annullare l'aggiornamento mentre è in corso. Se l'aggiornamento non riesce, Aurora esegue il rollback di tutte le modifiche e il cluster mantiene la versione del motore, i metadati e così via precedenti.

Il processo di aggiornamento è costituito da tre fasi:

  1. Aurora esegue una serie di controlli preliminari prima di iniziare il processo di aggiornamento. Il cluster continua a funzionare mentre Aurora esegue questi controlli. Ad esempio, il cluster non può avere transazioni XA nello stato preparato né avere istruzioni DDL (Data Definition Language) in corso di elaborazione. Ad esempio, potrebbe essere necessario arrestare le applicazioni che inviano determinati tipi di istruzioni SQL. Oppure si può semplicemente aspettare fino a quando alcune istruzioni di lunga durata non siano state completate. Dopodiché, si può riprovare a eseguire l'aggiornamento. Alcuni controlli verificano le condizioni che, pur non impedendo l'aggiornamento, potrebbero far sì che richieda molto tempo.

    Se Aurora rileva che le condizioni richieste non sono soddisfatte, modifica le condizioni identificate nei dettagli dell'evento. Segui le indicazioni riportate in Risoluzione dei problemi relativi all'aggiornamento in-place di Aurora My SQL. Se Aurora rileva condizioni che potrebbero rallentare l'aggiornamento, pianifica il monitoraggio dell'aggiornamento per un periodo prolungato.

  2. Aurora mette il cluster offline. Quindi Aurora esegue un insieme di test analoghi a quelli della fase precedente, per confermare che non si sono presentati nuovi problemi durante il processo di arresto. Se, a questo punto, Aurora rileva condizioni che impediscono l'aggiornamento, Aurora annulla l'aggiornamento e riporta il cluster in linea. In questo caso, verifica quando le condizioni non sono più applicabili e riavvia l'aggiornamento.

  3. Aurora crea uno snapshot del volume del cluster. Si supponga di scoprire problemi di compatibilità o di altro tipo di al termine dell'aggiornamento. Oppure si supponga di volere eseguire test utilizzando sia i cluster originali sia quelli aggiornati. In questi casi, è possibile eseguire il ripristino da questa snapshot per creare un nuovo cluster con la versione originale del motore e i dati originali.

    Suggerimento

    Questo snapshot è di tipo manuale. Tuttavia, Aurora può crearlo e continuare con il processo di aggiornamento anche se è stata raggiunta la quota per gli snapshot manuali. Questa istantanea rimane permanente (se necessario) finché non viene eliminata. Al termine di tutti i test successivi all'aggiornamento, è possibile eliminare questo snapshot per ridurre al minimo i costi di storage.

  4. Aurora clona il volume del cluster. La clonazione è un'operazione veloce che non comporta la copia dei dati effettivi della tabella. Se Aurora riscontra un problema durante l'aggiornamento, ripristina i dati originali dal volume del cluster clonato e riporta il cluster in linea. Il volume temporaneo clonato durante l'aggiornamento non è soggetto al normale limite del numero di cloni per un singolo volume cluster.

  5. Aurora esegue un arresto pulito per l'istanza database di scrittura. Durante l'arresto pulito, gli eventi di avanzamento vengono registrati ogni 15 minuti per le operazioni seguenti. È possibile esaminare gli eventi man mano che si verificano nella pagina Events (Eventi) della console RDS.

    • Aurora elimina i record di annullamento per le versioni precedenti delle righe.

    • Aurora esegue il rollback di tutte le transazioni non salvate.

  6. Aurora aggiorna la versione del motore sull'istanza database di scrittura:

    • Aurora installa il binario per la nuova versione del motore nell'istanza database di scrittura.

    • Aurora utilizza l'istanza database di scrittura per aggiornare i dati in formato compatibile con MySQL 5.7. Durante questa fase, Aurora modifica le tabelle di sistema ed esegue altre conversioni che influiscono sui dati nel volume del cluster. In particolare, Aurora aggiorna i metadati delle partizioni nelle tabelle di sistema affinché siano compatibili con il formato di partizione MySQL 5.7. Questa fase può richiedere molto tempo se le tabelle del cluster dispongono di un numero elevato di partizioni.

      Se durante questa fase si verificano degli errori, è possibile trovare i dettagli nei log degli errori di MySQL. Dopo l'avvio di questa fase, se il processo di aggiornamento non riesce per qualsiasi motivo, Aurora ripristina i dati originali dal volume cluster clonato.

  7. Aurora aggiorna la versione del motore sulle istanze database di lettura.

  8. Il processo di aggiornamento è completato. Aurora registra un evento finale per indicare che il processo di aggiornamento è stato completato correttamente. Ora il cluster di database sta eseguendo la nuova versione principale.

Pianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL

Per aiutarti a decidere il momento e l'approccio giusti per l'aggiornamento, puoi scoprire le differenze tra Aurora MySQL versione 3 e il tuo ambiente attuale:

Puoi inoltre trovare ulteriori suggerimenti e considerazioni sull'aggiornamento specifici di MySQL in Changes in MySQL 8.0 (Modifiche in MySQL 8.0)nel Manuale di riferimento MySQL. Per esempio, è possibile utilizzare il comando mysqlcheck --check-upgrade per analizzare i database Aurora MySQL esistenti e identificare potenziali problemi di aggiornamento.

Nota

Ti consigliamo di utilizzare classi di istanza database più grandi durante l’aggiornamento ad Aurora MySQL versione 3 utilizzando la tecnica di aggiornamento locale o di ripristino da snapshot. Esempi sono db.r5.24xlarge e db.r6g.16xlarge. Ciò consente di completare il processo di aggiornamento più rapidamente utilizzando la maggior parte della capacità della CPU disponibile sull'istanza database. Al termine dell'aggiornamento della versione principale, puoi passare alla classe di istanza database desiderata.

Dopo aver terminato l'aggiornamento stesso, è possibile seguire le procedure di post-aggiornamento in Pulizia post-aggiornamento per Aurora My versione 3 SQL. Infine, testare la funzionalità e le prestazioni dell'applicazione.

Se stai eseguendo la conversione da RDS da MySQL o dalla community MySQL, segui la procedura di migrazione spiegata in. Migrazione dei dati verso un cluster Amazon Aurora My DB SQL In alcuni casi, è possibile utilizzare la replica del log binario per sincronizzare i dati con un cluster Aurora MySQL versione 3 come parte della migrazione. In tal caso, il sistema di origine deve eseguire una versione compatibile con il cluster DB di destinazione.

Per assicurarsi che le applicazioni e le procedure di amministrazione funzionino correttamente dopo l'aggiornamento di un cluster tra versioni principali, eseguire parte della pianificazione e della preparazione in anticipo. Per vedere quali tipi di codice di gestione aggiornare per AWS CLI gli script o le applicazioni basate sull'API RDS, consulta. Come gli aggiornamenti in loco influiscono sui gruppi di parametri per un cluster Consultare anche Modifiche delle proprietà del cluster tra versioni di Aurora MySQL.

Per informazioni sui problemi che potresti riscontrare durante l'aggiornamento, consulta. Risoluzione dei problemi relativi all'aggiornamento in-place di Aurora My SQL In caso di problemi che potrebbero richiedere un lungo periodo di tempo per completare l'aggiornamento, è possibile verificare tali condizioni in anticipo e correggerle.

Nota

Un aggiornamento sul posto comporta la chiusura del cluster DB durante l'operazione. Aurora MySQL esegue un arresto pulito e completa operazioni eccezionali come l'annullamento della cancellazione. Un aggiornamento potrebbe richiedere molto tempo se ci sono molti record di annullamento da eliminare. Si consiglia di eseguire l'aggiornamento solo dopo che la lunghezza dell'elenco della cronologia (HLL) è bassa. Un valore generalmente accettabile per l'HLL è pari o inferiore a 100.000. Per ulteriori informazioni, consulta questo post del blog.

Simulazione dell'aggiornamento mediante clonazione del cluster DB

È possibile verificare la compatibilità dell'applicazione, le prestazioni, le procedure di manutenzione e considerazioni simili per il cluster aggiornato. A questo scopo, è possibile eseguire una simulazione dell'aggiornamento prima di eseguire l'aggiornamento reale. Questa tecnica può essere particolarmente utile per i cluster di produzione. In questo caso, è importante ridurre al minimo i tempi di inattività e disporre del cluster aggiornato pronto all'uso non appena l'aggiornamento è terminato.

Utilizza le fasi seguenti:

  1. Crea un clone del cluster originale. Segui la procedura riportata in Clonazione di un volume per un cluster di database Amazon Aurora.

  2. Imposta un insieme di istanze database di scrittura e di lettura analogo a quello del cluster originale.

  3. Esegui un aggiornamento in loco del cluster clonato. Segui la procedura riportata in Come eseguire un aggiornamento in loco.

    Avvia l'aggiornamento immediatamente dopo aver creato il clone. In questo modo, il volume del cluster è ancora identico allo stato del cluster originale. Se il clone rimane inattivo prima di eseguire l'aggiornamento, Aurora esegue i processi di pulizia del database in background. In tal caso, l'aggiornamento del clone non è una simulazione accurata dell'aggiornamento del cluster originale.

  4. Verifica la compatibilità e le prestazioni delle applicazioni, le procedure di amministrazione e così via, utilizzando il cluster clonato.

  5. Se riscontri problemi, modifica i tuoi piani di aggiornamento per tenerne conto. Ad esempio, adatta qualsiasi codice dell'applicazione affinché sia compatibile con il set di caratteristiche della versione superiore. Stima il tempo necessario per l'aggiornamento in base alla quantità di dati nel cluster. È inoltre possibile scegliere di pianificare l'aggiornamento per un momento in cui il cluster non è occupato.

  6. Dopo avere verificato che le applicazioni e il carico di lavoro funzionano correttamente con il cluster di test, puoi eseguire l'aggiornamento locale per il cluster di produzione.

  7. Agisci per ridurre al minimo il tempo di inattività totale del cluster durante un aggiornamento della versione principale. A questo scopo, assicurati che il carico di lavoro sul cluster sia basso o zero al momento dell'aggiornamento. In particolare, assicurati che non vi siano transazioni di lunga durata in corso all'avvio dell'aggiornamento.

Distribuzioni blu/verdi

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, consultare Utilizzo di Amazon Aurora Blue/Green Deployments per gli aggiornamenti del database.