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à.
Ti consigliamo di rivedere il materiale di background in Come funziona l'aggiornamento della versione principale di Aurora MySQL in loco.
Esegui qualsiasi pianificazione e test prima dell'aggiornamento, come descritto in. Pianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL
L'esempio seguente aggiorna il cluster mydbcluster-cluster
DB alla versione 3.04.1 di Aurora MySQL.
Per aggiornare la versione principale di un cluster di database Aurora MySQL
-
Accedi a AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/
. -
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.
-
Nel riquadro di navigazione, scegliere Databases (Database).
-
Scegliere il cluster di database che si desidera modificare.
-
Scegliere Modify (Modifica).
-
Per Versione, scegli una versione principale di Aurora MySQL.
In genere consigliamo di utilizzare la versione secondaria più recente della versione principale. Qui, scegliamo la versione predefinita corrente.
-
Scegli Continue (Continua).
-
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).
-
(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-place di Aurora My SQL per la procedura da intraprendere.
-
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.
Nota
Per eseguire questo passaggio, è necessario riavviare nuovamente il cluster per applicare il nuovo gruppo di parametri.
-
(Facoltativo) Dopo avere completato i test successivi all'aggiornamento, eliminare lo snapshot manuale che Aurora ha creato all'inizio dell'aggiornamento.
Per aggiornare la versione principale di un cluster Aurora MySQL DB, usa il AWS CLI modify-db-clustercomando 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
L'esempio seguente aggiorna il cluster sample-cluster
DB alla versione 3.04.1 di Aurora MySQL. L'aggiornamento avviene immediatamente, invece di attendere la successiva finestra di manutenzione.
Esempio
In Linux, macOS, oppure 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
In 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
Puoi combinare altri comandi CLI con modify-db-cluster
per creare un end-to-end processo automatizzato per l'esecuzione e la verifica degli aggiornamenti. Per maggiori informazioni ed esempi, vedi Aurora Il mio tutorial di aggiornamento SQL sul posto.
Nota
Se il cluster fa parte di un database globale Aurora, la procedura di aggiornamento in loco è leggermente diversa. Si chiama l'operazione di modify-global-clustercomando invece di. modify-db-cluster
Per ulteriori informazioni, consulta Principali aggiornamenti in loco per database globali.
-
DBClusterIdentifier
-
Engine
-
EngineVersion
-
AllowMajorVersionUpgrade
-
ApplyImmediately
( impostato sutrue
ofalse
)
Nota
Se il cluster fa parte di un database globale Aurora, la procedura di aggiornamento in loco è leggermente diversa. Si chiama l'operazione invece di. ModifyGlobalClusterModifyDBCluster
Per ulteriori informazioni, consulta Principali aggiornamenti in loco per database globali.
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 sul posto da Aurora MySQL versione 2 alla versione 3 solo se si imposta il parametro su default e si riavvia il database globale. lower_case_table_names
Per ulteriori informazioni sui metodi disponibili all'uso, consulta Aggiornamenti di una versione principale.
Importante
Se si specifica un gruppo di parametri personalizzato durante il processo di aggiornamento, accertarsi di riavviare manualmente il cluster al termine dell'aggiornamento. In questo modo, il cluster inizia a utilizzare le impostazioni dei parametri personalizzati.
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. Quando specifichi cosa aggiornare, assicurati di scegliere il cluster di database globale anziché uno dei cluster in esso contenuti.
Se utilizzi il, scegli l'elemento con il ruolo Database AWS Management Console globale.

Se utilizzi l'API AWS CLI o RDS, avvia il processo di aggiornamento chiamando il modify-global-clustercomando o l'ModifyGlobalClusteroperazione. 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 di database globale Aurora MySQL utilizzando il AWS CLI, usa il modify-global-clustercomando con i seguenti parametri richiesti:
-
--global-cluster-identifier
-
--engine aurora-mysql
-
--engine-version
-
--allow-major-version-upgrade
L'esempio seguente aggiorna il cluster di database globale alla versione 3.04.2 di Aurora MySQL.
Esempio
In Linux, macOS, oppure 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
In 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 sul posto per cluster DB con repliche di lettura interregionali
È possibile aggiornare un cluster Aurora DB con una replica di lettura interregionale utilizzando la procedura di aggiornamento sul posto, ma ci sono alcune considerazioni:
-
È necessario prima aggiornare il cluster DB di replica di lettura. Se si tenta di aggiornare prima il cluster primario, verrà visualizzato un messaggio di errore simile al seguente:
Impossibile aggiornare il cluster DB test-xr-primary-cluster perché la replica Aurora Cross-Region associata test-xr-replica-cluster non è ancora stata patchata. Aggiorna la replica Aurora Cross-Region e riprova.
Ciò significa che il cluster DB primario non può avere una versione del motore DB superiore a quella del cluster di replica.
-
Prima di aggiornare il cluster DB primario, interrompi il carico di lavoro di scrittura e disabilita tutte le nuove richieste di connessione all'istanza Writer DB del cluster primario.
-
Quando aggiorni il cluster primario, scegli un gruppo di parametri del cluster DB personalizzato con il
binlog_format
parametro impostato su un valore che supporti la replica con logging binario, ad esempio.MIXED
Per ulteriori informazioni sull'utilizzo di registrazione binaria con Aurora, consulta Replica tra Aurora e SQL My o tra Aurora e un altro cluster Aurora DB (replica di log binari). Per ulteriori informazioni sulla modifica dei parametri di configurazione di Aurora MySQL, consulta Parametri di configurazione Aurora MySQL e .
-
Non aspettate troppo tempo per aggiornare il cluster DB primario dopo aver aggiornato il cluster di replica. Si consiglia di non attendere più a lungo della finestra di manutenzione successiva.
-
Dopo aver aggiornato il cluster DB primario, riavvia la relativa istanza Writer DB. Il gruppo di parametri del cluster DB personalizzato che abilita la replica binlog non ha effetto finché l'istanza DB writer non viene riavviata.
-
Non riprendete il carico di lavoro di scrittura né abilitate le connessioni all'istanza DB di scrittura finché non confermate che la replica tra regioni è stata riavviata e che il ritardo di replica nell'istanza secondaria è 0. Regione AWS