Verificações prévias de atualização da versão principal do Aurora MySQL

Elas podem reduzir a possibilidade de falhas de atualização capazes de prolongar o tempo de inatividade.

Se houver incompatibilidades, o Amazon Aurora impedirá que a atualização continue e fornecerá um log para que você saiba mais sobre elas. Você pode então resolver essas incompatibilidades usando o log para preparar o banco de dados para a atualização para a versão 3. Consulte informações detalhadas sobre como resolver incompatibilidades em Preparing Your Installation for Upgrade na documentação do MySQL e em Upgrading to MySQL 8.0? Here is what you need to know... no blog do MySQL Server.

Para ter informações sobre como atualizar para o MySQL 8.0, consulte Upgrading MySQL na documentação do MySQL.

targetVersion: a versão compatível com MySQL da atualização do Aurora MySQL.

auroraServerVersion: a versão do Aurora MySQL na qual a pré-verificação foi executada.

auroraTargetVersion: a versão do Aurora MySQL para a qual você está fazendo a atualização.

checksPerformed: contém a lista de pré-verificações realizadas.

id: o nome da pré-verificação que está sendo executada.

title: uma descrição da pré-verificação que está sendo executada.

status: isso não indica se a pré-verificação foi bem-sucedida ou falhou, mas mostra o status da consulta de pré-verificação:

description: uma descrição geral da incompatibilidade e informações de como corrigir o problema.

documentationLink: quando aplicável, um link para a documentação relevante do Aurora MySQL ou do MySQL é indicado aqui. Para ter mais informações, consulte Referência de descrições da pré-verificação do Aurora MySQL.

detectedProblems: se a pré-verificação exibir um erro, aviso ou alerta, isso mostrará os detalhes da incompatibilidade e os objetos incompatíveis, quando aplicável:

errorCount: o número de erros de incompatibilidade detectados. Eles impedem a atualização.

warningCount: o número de avisos de incompatibilidade detectados. Eles não impedem a atualização, mas resolva-os o quanto antes para evitar problemas em versões futuras.

noticeCount: o número de alertas de incompatibilidade detectados. Eles não impedem a atualização, mas resolva-os o quanto antes para evitar problemas em versões futuras.

Summary: um resumo da contagem de erros, avisos e alertas de compatibilidade da pré-verificação.

A duração da pré-verificação varia de acordo com o número de objetos do banco de dados, como tabelas, colunas, rotinas e restrições. Clusters de banco de dados com um grande número de objetos podem levar mais tempo para serem executados.

Por exemplo, removedFunctionsCheck pode levar mais tempo e usar mais recursos com base no número de objetos armazenados.

Para atualizações no local, o uso de uma classe de instância de banco de dados maior (por exemplo, db.r5.24xlarge ou db.r6g.16xlarge) pode ajudar a concluir a atualização mais rapidamente usando mais CPU. Você pode reduzir o tamanho após a atualização.

As consultas em information_schema em vários bancos de dados podem ser lentas, principalmente quando há muitos objetos e em instâncias de banco de dados menores. Nesses casos, considere usar clonagem, restauração de snapshots ou uma implantação azul/verde para atualizações.

O uso de recursos (CPU, memória) da pré-verificação pode aumentar com mais objetos, resultando em tempos de execução mais longos em instâncias de banco de dados menores. Nesses casos, considere testar o uso de clonagem, restauração de snapshots ou uma implantação azul/verde para atualizações.

Se as pré-verificações falharem devido à falta de recursos, você poderá detectar isso no log de pré-verificação usando a saída de status:

"status": "ERROR",

O cluster de banco de dados compatível com o MySQL 5.7 não deve usar recursos incompatíveis com o MySQL 8.0.

Para obter mais informações, consulte Recursos removidos no MySQL 8.0 na documentação do MySQL.

Não deve haver violações de palavra-chave ou palavra reservada. Algumas palavras-chave podem ser reservadas no MySQL 8.0 que não eram reservadas anteriormente.

Para obter mais informações, consulte Palavras-chave e palavras reservadas na documentação do MySQL.

Para suporte melhorado do Unicode, considere a conversão de objetos que usam o conjunto de caracteres utf8mb3 para que usem o conjunto de caracteres utf8mb4. O conjunto de caracteres utf8mb3 está obsoleto. Além disso, considere o uso de utf8mb4 para referências de conjuntos de caracteres em vez de utf8, pois, no momento, utf8 é um alias para o conjunto de caracteres utf8mb3.

Para obter mais informações, consulte The utf8mb3 character set (3-byte UTF-8 unicode encoding) na documentação do MySQL.

Não deve haver tabelas do InnoDB com um formato de linha não padrão.

Não deve haver atributos de tipo de tamanho ZEROFILL ou display.

Não deve haver tabela particionada que usa um mecanismo de armazenamento que não tem suporte para particionamento nativo,

Não deve haver tabelas no banco de dados do sistema mysql do MySQL 5.7 com o mesmo nome de uma tabela usada pelo dicionário de dados do MySQL 8.0.

Não deve haver tabelas que usam funções ou tipos de dados obsoletos.

Não deve haver nomes de restrição de chave externa maiores que 64 caracteres.

Não deve haver modos obsoletos do SQL definidos na configuração de variável do sistema sql_mode.

Não deve haver tabelas nem procedimentos armazenados com elementos de coluna ENUM ou SET individuais que excedam 255 caracteres.

Não deve haver partições de tabela que residam em espaços de tabela compartilhados do InnoDB.

Não deve haver referências circulares nos caminhos do arquivo de dados do espaço de tabela.

Não deve haver consultas e definições de programa armazenadas que usem qualificadores ASC ou DESC para cláusulas GROUP BY.

Não deve haver variáveis do sistema removidas, e as variáveis do sistema devem usar os novos valores padrão para o MySQL 8.0.

Não deve haver valores zero (0) de data, data e hora ou carimbo de data e hora.

Não deve haver inconsistências em esquemas resultantes da remoção ou da corrupção de arquivos.

Não deve haver nomes de tabela que contenham a string de caracteres FTS.

Não deve haver tabelas do InnoDB que pertençam a um mecanismo diferente.

Não deve haver nomes de tabelas ou esquemas inválidos para o MySQL 5.7.

Não deve haver nenhuma sintaxe SQL obsoleta, como SQL_CACHE, SQL_NO_CACHE e QUERY_CACHE, em visualizações, rotinas, gatilhos e eventos.

Não deve haver colunas FTS_DOC_ID presentes em nenhuma tabela sem o índice FTS.

Não deve haver nenhuma incompatibilidade de definição de coluna entre o dicionário de dados do InnoDB e a definição real da tabela.

Todos os nomes de bancos de dados e tabelas devem estar em minúsculas quando o parâmetro lower_case_table_names é definido como 1.

Eventos e gatilhos não devem ter um definidor vazio ou ausente ou um contexto de criação inválido.

Todos os nomes de gatilhos em um banco de dados devem ser exclusivos.

A recuperação de DDL e o DDL rápido não são compatíveis com o Aurora MySQL versão 3. Não deve haver artefatos nos bancos de dados relacionados a esses recursos.

Tabelas com o formato de linha REDUNDANT ou COMPACT não podem ter índices maiores que 767 bytes.

O tamanho do prefixo dos índices definidos nas colunas de texto tiny não pode exceder 255 bytes. Com o conjunto de caracteres utf8mb4, isso limita o tamanho do prefixo aceito a 63 caracteres.

Uma extensão maior de prefixo era permitida no MySQL 5.7 usando o parâmetro innodb_large_prefix. Esse parâmetro está obsoleto no MySQL 8.0.

Não deve haver nenhuma inconsistência de metadados do InnoDB na tabela mysql.host.

Não deve haver incompatibilidade do tipo de dados da coluna nas tabelas do sistema.

Não deve haver transações XA no estado prepared.

Os nomes das colunas nas visualizações não podem exceder 64 caracteres.

Caracteres especiais em procedimentos armazenados não podem ser inconsistentes.

As tabelas não podem ter inconsistência no caminho do arquivo de dados.