Come eseguire un aggiornamento in loco

Ti consigliamo di rivedere il materiale di background in Come funziona l'aggiornamento della versione principale di Aurora MySQL in loco.

Esegui eventuali operazioni di pianificazione e test pre-aggiornamento, come descritto in Pianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL.

Console

Nell'esempio seguente viene aggiornato il cluster database mydbcluster-cluster ad Aurora MySQL versione 3.04.1.

Per aggiornare la versione principale di un cluster di database Aurora MySQL

1. Accedi alla AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

2. 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.

3. Nel riquadro di navigazione, scegliere Databases (Database).

4. Scegliere il cluster di database che si desidera modificare.

5. Scegliere Modify (Modifica).

6. Per Versione, scegli una versione principale di Aurora MySQL.

   In genere consigliamo di utilizzare la versione secondaria più recente della versione principale. In questo caso viene scelta la versione predefinita corrente.

   

7. Scegli Continua.

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

9. (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 loco di Aurora MySQL per la procedura da intraprendere.

10. 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.

11. (Facoltativo) Dopo avere completato i test successivi all'aggiornamento, eliminare lo snapshot manuale che Aurora ha creato all'inizio dell'aggiornamento.

AWS CLI

Per aggiornare la versione principale di un cluster di database Aurora MySQL, utilizzare il comando AWS CLI CLI modify-db-cluster 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

Nell'esempio seguente viene aggiornato il cluster database sample-cluster ad Aurora MySQL versione 3.04.1. L'aggiornamento avviene immediatamente, invece di attendere la successiva finestra di manutenzione.

Esempio

Per Linux, macOS o 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

Per 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

È possibile combinare altri comandi della CLI con modify-db-cluster per creare un processo end-to-end automatizzato per l'esecuzione e la verifica degli aggiornamenti. Per maggiori informazioni ed esempi, vedi Esercitazione sull'aggiornamento in loco di Aurora MySQL.

Nota

Se il cluster fa parte di un database globale Aurora, la procedura di aggiornamento in loco è leggermente diversa. Si chiama l'operazione del comando modify-global-cluster invece di modify-db-cluster. Per ulteriori informazioni, consulta Principali aggiornamenti in loco per database globali.

API RDS

Per aggiornare la versione principale di un cluster di database Aurora MySQL, utilizza l'operazione ModifyDBCluster dell'API RDS con i seguenti parametri obbligatori:

• DBClusterIdentifier

• Engine

• EngineVersion

• AllowMajorVersionUpgrade

• ApplyImmediately ( impostato su true o false)

Nota

Se il cluster fa parte di un database globale Aurora, la procedura di aggiornamento in loco è leggermente diversa. Si chiama l'operazione ModifyGlobalCluster invece di ModifyDBCluster. 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 in loco da Aurora MySQL versione 2 alla versione 3 solo se il parametro lower_case_table_names è impostato sull’opzione predefinita e il database globale viene riavviato. Per ulteriori informazioni sui metodi disponibili all'uso, consulta Aggiornamenti di una versione principale.

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 plugin AWS Management Console, scegli l'articolo con il ruolo Global database (Database globale).

Se si utilizza la AWS CLI o l'API RDS, avviare il processo di aggiornamento chiamando il comando modify-global-cluster o l'operazione ModifyGlobalCluster. 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 database globale Aurora MySQL mediante la AWS CLI, utilizza il comando modify-global-cluster con i seguenti parametri obbligatori:

• --global-cluster-identifier

• --engine aurora-mysql

• --engine-version

• --allow-major-version-upgrade

Nell'esempio seguente il cluster database globale viene aggiornato ad Aurora MySQL versione 3.04.2.

Esempio

Per Linux, macOS o 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

Per 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 in loco per cluster di database con repliche di lettura tra Regioni

È possibile aggiornare un cluster di database Aurora con una replica di lettura tra Regioni utilizzando la procedura di aggiornamento in loco, ma occorre tenere a mente alcune considerazioni:

• È necessario prima aggiornare il cluster di database della replica di lettura. Se si tenta di eseguire prima l’aggiornamento del cluster primario, si riceverà un messaggio di errore del tipo seguente:

  Unable to upgrade DB cluster test-xr-primary-cluster because the associated Aurora cross-Region replica test-xr-replica-cluster isn’t patched yet. Upgrade the Aurora cross-Region replica and try again.

  Ciò significa che il cluster di database primario non può avere una versione del motore di database superiore a quella del cluster di replica.

• Prima di aggiornare il cluster di database primario, interrompi il carico di lavoro di scrittura e disabilita tutte le nuove richieste di connessione all’istanza database di scrittura del cluster primario.

• Quando aggiorni il cluster primario, scegli un gruppo di parametri del cluster di database personalizzato con il parametro binlog_format impostato su un valore che supporti la replica con registrazione di log binari, ad esempio MIXED.

  Per ulteriori informazioni sull'utilizzo di registrazione binaria con Aurora, consulta Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari). Per ulteriori informazioni sulla modifica dei parametri di configurazione di Aurora MySQL, consulta Parametri di configurazione Aurora MySQL e Gruppi di parametri per Amazon Aurora.

• Non lasciar passare troppo tempo tra l’aggiornamento del cluster di replica e l’aggiornamento del cluster di database primario. Si consiglia di non attendere oltre la finestra di manutenzione successiva.

• Dopo aver aggiornato il cluster di database primario, riavvia la relativa istanza database di scrittura. Il gruppo di parametri del cluster di database personalizzato che abilita la replica binlog non ha effetto finché l’istanza database di scrittura non viene riavviata.

• Non riavviare il carico di lavoro di scrittura e non abilitare le connessioni all’istanza database di scrittura prima di aver verificato che la replica tra Regioni sia stata riavviata e che il ritardo di replica nella Regione AWS sia pari a 0.