Individuazione delle cause degli errori di aggiornamento a una versione principale di Aurora MySQL

Nel tutorial, l’aggiornamento dalla versione 2 alla versione 3 di Aurora MySQL è riuscito. Ma se l’aggiornamento non fosse riuscito, vorresti sapere perché.

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

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

In questo caso, si è verificato un errore nei controlli preliminari 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.Upgrading.Troubleshooting.html",
            "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, esaminare i log del database per l’istanza database di scrittura. Quando un aggiornamento alla versione 3 di Aurora MySQL non riesce, l’istanza di scrittura contiene un file di log denominato 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 i campi oggetto e 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 inesatto.

OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;

Provare quindi a eseguire nuovamente l’aggiornamento.