# Descobrir os motivos das falhas de atualização da versão principal do Aurora MySQL
<a name="AuroraMySQL.Upgrading.failure-events"></a>

No [tutorial](AuroraMySQL.Upgrading.Tutorial.md), a atualização do Aurora MySQL versão 2 para a versão 3 foi bem-sucedida. Mas, se a atualização tivesse falhado, seria útil saber o motivo.

É possível começar usando o comando `describe-events` da AWS CLI para examinar os eventos do cluster de banco de dados. Este exemplo mostra os eventos de `mydbcluster` nas últimas dez horas.

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

Nesse caso, tivemos uma falha na pré-verificação da atualização.

```
{
    "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"
        }
    ]
}
```

Para diagnosticar a causa exata do problema, examine os logs do banco de dados para a instância de banco de dados de gravador. Quando uma atualização para o Aurora MySQL versão 3 falha, a instância de gravador contém um arquivo de log com o nome do arquivo `upgrade-prechecks.log`. Este exemplo mostra como detectar a presença desse log e, em seguida, baixá-lo para um arquivo local para exame.

```
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
```

O arquivo `upgrade-prechecks.log` está no formato JSON. Nós o baixamos usando a opção `--output text` para evitar codificar a saída JSON em outro wrapper JSON. Para atualizações do Aurora MySQL versão 3, esse log sempre inclui determinadas mensagens informativas e de aviso. Ele só inclui mensagens de erro se a atualização falhar. Se a atualização for bem-sucedida, o arquivo de log não será produzido.

Para resumir todos esses erros e exibir os campos de objeto e descrição associados, é possível executar o comando `grep -A 2 '"level": "Error"'` no conteúdo do arquivo `upgrade-prechecks.log`. Isso exibe cada linha de erro e as duas linhas depois dela. Elas contêm o nome do objeto de banco de dados correspondente e orientações sobre como corrigir o 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."
```

Neste exemplo, é possível executar o comando SQL a seguir na tabela com problemas para tentar corrigi-los ou recriar a tabela sem o índice pendente.

```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```

Tente realizar a atualização novamente.