Aggiornamento della versione principale di un cluster di database Amazon Aurora MySQL

In un numero di versione di Aurora MySQL come 2.12.1, il 2 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.

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 MySQL versione 3 compatibile con MySQL 8.0.

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.

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.

Dopo aver terminato l'aggiornamento stesso, è possibile seguire le procedure di post-aggiornamento in Pulizia post-aggiornamento per Aurora MySQL versione 3. 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 di dati a un cluster di database Amazon Aurora MySQL 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 sapere quali problemi potresti riscontrare durante l'aggiornamento, consulta. Risoluzione dei problemi relativi all'aggiornamento in loco di Aurora MySQL In caso di problemi che potrebbero richiedere un lungo periodo di tempo per completare l'aggiornamento, è possibile verificare tali condizioni in anticipo e correggerle.

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:

Utilizzo della tecnica di aggiornamento blu-verde

Puoi anche creare una distribuzione blu/verde che esegua 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 delle implementazioni blu/verde Amazon RDS per gli aggiornamenti del database.

Controlli preliminari di aggiornamento delle versioni principali per Aurora MySQL

MySQL 8.0 include un certo numero di incompatibilità con MySQL 5.7. Queste incompatibilità possono causare problemi durante l'aggiornamento da Aurora MySQL versione 2 alla versione 3. Potrebbe essere necessaria una certa preparazione del database affinché l'aggiornamento abbia successo.

Quando avvii un aggiornamento da Aurora MySQL versione 2 alla versione 3, Amazon Aurora esegue automaticamente i precontrolli per rilevare queste incompatibilità.

Questi controlli preliminari sono obbligatori. Non puoi scegliere di saltarli. I controlli preliminari offrono i seguenti vantaggi:

I precontrolli includono alcuni inclusi in MySQL e altri creati appositamente dal team di Aurora. Per informazioni sui controlli preliminari forniti da MySQL, consultare Utility di controllo aggiornamenti.

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 precontrolli rilevano un'incompatibilità, Aurora annulla automaticamente l'aggiornamento prima che l'istanza DB venga interrotta. 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 registra informazioni dettagliate su ogni incompatibilità nel file di registro. 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.

Precheck comunitari per l'aggiornamento di MySQL

Di seguito è riportato un elenco generale delle incompatibilità tra MySQL 5.7 e 8.0:

Per ulteriori informazioni sull'aggiornamento a MySQL 8.0, vedere Aggiornamento di MySQL nella documentazione di MySQL.

Precontrolli preliminari per l'aggiornamento di Aurora MySQL

Aurora MySQL ha i propri requisiti specifici per l'aggiornamento dalla versione 2 alla versione 3:

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.

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 della notifica degli eventi di Amazon RDS.

Il processo di aggiornamento è costituito da tre fasi:

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, vedi Utilizzo delle implementazioni blu/verde Amazon RDS per gli aggiornamenti del database.

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.

Eseguire qualsiasi pianificazione e test prima dell'aggiornamento, come descritto in. Pianificazione di un aggiornamento della versione principale per un cluster Aurora MySQL

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

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

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.

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 usi il AWS Management Console, scegli l'elemento con il ruolo Database globale.

Se utilizzi l'API AWS CLI o RDS, avvia il processo di aggiornamento chiamando il comando modify-global-cluster o Cluster operation. ModifyGlobal Utilizzare uno di questi anziché modify-db-cluster o ModifyDBCluster.

Per aggiornare la versione principale di un cluster di database globale Aurora MySQL utilizzando AWS CLI, usa il comando modify-global-cluster con i seguenti parametri richiesti:

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

aws rds modify-global-cluster \
          --global-cluster-identifier global_cluster_identifier \
          --engine aurora-mysql \
          --engine-version 5.7.mysql_aurora.2.10.2 \
          --allow-major-version-upgrade

aws rds modify-global-cluster ^
          --global-cluster-identifier global_cluster_identifier ^
          --engine aurora-mysql ^
          --engine-version 5.7.mysql_aurora.2.10.2 ^
          --allow-major-version-upgrade

Considerazioni a ritroso

Se sul cluster che è stato aggiornato era abilitata la funzione backtrack, non è possibile eseguire il backtrack del cluster aggiornato a un momento precedente all'aggiornamento.

Esercitazione sull'aggiornamento in loco di Aurora MySQL

I seguenti esempi di Linux mostrano come è possibile eseguire i passaggi generali della procedura di aggiornamento in loco utilizzando la AWS CLI.

Questo primo esempio crea un cluster di database Aurora che esegue una versione 2.x di Aurora MySQL. Il cluster include un'istanza database di scrittura e un'istanza database di lettura. Il comando wait db-instance-available si interrompe fino a quando l'istanza database di scrittura non è disponibile. Questo è il momento in cui il cluster è pronto per essere aggiornato.

aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
  --db-cluster-version 5.7.mysql_aurora.2.10.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
  --db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1

Le versioni di Aurora MySQL 3.x a cui è possibile aggiornare il cluster dipendono dalla versione 2.x attualmente in esecuzione sul cluster e dalla posizione in cui si trova il cluster. Regione AWS Il primo comando, con --output text, mostra soltanto la versione di destinazione disponibile. Il secondo comando mostra l'output JSON completo della risposta. Questa risposta contiene dettagli quali il valore aurora-mysql utilizzato per il parametro engine. Inoltre, indica che l'aggiornamento a 3.02.0 rappresenta un aggiornamento della versione principale.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]'
...
{
    "Engine": "aurora-mysql",
    "EngineVersion": "8.0.mysql_aurora.3.02.0",
    "Description": "Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23)",
    "AutoUpgrade": false,
    "IsMajorVersionUpgrade": true,
    "SupportedEngineModes": [
        "provisioned"
    ],
    "SupportsParallelQuery": true,
    "SupportsGlobalDatabases": true,
    "SupportsBabelfish": false
},
...

Questo esempio mostra che se si immette un numero di versione di destinazione che non è una destinazione di aggiornamento valida per il cluster, Aurora non esegue l'aggiornamento. Aurora non esegue un aggiornamento della versione principale a meno che non si includa il parametro --allow-major-version-upgrade. In questo modo, non è possibile eseguire accidentalmente un aggiornamento che potrebbe richiedere modifiche e test estesi al codice dell'applicazione.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.10.2 with requested version 5.7.mysql_aurora.2.09.2.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --apply-immediately --allow-major-version-upgrade
{
  "DBClusterIdentifier": "mynewdbcluster",
  "Status": "available",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.2"
}

Sono necessari alcuni istanti prima che lo stato del cluster e le istanze database associate vengano modificati in upgrading. I numeri di versione per il cluster e le istanze database cambiano solo al termine dell'aggiornamento. Ancora una volta, è possibile utilizzare il comando wait db-instance-available perché l'istanza database di scrittura attenda il completamento dell'aggiornamento prima di procedere.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.10.2

aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
  --query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
    "DBInstanceIdentifier": "mynewdbcluster-instance1",
    "DBInstanceStatus": "upgrading"
}

aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1

A questo punto, il numero di versione del cluster corrisponde a quello specificato per l'aggiornamento.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].[EngineVersion]' --output text

8.0.mysql_aurora.3.02.0

L'esempio precedente ha eseguito un aggiornamento immediato specificando il parametro --apply-immediately. Per consentire l'aggiornamento in un momento opportuno, quando si prevede che il cluster non sia occupato, è possibile specificare il parametro --no-apply-immediately. In questo modo l'aggiornamento viene avviato durante la successiva finestra di manutenzione del cluster. La finestra di manutenzione definisce il periodo durante il quale possono iniziare le operazioni di manutenzione. Un'operazione di lunga durata potrebbe non terminare durante la finestra di manutenzione. Pertanto, non è necessario definire una finestra di manutenzione più ampia anche se si prevede che l'aggiornamento potrebbe richiedere molto tempo.

Nell'esempio seguente viene aggiornato un cluster che esegue inizialmente Aurora MySQL versione 2.10.2. Nell’output di describe-db-engine-versions, i valori False e True rappresentano la proprietà IsMajorVersionUpgrade. Dalla versione 2.10.2, è possibile eseguire l'aggiornamento ad altre versioni 2.*. Questi aggiornamenti non sono considerati aggiornamenti di versione principali e quindi non richiedono un aggiornamento in loco. L'aggiornamento locale è disponibile solo per gli aggiornamenti alle versioni 3.* visualizzate nell'elenco.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text

5.7.mysql_aurora.2.10.3 False
5.7.mysql_aurora.2.11.0 False
5.7.mysql_aurora.2.11.1 False
8.0.mysql_aurora.3.01.1 True
8.0.mysql_aurora.3.02.0 True
8.0.mysql_aurora.3.02.2 True


aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.0 --no-apply-immediately --allow-major-version-upgrade
...

Quando un cluster viene creato senza una finestra di manutenzione specificata, Aurora seleziona un giorno casuale della settimana. In questo caso, il comando modify-db-cluster viene inviato un lunedì. Pertanto, modifichiamo la finestra di manutenzione affinché sia di martedì mattina. Tutti gli orari sono rappresentati nel fuso orario UTC. La finestra tue:10:00-tue:10:30 indica dalle 2:00 alle 2:30 ora del Pacifico. La modifica della finestra di manutenzione ha effetto immediato.

aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "sat:08:20-sat:08:50"
    ]
]

aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "tue:10:00-tue:10:30"
    ]
]

Nell'esempio seguente viene illustrato come ottenere un report degli eventi generati dall'aggiornamento. L'argomento --duration rappresenta il numero di minuti per recuperare le informazioni sull'evento. Questo argomento è necessario perché per impostazione predefinita restituisce describe-events solo gli eventi dell'ultima ora.

aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
    "Events": [
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "DB cluster created",
            "EventCategories": [
                "creation"
            ],
            "Date": "2022-11-17T01:24:11.093000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing online pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T22:57:08.450000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T22:57:59.519000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:00:22.318000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Cloning volume.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:01:45.428000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:02:25.141000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:06:23.036000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Upgrading database objects.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:06:48.208000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        },
        {
            "SourceIdentifier": "mynewdbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster major version has been upgraded",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2022-11-18T23:10:28.999000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
        }
    ]
}

Individuazione dei motivi degli errori di aggiornamento

Nel tutorial precedente, l'aggiornamento da Aurora MySQL versione 2 alla versione 3 è riuscito. Ma se l'aggiornamento fosse fallito, vorresti sapere perché.

È possibile iniziare utilizzando il describe-events AWS CLI comando per esaminare gli eventi del cluster DB. Questo esempio mostra gli eventi delle ultime 10 ore. mydbcluster

aws rds describe-events \
    --source-type db-cluster \
    --source-identifier mydbcluster \
    --duration 600

In questo caso, si è verificato un errore di precontrollo dell'aggiornamento.

{
    "Events": [
        {
            "SourceIdentifier": "mydbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster engine version upgrade started.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2024-04-11T13:23:22.846000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
        },
        {
            "SourceIdentifier": "mydbcluster",
            "SourceType": "db-cluster",
            "Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the  
             upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see 
             https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2024-04-11T13:23:24.373000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
        }
    ]
}

Per diagnosticare la causa esatta del problema, esamina i log del database per l'istanza Writer DB. Quando un aggiornamento ad Aurora MySQL versione 3 fallisce, l'istanza writer contiene un file di registro con il nome. upgrade-prechecks.log Questo esempio mostra come rilevare la presenza di quel log e quindi scaricarlo in un file locale per l'analisi.

aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
    --query '*[].[LogFileName]' --output text

error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log

aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
    --log-file-name upgrade-prechecks.log \
    --starting-token 0 \
    --output text >upgrade_prechecks.log

Il file upgrade-prechecks.log è in formato JSON. Lo scarichiamo usando l'opzione --output text per evitare la codifica dell'output JSON all'interno di un altro wrapper JSON. Per gli aggiornamenti di Aurora MySQL versione 3, questo log include sempre alcuni messaggi informativi e di avviso. Include messaggi di errore solo se l'aggiornamento non riesce. Se l'aggiornamento riesce, il file di log non viene prodotto.

Per riepilogare tutti gli errori e visualizzare gli oggetti e i campi di descrizione associati, è possibile eseguire il comando grep -A 2 '"level": "Error"' sul contenuto del file. upgrade-prechecks.log In questo modo viene visualizzata ogni riga di errore e le due righe successive. Queste contengono il nome dell'oggetto di database corrispondente e le indicazioni su come correggere il problema.

$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'

"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."

In questo esempio, è possibile eseguire il seguente comando SQL sulla tabella che causa il problema per cercare di risolvere il problema oppure è possibile ricreare la tabella senza l'indice pendente.

OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;

Quindi riprova a eseguire l'aggiornamento.

Risoluzione dei problemi relativi all'aggiornamento in loco di Aurora MySQL

Utilizza i seguenti suggerimenti per risolvere i problemi relativi agli aggiornamenti in loco di Aurora MySQL. Questi suggerimenti non si applicano a cluster di database Aurora Serverless.

SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, 
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, 
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;

Per ulteriori dettagli sulla risoluzione dei problemi che causano il fallimento dei controlli preliminari di aggiornamento, consultate i seguenti blog:

È possibile utilizzare la procedura seguente per eseguire controlli personalizzati per alcune delle condizioni della tabella precedente. In questo modo, è possibile pianificare l'aggiornamento in un momento in cui si sa che il database si trova in uno stato in cui l'aggiornamento può essere completato correttamente e con rapidità.

Pulizia post-aggiornamento per Aurora MySQL versione 3

Dopo aver completato l'aggiornamento di un cluster Aurora MySQL versione 2 ad Aurora MySQL versione 3, è possibile eseguire queste altre azioni di pulizia:

Indici spaziali

Dopo l'aggiornamento a Aurora MySQL versione 3, verificare se è necessario eliminare o ricreare oggetti e indici relativi agli indici spaziali. Prima di MySQL 8.0, Aurora poteva ottimizzare le query spaziali utilizzando indici che non contengono un identificatore delle risorse spaziali (SRID). Aurora MySQL versione 3 utilizza solo indici spaziali contenenti SRID. Durante un aggiornamento, Aurora rilascia automaticamente tutti gli indici spaziali senza SRID e stampa i messaggi di avviso nel registro del database. Se si osservano tali messaggi di avviso, creare nuovi indici spaziali con SRID dopo l'aggiornamento. Per ulteriori informazioni sulle modifiche alle funzioni spaziali e ai tipi di dati in MySQL 8.0, consultare Changes in MySQL 8.0 (Modifiche in MySQL 8.0)nel Manuale di riferimento MySQL.