Referência de descrições da pré-verificação do Aurora MySQL

Nível de pré-verificação: erro

Problemas relatados pelo comando check table x for upgrade para o esquema mysql

Antes de iniciar a atualização para o Aurora MySQL versão 3, check table for upgrade é executado em cada tabela no esquema mysql na instância de banco de dados. O comando check table for upgrade examina as tabelas em busca de possíveis problemas que possam surgir durante uma atualização para uma versão mais recente do MySQL. Executar esse comando antes de tentar fazer a atualização pode ajudar a identificar e resolver quaisquer incompatibilidades com antecedência, facilitando o respectivo processo.

Esse comando executa várias verificações em cada tabela, como as seguintes:

Consulte mais informações em CHECK TABLE Statement na documentação do MySQL.

Exemplos de resultado:

{
  "id": "checkTableMysqlSchema",
  "title": "Issues reported by 'check table x for upgrade' command for mysql schema.",
  "status": "OK",
  "detectedProblems": []
}

A saída dessa pré-verificação depende do erro encontrado e de quando ele foi encontrado, pois check table for upgrade executa várias verificações.

Se você encontrar algum erro nessa pré-verificação, abra um caso no AWS Support para solicitar que a inconsistência de metadados seja resolvida. Ou você pode tentar fazer a atualização novamente executando um despejo lógico e, depois, restaurando para um novo cluster de banco de dados do Aurora MySQL versão 3.

Nível de pré-verificação: erro

Referências circulares a diretórios nos caminhos de arquivo de dados do espaço de tabela

Desde o MySQL 8.0.17, a cláusula CREATE TABLESPACE ... ADD DATAFILE não permite mais referências circulares a diretórios. Para evitar problemas de atualização, remova todas as referências circulares a diretórios dos caminhos de arquivo de dados do espaço de tabela antes de fazer a atualização para o Aurora MySQL versão 3.

Exemplos de resultado:

{
  "id": "circularDirectory",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "description": "Error: Following tablespaces contain circular directory references (e.g. the reference '/../') in data file paths which as of MySQL 8.0.17 are not permitted by the CREATE TABLESPACE ... ADD DATAFILE clause. An exception to the restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-innodb-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "ts2",
        "description": "circular reference in datafile path: '/home/ec2-user/dbdata/mysql_5_7_44/../ts2.ibd'",
        "dbObjectType": "Tablespace"
      }
  ]
}

Se você receber esse erro, recrie suas tabelas usando um espaço de tabela de arquivo por tabela. Use caminhos de arquivo padrão para todos os espaços e definições de tabela.

Após a recriação, a pré-verificação é concluída com êxito, permitindo que a atualização prossiga.

{
  "id": "circularDirectoryCheck",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "detectedProblems": []
},

Nível de pré-verificação: erro

Colunas que não podem ter valores padrão

Nas versões anteriores ao MySQL 8.0.13, as colunas BLOB, TEXT, GEOMETRY e JSON não podem ter valores padrão. Remova todas as cláusulas padrão dessas colunas antes de fazer a atualização para o Aurora MySQL versão 3. Consulte mais informações sobre alterações no tratamento padrão desses tipos de dados em Data Type Default Values na documentação do MySQL.

Exemplos de resultado:

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "description": "Error: The following columns are defined as either BLOB, TEXT, GEOMETRY or JSON and have a default value set. These data types cannot have default values in MySQL versions prior to 8.0.13, while starting with 8.0.13, the default value must be specified as an expression. In order to fix this issue, please use the ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT statement.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html#data-type-defaults-explicit",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test_blob_default.geo_col",
        "description": "geometry"
      }
  ]
},

A pré-verificação retorna um erro porque a coluna geo_col na tabela test.test_blob_default está usando um tipo de dados BLOB, TEXT, GEOMETRY ou JSON com um valor padrão especificado.

Observando a definição da tabela, podemos ver que a coluna geo_col é definida como geo_col geometry NOT NULL default ''.

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Remova essa cláusula padrão para permitir que a pré-verificação seja bem-sucedida.

mysql> ALTER TABLE test_blob_default modify COLUMN geo_col geometry NOT NULL;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

A pré-verificação é concluída com êxito e você pode tentar fazer a atualização novamente.

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "detectedProblems": []
},

Nível de pré-verificação: erro

Uso de palavras-chave obsoletas na definição

O MySQL 8.0 removeu o cache de consultas. Por isso, algumas sintaxes de SQL específicas de cache de consultas foram removidas. Se algum dos objetos do banco de dados contiver as palavras-chave QUERY CACHE, SQL_CACHE ou SQL_NO_CACHE, um erro de pré-verificação será exibido. Para resolver esse problema, recrie esses objetos removendo as palavras-chave mencionadas.

Exemplos de resultado:

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "description": "Error: The following DB objects contain keywords like 'QUERY CACHE', 'SQL_CACHE', 'SQL_NO_CACHE' which are not supported in major version 8.0. It is recommended to drop these DB objects or rebuild without any of the above keywords before upgrade.",
  "detectedProblems": [
      {
"level": "Error",
"dbObject": "test.no_query_cache_check",
"description": "PROCEDURE uses depreciated words in definition"
      }
  ]
}

A pré-verificação informa que o procedimento armazenado test.no_query_cache_check está usando uma das palavras-chave removidas. Observando a definição do procedimento, podemos ver que ele usa SQL_NO_CACHE.

mysql> show create procedure test.no_query_cache_check\G
*************************** 1. row ***************************
           Procedure: no_query_cache_check
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`()
BEGIN
    SELECT SQL_NO_CACHE k from sbtest1 where id > 10 and id < 20 group by k asc;
END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Remova a palavra-chave.

mysql> drop procedure test.no_query_cache_check;
Query OK, 0 rows affected (0.01 sec)

mysql> delimiter //

mysql> CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`() BEGIN     SELECT k from sbtest1 where id > 10 and id < 20 group by k asc; END//
Query OK, 0 rows affected (0.00 sec)

mysql> delimiter ;

Após a remoção da palavra-chave, a pré-verificação é concluída com êxito.

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Tabela reconhecida pelo InnoDB que pertence a um mecanismo diferente

De modo semelhante a schemaInconsistencyCheck, essa pré-verificação verifica se os metadados da tabela no MySQL são consistentes antes de prosseguir com a atualização.

Se você encontrar algum erro nessa pré-verificação, abra um caso no AWS Support para solicitar que a inconsistência de metadados seja resolvida. Ou você pode tentar fazer a atualização novamente executando um despejo lógico e, depois, restaurando para um novo cluster de banco de dados do Aurora MySQL versão 3.

Exemplos de resultado:

{
  "id": "engineMixupCheck",
  "title": "Tables recognized by InnoDB that belong to a different engine",
  "status": "OK",
  "description": "Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removes InnoDB table files manually from the disk and creates e.g. a MyISAM table with the same name.\n\nA possible way to solve this situation is to e.g. in case of MyISAM table:\n\n1. Rename the MyISAM table to a temporary name (RENAME TABLE).\n2. Create some dummy InnoDB table (its definition does not need to match), then copy (copy, not move) and rename the dummy .frm and .ibd files to the orphan name using OS file commands.\n3. The orphan table can be then dropped (DROP TABLE), as well as the dummy table.\n4. Finally the MyISAM table can be renamed back to its original name.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.general_log_backup",
        "description": "recognized by the InnoDB engine but belongs to CSV"
      }
  ]
}

Nível de pré-verificação: erro

Definições de coluna ENUM e SET contendo elementos com tamanho superior a 255 caracteres

Tabelas e procedimentos armazenados não devem ter elementos de coluna ENUM ou SET que excedam 255 caracteres ou 1.020 bytes. Antes do MySQL 8.0, o tamanho máximo combinado era de 64 K, mas o 8.0 limita elementos individuais a 255 caracteres ou 1.020 bytes (com suporte a multibyte). Se houver uma falha na pré-verificação referente a enumSetElementLengthCheck, modifique os elementos que excedam esses novos limites antes de tentar fazer a atualização novamente.

Exemplos de resultado:

{
  "id": "enumSetElementLengthCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "description": "Error: The following columns are defined as either ENUM or SET and contain at least one element longer that 255 characters. They need to be altered so that all elements fit into the 255 characters limit.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/string-type-overview.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.large_set.s",
        "description": "SET contains element longer than 255 characters"
      }
  ]
},

A pré-verificação relata um erro porque a coluna s na tabela test.large_set contém um elemento SET com mais de 255 caracteres.

Após a redução do tamanho de SET dessa coluna, a pré-verificação é concluída com êxito, permitindo que a atualização prossiga.

{
  "id": "enumSetElementLenghtCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "detectedProblems": []
},

Nível de pré-verificação: erro

Nomes de restrição de chave externa com mais de 64 caracteres

No MySQL, o tamanho dos identificadores é limitado a 64 caracteres, conforme descrito na documentação do MySQL. Tendo em vista os problemas identificados, em que as extensões das chaves externas podiam se igualar ou exceder esse valor, causando falhas de atualização, essa pré-verificação foi implementada. Se você encontrar erros com essa pré-verificação, altere ou renomeie a restrição para que ela tenha menos de 64 caracteres, antes de tentar fazer a atualização novamente.

Exemplos de resultado:

{
  "id": "foreignKeyLength",
  "title": "Foreign key constraint names longer than 64 characters",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

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

Devido a mudanças na implementação do dicionário de dados, o MySQL 8.0 não permite gatilhos com distinção entre letras maiúsculas e minúsculas em um banco de dados. Essa pré-verificação confirma que o cluster de banco de dados não tem um ou mais bancos de dados com gatilhos duplicados. Consulte mais informações em Identifier Case Sensitivity na documentação do MySQL.

Exemplos de resultado:

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "description": "Error: You have one or more database containing duplicate triggers. Mysql 8.0 does not support case sensitive triggers within a database https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html. To upgrade to MySQL 8.0, drop the triggers with case-insensitive duplicate names and recreate with distinct names.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_product"
      },
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_PRODUCT"
      }
  ]
}

A pré-verificação relata o erro de que o cluster de banco de dados tem dois gatilhos com o mesmo nome, mas com grafia diferente de maiúscula e minúscula: test.before_insert_product e test.before_insert_PRODUCT.

Antes de fazer a atualização, renomeie os gatilhos ou descarte-os e recrie-os com um novo nome.

Depois de renomear test.before_insert_PRODUCT para test.before_insert_product_2, a pré-verificação é bem-sucedida.

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

A coluna de definidor referente a mysql.event não pode ser nula nem estar em branco.

O atributo DEFINER especifica a conta do MySQL que possui uma definição de objeto armazenado, como um gatilho, um procedimento armazenado ou um evento. Esse atributo é útil principalmente em situações em que você quer controlar o contexto de segurança no qual o objeto armazenado é executado. Ao criar um objeto armazenado, se não for especificado um DEFINER, o padrão será o usuário que criou o objeto.

Ao fazer atualização para o MySQL 8.0, você não pode ter nenhum objeto armazenado que tenha um definidor null ou em branco no dicionário de dados do MySQL. Se você tiver esses objetos armazenados, será gerado um erro de pré-verificação. Você deve corrigi-lo antes de prosseguir com a atualização.

Exemplo de erro:

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "description": "Error: Set definer column in mysql.event to a valid non-null definer.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.get_version",
        "description": "Set definer for event get_version in Schema test"
      }
  ]
}

A pré-verificação exibe um erro para o evento test.get_version porque ele tem um definidor null.

Para resolver isso, você pode verificar a definição do evento. Como você pode ver, o definidor é null ou está em branco.

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+---------+
| db   | name        | definer |
+------+-------------+---------+
| test | get_version |         |
+------+-------------+---------+
1 row in set (0.00 sec)

Descarte ou recrie o evento com um definidor válido.

mysql> drop event test.get_version;
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;
mysql> delimiter $$
mysql> CREATE EVENT get_version
    ->     ON SCHEDULE
    ->       EVERY 1 DAY
    ->     DO
    ->      ///DO SOMETHING //
    -> $$
Query OK, 0 rows affected (0.01 sec)

mysql> DELIMITER ;

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+------------+
| db   | name        | definer    |
+------+-------------+------------+
| test | get_version | reinvent@% |
+------+-------------+------------+
1 row in set (0.00 sec)

Agora a pré-verificação é concluída com êxito.

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "detectedProblems": []},

Nível de pré-verificação: erro

Incompatibilidade de definição de coluna entre o dicionário de dados do InnoDB e a definição real da tabela

De modo semelhante a schemaInconsistencyCheck, essa pré-verificação verifica se os metadados da tabela no MySQL são consistentes antes de prosseguir com a atualização. Nesse caso, a pré-verificação confere se as definições de coluna são correspondentes entre o dicionário de dados do InnoDB e a definição de tabela do MySQL. Se for detectada uma incompatibilidade, a atualização não prosseguirá.

Se você encontrar algum erro nessa pré-verificação, abra um caso no AWS Support para solicitar que a inconsistência de metadados seja resolvida. Ou você pode tentar fazer a atualização novamente executando um despejo lógico e, depois, restaurando para um novo cluster de banco de dados do Aurora MySQL versão 3.

Exemplos de resultado:

{
  "id": "getMismatchedMetadata",
  "title": "Column definition mismatch between InnoDB Data Dictionary and actual table definition.",
  "status": "OK",
  "description": "Error: Your database has mismatched metadata. The upgrade to mysql 8.0 will not succeed until this is fixed.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.mismatchTable",
        "description": "Table `test/mismatchTable` column names mismatch with InnoDb dictionary column names: iD <> id"
      }
  ]
}

A pré-verificação relata uma incompatibilidade nos metadados da coluna id na tabela test.mismatchTable. Especificamente, os metadados do MySQL têm o nome de coluna iD, enquanto o InnoDB tem o nome id.

Nível de pré-verificação: erro

A coluna de definidor referente a information_schema.triggers não pode ser null nem estar em branco.

A pré-verificação confere se o banco de dados não tem gatilhos definidos com definidores null ou em branco. Consulte mais informações sobre os requisitos de definidores para objetos armazenados em getEventsWithNullDefiner.

Exemplos de resultado:

{
  "id": "getTriggersWithNullDefiner",
  "title": "The definer column for information_schema.triggers cannot be null or blank.",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.example_trigger",
        "description": "Set definer for trigger example_trigger in Schema test"
      }
  ]
}

A pré-verificação exibe um erro porque o gatilho example_trigger no esquema test tem um definidor null. Para corrigir esse problema, ajuste o definidor recriando o gatilho com um usuário válido ou descarte o gatilho. Consulte mais informações no exemplo em getEventsWithNullDefiner.

Nível de pré-verificação: erro

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

Antes do MySQL 8.0, os nomes de banco de dados, os nomes de tabela e outros objetos correspondiam a arquivos no diretório de dados, como metadados baseados em arquivos (.frm). A variável de sistema lower_case_table_names permite que os usuários controlem como o servidor lida com a distinção entre letras maiúsculas e minúsculas do identificador para objetos de banco de dados e o armazenamento desses objetos de metadados. Esse parâmetro podia ser alterado em um servidor já inicializado após uma reinicialização.

No entanto, no MySQL 8.0, embora esse parâmetro ainda controle como o servidor lida com a distinção entre letras maiúsculas e minúsculas do identificador, ele não pode ser alterado após a inicialização do dicionário de dados. Ao fazer a atualização ou criar um banco de dados do MySQL 8.0, o valor definido como lower_case_table_names na primeira vez em que o dicionário de dados é iniciado no MySQL é usado durante o ciclo de vida desse banco de dados. Essa restrição foi implementada como parte da implementação do Atomic Data Dictionary, em que objetos de banco de dados são migrados de metadados baseados em arquivos para tabelas internas do InnoDB no esquema mysql.

Consulte mais informações em Data Dictionary Changes na documentação do MySQL.

Para evitar problemas durante a atualização de metadados baseados em arquivo para o novo Atomic Data Dictionary, essa pré-verificação confirma se, quando lower_case_table_names = 1, todas as tabelas são armazenadas em disco em letras minúsculas. Se não forem, um erro de pré-verificação será exibido e você deverá corrigir os metadados antes de prosseguir com a atualização.

Exemplos de resultado:

{
  "id": "getValueOfVariablelower_case_table_names",
  "title": "MySQL pre-checks that all database or table names are lowercase when the lower_case_table_names parameter is set to 1.",
  "status": "OK",
  "description": "Error: You have one or more databases or tables with uppercase letters in the names, but the lower_case_table_names parameter is set to 1. To upgrade to MySQL 8.0, either change all database or table names to lowercase, or set the parameter to 0.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.TEST",
        "description": "Table test.TEST contains one or more capital letters in name while lower_case_table_names = 1"
      }
  ]
}

Um erro é exibido porque a tabela test.TEST contém letras maiúsculas, mas lower_case_table_names está definido como 1.

Para resolver esse problema, você pode renomear a tabela com letras minúsculas ou modificar o parâmetro lower_case_table_names no cluster de banco de dados antes de iniciar a atualização.

Nível de pré-verificação: erro

Uso da sintaxe GROUP BY ASC/DESC removida

Desde o MySQL 8.0.13, a sintaxe obsoleta ASC ou DESC para cláusulas GROUP BY foi removida. As consultas que dependem da classificação GROUP BY agora podem produzir resultados diferentes. Para ter uma ordem de classificação específica, use uma cláusula ORDER BY. Se algum objeto no banco de dados estiver usando essa sintaxe, você deverá recriá-lo por meio de uma cláusula ORDER BY antes de tentar fazer a atualização novamente. Consulte mais informações em SQL Changes na documentação do MySQL.

Exemplos de resultado:

{
  "id": "groupbyAscSyntaxCheck",
  "title": "Usage of removed GROUP BY ASC/DESC syntax",
  "status": "OK",
  "description": "Error: The following DB objects use removed GROUP BY ASC/DESC syntax. They need to be altered so that ASC/DESC keyword is removed from GROUP BY clause and placed in appropriate ORDER BY clause.",
  "documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-sql-syntax",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.groupbyasc",
        "description": "PROCEDURE uses removed GROUP BY ASC syntax",
        "dbObjectType": "Routine"
      }
  ]
}

Nível de pré-verificação: erro

Verifique a sintaxe obsoleta .<table> usada nas rotinas.

No MySQL 8.0, as rotinas não podem mais conter a sintaxe obsoleta do identificador (\".<table>\"). Se alguma rotina ou gatilho armazenado tiver esses identificadores, a atualização falhará. Por exemplo, a seguinte referência a .dot_table não é mais permitida:

mysql> show create procedure incorrect_procedure\G
*************************** 1. row ***************************
           Procedure: incorrect_procedure
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `incorrect_procedure`()
BEGIN delete FROM .dot_table; select * from .dot_table where 1=1; END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Depois que você recria as rotinas e os gatilhos para usar o escape e a sintaxe correta do identificador, a pré-verificação é concluída com êxito e a atualização pode prosseguir. Consulte mais informações sobre identificadores em Schema Object Names na documentação do MySQL.

Exemplos de resultado:

{
  "id": "mysqlEmptyDotTableSyntaxCheck",
  "title": "Check for deprecated '.<table>' syntax used in routines.",
  "status": "OK",
  "description": "Error: The following routines contain identifiers in deprecated identifier syntax (\".<table>\"), and should be corrected before upgrade:\n",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.incorrect_procedure",
        "description": " routine body contains deprecated identifiers."
      }
  ]
}

A pré-verificação exibe um erro referente à rotina incorrect_procedure no banco de dados test porque ela contém uma sintaxe obsoleta.

Depois que você corrige a rotina, a pré-verificação é bem-sucedida e você pode tentar fazer a atualização novamente.

Nível de pré-verificação: erro

Verifique se há índices que são muito grandes para funcionar em versões do MySQL posteriores à 5.7

Com relação a formatos de linha compactos ou redundantes, não deveria ser possível criar um índice com um prefixo com mais de 767 bytes. No entanto, antes do MySQL versão 5.7.35, isso era possível. Consulte mais informações em MySQL 5.7.35 Release Notes.

Todos os índices afetados por esse erro ficarão inacessíveis após a atualização para o MySQL 8.0. Essa pré-verificação identifica índices incorretos que precisam ser recriados antes que a atualização possa prosseguir.

 {
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "description": "Error: The following indexes ware made too large for their format in an older version of MySQL (older than 5.7.34). Normally those indexes within tables with compact or redundant row formats shouldn't be larger than 767 bytes. To fix this problem those indexes should be dropped before upgrading or those tables will be inaccessible.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_large_idx",
        "description": "IDX_2"
      }
  ]
}

A pré-verificação exibe um erro porque a tabela test.table_with_large_idx contém um índice em uma tabela que usa um formato de linha compacto ou redundante com mais de 767 bytes. Essas tabelas ficariam inacessíveis depois da atualização para o MySQL 8.0. Antes de prosseguir com a atualização, execute uma destas ações:

Aqui, nós recriamos a tabela para resolver a falha de pré-verificação. Antes de recriar a tabela, verifique se o innodb_file_format está definido como Barracuda e o innodb_default_row_format está definido como dynamic. Esses são os padrões no MySQL 5.7. Consulte mais informações em InnoDB Row Formats e em InnoDB File-Format Management na documentação do MySQL.

mysql > select @@innodb_file_format,@@innodb_default_row_format;
+----------------------+-----------------------------+
| @@innodb_file_format | @@innodb_default_row_format |
+----------------------+-----------------------------+
| Barracuda            | dynamic                     |
+----------------------+-----------------------------+
1 row in set (0.00 sec)

mysql> optimize table table_with_large_idx;
+---------------------------+----------+----------+-------------------------------------------------------------------+
| Table                     | Op       | Msg_type | Msg_text                                                          |
+---------------------------+----------+----------+-------------------------------------------------------------------+
| test.table_with_large_idx | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.table_with_large_idx | optimize | status   | OK                                                                |
+---------------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.02 sec)

# Verify FILE_FORMAT and ROW_FORMAT
mysql>  select * from information_schema.innodb_sys_tables where name like 'test/table_with_large_idx';
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
| TABLE_ID | NAME                      | FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE | SPACE_TYPE |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
|       43 | test/table_with_large_idx |   33 |      4 |    26 | Barracuda   | Dynamic    |             0 | Single     |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
1 row in set (0.00 sec)

Após a recriação da tabela, a pré-verificação é concluída com êxito e a atualização pode prosseguir.

{
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "detectedProblems": []
},

Nível de pré-verificação: erro

Verifique se há nomes inválidos de tabelas e esquemas usados no MySQL 5.7

Ao migrar para o novo dicionário de dados no MySQL 8.0, a instância de banco de dados não pode conter esquemas ou tabelas com o prefixo #mysql50#. Se algum desses objetos existir, a atualização falhará. Para resolver esse problema, execute mysqlcheck nos esquemas e tabelas exibidos.

Exemplos de resultado:

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "description": "The following tables and/or schemas have invalid names. In order to fix them use the mysqlcheck utility as follows:\n\n  $ mysqlcheck --check-upgrade --all-databases\n  $ mysqlcheck --fix-db-names --fix-table-names --all-databases\n\nOR via mysql client, for eg:\n\n  ALTER DATABASE `#mysql50#lost+found` UPGRADE DATA DIRECTORY NAME;",
  "documentationLink": "https://dev.mysql.com/doc/refman/5.7/en/identifier-mapping.html https://dev.mysql.com/doc/refman/5.7/en/alter-database.html https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "#mysql50#fix_db_names",
        "description": "Schema name"
      }
  ]
}

A pré-verificação informa que o esquema #mysql50#fix_db_names tem um nome inválido.

Após a correção do nome do esquema, a pré-verificação é concluída com êxito, permitindo que a atualização prossiga.

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "detectedProblems": []
},

Nível de pré-verificação: erro

Verifique se há rotinas órfãs na versão 5.7

Ao migrar para o novo dicionário de dados no MySQL 8.0, se houver algum procedimento armazenado no banco de dados em que o esquema não exista mais, a atualização falhará. Essa pré-verificação confere se todos os esquemas referidos nos procedimentos armazenados na instância de banco de dados ainda existem. Para permitir que a atualização prossiga, descarte esses procedimentos armazenados.

Exemplos de resultado:

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "description": "Error: The following routines have been orphaned. Schemas that they are referencing no longer exists.\nThey have to be cleaned up or the upgrade will fail.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "dropped_db.get_version",
        "description": "is orphaned"
      }
  ]
},

A pré-verificação informa que o procedimento armazenado get_version no banco de dados dropped_db é órfão.

Para limpar esse procedimento, você pode recriar o esquema ausente.

mysql> create database dropped_db;
Query OK, 1 row affected (0.01 sec)

Depois que o esquema for recriado, você poderá descartar o procedimento para permitir que a atualização prossiga.

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "detectedProblems": []
},

Nível de pré-verificação: erro

Nomes de tabela no esquema mysql conflitantes com novas tabelas no MySQL 8.0

O novo Atomic Data Dictionary, introduzido no MySQL 8.0, armazena todos os metadados em um conjunto de tabelas internas do InnoDB no esquema mysql. Durante a atualização, as novas tabelas do dicionário de dados interno são criadas no esquema mysql. Para evitar conflitos de nomenclatura, que resultariam em falhas de atualização, a pré-verificação examina todos os nomes de tabela no esquema mysql para garantir que nenhum dos novos nomes já esteja em uso. Se estiverem, um erro será exibido, e a atualização não poderá prosseguir.

Exemplos de resultado:

{
  "id": "mysqlSchema",
  "title": "Table names in the mysql schema conflicting with new tables in the latest MySQL.",
  "status": "OK",
  "description": "Error: The following tables in mysql schema have names that will conflict with the ones introduced in the latest version. They must be renamed or removed before upgrading (use RENAME TABLE command). This may also entail changes to applications that use the affected tables.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrade-before-you-begin.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.tablespaces",
        "description": "Table name used in mysql schema.",
        "dbObjectType": "Table"
      }
  ]
}

Um erro é exibido porque há uma tabela chamada tablespaces no esquema mysql. Esse é um dos novos nomes de tabela do dicionário de dados interno no MySQL 8.0. Você deve renomear ou remover essas tabelas antes da atualização usando o comando RENAME TABLE.

Nível de pré-verificação: erro

Tabelas particionadas usando mecanismos com particionamento não nativo

De acordo com a documentação do MySQL 8.0, no momento, dois mecanismos de armazenamento fornecem suporte nativo ao particionamento: InnoDB e NDB. Dentre eles, somente o InnoDB é compatível com o Aurora MySQL versão 3 compatível com o MySQL 8.0. Qualquer tentativa de criar tabelas particionadas no MySQL 8.0 usando qualquer outro mecanismo de armazenamento apresenta falha. Essa pré-verificação procura tabelas no cluster de banco de dados que estão usando particionamento não nativo. Se encontrar algum resultado, você deverá remover o particionamento ou realizar a conversão do mecanismo de armazenamento para o InnoDB.

Exemplos de resultado:

{
  "id": "nonNativePartitioning",
  "title": "Partitioned tables using engines with non native partitioning",
  "status": "OK",
  "description": "Error: In the latest MySQL storage engine is responsible for providing its own partitioning handler, and the MySQL server no longer provides generic partitioning support. InnoDB and NDB are the only storage engines that provide a native partitioning handler that is supported in the latest MySQL. A partitioned table using any other storage engine must be altered—either to convert it to InnoDB or NDB, or to remove its partitioning—before upgrading the server, else it cannot be used afterwards.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-configuration-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partMyisamTable",
         "description": "MyISAM engine does not support native partitioning",
         "dbObjectType": "Table"
      }
  ]
}

Aqui, uma tabela MyISAM está usando particionamento, o que requer uma ação para que a atualização possa prosseguir.

Nível de pré-verificação: erro

Uso do tipo temporal antigo

“Temporais antigos” referem-se às colunas do tipo temporal (como TIMESTAMP eDATETIME) criadas no MySQL versões 5.5 e anteriores. No MySQL 8.0, a compatibilidade com esses tipos de dados temporais antigos foi removida, o que significa que as atualizações no local do MySQL 5.7 para 8.0 não serão possíveis se o banco de dados tiver esses tipos temporais antigos. Para corrigir isso, você deve recriar todas as tabelas que contenham esses tipos de dados temporais antigos antes de prosseguir com a atualização.

Consulte mais informações sobre a descontinuação de tipos de dados temporais antigos no MySQL 5.7 neste blog. Consulte mais informações sobre a remoção de tipos de dados temporais antigos no MySQL 8.0 neste blog.

Exemplos de resultado:

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "description": "Error: Following table columns use a deprecated and no longer supported temporal disk storage format. They must be converted to the new format before upgrading. It can by done by rebuilding the table using 'ALTER TABLE <table_name> FORCE' command",
  "documentationLink": "https://dev.mysql.com/blog-archive/mysql-8-0-removing-support-for-old-temporal-datatypes/",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.55_temporal_table.timestamp_column",
        "description": "timestamp /* 5.5 binary format */",
        "dbObjectType": "Column"
      }
  ]
},

Um erro é relatado para a coluna timestamp_column na tabela test.55_temporal_table, porque ela usa um formato de armazenamento em disco temporal antigo que não é mais compatível.

Para resolver esse problema e permitir que a atualização prossiga, recrie a tabela para converter o formato de armazenamento em disco temporal antigo no novo apresentado no MySQL 5.6. Antes de fazer isso, consulte mais informações e pré-requisitos em Converting Between 3-Byte And 4-Byte Unicode Character Sets na documentação do MySQL.

A execução do comando a seguir para recriar as tabelas mencionadas nessa pré-verificação converte os tipos temporais antigos no formato mais novo com precisão de fração de segundos.

ALTER TABLE ... ENGINE=InnoDB;

Consulte mais informações sobre como recriar tabelas em ALTER TABLE Statement na documentação do MySQL.

Depois que você recria a tabela em questão e reinicia a atualização, a verificação de compatibilidade é concluída com êxito, permitindo que a atualização prossiga.

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Uso de tabelas particionadas em espaços de tabela compartilhados

Desde o MySQL 8.0.13, não é mais possível colocar partições de tabela em espaços de tabela compartilhados. Antes da atualização, mova essas tabelas de espaços de tabela compartilhados para espaços de tabela de arquivo por tabela.

Exemplos de resultado:

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "description": "Error: The following tables have partitions in shared tablespaces. They need to be moved to file-per-table tablespace before upgrading. You can do this by running query like 'ALTER TABLE table_name REORGANIZE PARTITION X INTO (PARTITION X VALUES LESS THAN (30) TABLESPACE=innodb_file_per_table);'",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partInnoDBTable",
        "description": "Partition p1 is in shared tablespace innodb",
        "dbObjectType": "Table"
      }
  ]
}

A pré-verificação falha porque a partição p1 da tabela test.partInnoDBTable está no espaço de tabela do sistema.

Para resolver esse problema, recrie a tabela test.partInnodbTable, colocando a partição incorreta p1 em um espaço de tabela de arquivo por tabela.

mysql > ALTER TABLE partInnodbTable REORGANIZE PARTITION p1
    ->   INTO (PARTITION p1 VALUES LESS THAN ('2014-01-01') TABLESPACE=innodb_file_per_table);
Query OK, 0 rows affected, 1 warning (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

Depois disso, a pré-verificação é concluída com êxito.

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Uso de funções que foram removidas da versão mais recente do MySQL

No MySQL 8.0, várias funções integradas foram removidas. Essa pré-verificação examina o banco de dados em busca de objetos que possam usar essas funções. Se algo for encontrado, será exibido um erro. Você deve resolver os problemas antes de tentar fazer a atualização novamente.

As funções removidas são em sua maioria funções espaciais, que foram substituídas por funções ST_* equivalentes. Nesses casos, você modifica os objetos do banco de dados para usar a nova nomenclatura do procedimento. Para obter mais informações, consulte Recursos removidos no MySQL 8.0 na documentação do MySQL.

Exemplos de resultado:

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "description": "Error: The following DB objects use functions that were removed in the latest MySQL version. Please make sure to update them to use supported alternatives before upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.GetLocationsInPolygon",
        "description": "PROCEDURE uses removed function POLYGONFROMTEXT (consider using ST_POLYGONFROMTEXT instead)",
        "dbObjectType": "Routine"
      },
      {
        "level": "Error",
        "dbObject": "test.InsertLocation",
        "description": "PROCEDURE uses removed function POINTFROMTEXT (consider using ST_POINTFROMTEXT instead)",
        "dbObjectType": "Routine"
      }
  ]
},

A pré-verificação informa que o procedimento armazenado test.GetLocationsInPolygon está usando duas funções removidas: POLYGONFROMTEXT e POINTFROMTEXT. Ela também sugere que você use como substituição ST_POLYGONFROMTEXT e ST_POINTFROMTEXT novos. Depois que você recria o procedimento usando as sugestões, a pré-verificação é concluída com êxito.

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "detectedProblems": []
},

Nível de pré-verificação: erro

Verificação de sintaxe do MySQL para objetos de rotina

O MySQL 8.0 introduziu palavras-chave reservadas que não eram reservadas anteriormente. A pré-verificação de atualização avalia o uso de palavras-chave reservadas nos nomes de objeto de banco de dados e em suas definições e corpo. Se for detectado que estão sendo usadas palavras-chave reservadas em objetos de banco de dados, como procedimentos armazenados, funções, eventos e gatilhos, a atualização falhará e um erro será publicado no arquivo upgrade-prechecks.log. Para resolver o problema, você deve atualizar essas definições de objeto e colocar essas referências entre aspas simples (‘’) antes da atualização. Consulte mais informações sobre o escape de palavras reservadas no MySQL em String Literals na documentação do MySQL.

Ou é possível alterar o nome para um nome diferente, o que pode exigir alterações na aplicação.

Exemplos de resultado:

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "description": "The following objects did not pass a syntax check with the latest MySQL grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
      {
         "level": "Error",
         "dbObject": "test.select_res_word",
         "description": "at line 2,18: unexpected token 'except'",
         "dbObjectType": "Routine"
      }
  ]
}

Para corrigir esse problema, confira a definição da rotina.

SHOW CREATE PROCEDURE test.select_res_word\G

*************************** 1. row ***************************
           Procedure: select_res_word
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
    Create Procedure: CREATE PROCEDURE 'select_res_word'()
BEGIN
    SELECT * FROM except;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

O procedimento usa uma tabela chamada except, que é uma nova palavra-chave no MySQL 8.0. Recrie o procedimento fazendo o escape do literal da string.

> drop procedure if exists select_res_word;
Query OK, 0 rows affected (0.00 sec)

> DELIMITER $$
 > CREATE PROCEDURE select_res_word()
    -> BEGIN
    ->     SELECT * FROM 'except';
    -> END$$
Query OK, 0 rows affected (0.00 sec)

 > DELIMITER ;

A pré-verificação agora é concluída com êxito.

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Inconsistências em esquemas resultantes da remoção ou corrupção de arquivos

Como descrito anteriormente, o MySQL 8.0 introduziu o Atomic Data Dictionary, que armazena todos os metadados em um conjunto de tabelas internas do InnoDB no esquema mysql. Essa nova arquitetura oferece uma forma transacional compatível com ACID de gerenciar metadados de banco de dados, resolvendo o problema de “DDL atômica” com a antiga abordagem baseada em arquivos. Antes do MySQL 8.0, era possível que objetos de esquema ficassem órfãos se uma operação de DDL fosse interrompida inesperadamente. A migração de metadados baseados em arquivos para as novas tabelas do Atomic Data Dictionary durante a atualização garante que não existam esses objetos de esquema órfãos na instância de banco de dados. Se algum objeto órfão for encontrado, a atualização falhará.

Para ajudar a detectar esses objetos órfãos antes de iniciar a atualização, a schemaInconsistencyCheck pré-verificação é executada para garantir que todos os objetos de metadados do dicionário de dados estejam sincronizados. Se algum objeto de metadados órfão for detectado, a atualização não prosseguirá. Para continuar com a a atualização, limpe esses objetos de metadados órfãos.

Se você encontrar algum erro nessa pré-verificação, abra um caso no AWS Support para solicitar que a inconsistência de metadados seja resolvida. Ou você pode tentar fazer a atualização novamente executando um despejo lógico e, depois, restaurando para um novo cluster de banco de dados do Aurora MySQL versão 3.

Exemplos de resultado:

{
  "id": "schemaInconsistencyCheck",
  "title": "Schema inconsistencies resulting from file removal or corruption",
  "status": "OK",
  "description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.schemaInconsistencyCheck_failure",
        "description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
      }
  ]
}

A pré-verificação informa que a tabela test.schemaInconsistencyCheck_failure tem metadados inconsistentes. Nesse caso, a tabela existe nos metadados do mecanismo de armazenamento do InnoDB (information_schema.INNODB_SYS_TABLES), mas não nos metadados do MySQL (information_schema.TABLES).

Nível de pré-verificação: erro

Verifique se há artefatos relacionados ao recurso de recuperação de DDL do Aurora

Como parte da implementação de recuperação da linguagem de definição de dados (DDL) no Aurora MySQL, os metadados nas instruções de DDL em trânsito são mantidos nas tabelas ddl_log_md_table e ddl_log_table no esquema mysql. A implementação da recuperação de DDL do Aurora não é compatível com a versão 3 em diante, porque a funcionalidade faz parte da nova implementação do Atomic Data Dictionary no MySQL 8.0. Se você tiver alguma instrução de DDL em execução durante as verificações de compatibilidade, essa pré-verificação poderá falhar. Recomendamos tentar fazer a atualização quando nenhuma instrução de DDL estiver em execução.

Se essa pré-verificação falhar sem que nenhuma instrução de DDL esteja em execução, abra um caso no AWS Support para solicitar que a inconsistência de metadados seja resolvida. Ou você pode tentar fazer a atualização novamente executando um despejo lógico e, depois, restaurando para um novo cluster de banco de dados do Aurora MySQL versão 3.

Se alguma instrução DDL estiver em execução, a saída da pré-verificação imprimirá a seguinte mensagem:

“There are DDL statements in process. Please allow DDL statements to finish before upgrading.”

Exemplos de resultado:

{
  "id": "auroraCheckDDLRecovery",
  "title": "Check for artifacts related to Aurora DDL recovery feature",
  "status": "OK",
  "description": "Aurora implementation of DDL recovery is not supported from 3.x onwards. This check verifies that the database do not have artifacts realted to the feature",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_md_table",
        "description": "Table mysql.ddl_log_md_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_table",
        "description": "Table mysql.ddl_log_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "information_schema.processlist",
        "description": "There are DDL statements in process. Please allow DDL statements to finish before upgrading."
      }
  ]
}

A pré-verificação exibiu um erro devido à execução simultânea de um DDL em trânsito com as verificações de compatibilidade. Recomendamos que você tente fazer a atualização novamente sem DDLs em execução.

Nível de pré-verificação: erro

Verifique a existência da tabela mysql.rds_upgrade_prechecks

Essa é uma pré-verificação somente interna realizada pelo serviço RDS. Os erros serão gerenciados automaticamente na atualização e podem ser ignorados com segurança.

Se você encontrar algum erro nessa pré-verificação, abra um caso no AWS Support para solicitar que a inconsistência de metadados seja resolvida. Ou você pode tentar fazer a atualização novamente executando um despejo lógico e, depois, restaurando para um novo cluster de banco de dados do Aurora MySQL versão 3.

{
  "id": "auroraCheckRdsUpgradePrechecksTable",
  "title": "Check existence of mysql.rds_upgrade_prechecks table",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Verifique se há artefatos relacionados ao recurso de DDL rápida do Aurora

A otimização da DDL rápida foi introduzida no modo de laboratório no Aurora MySQL versão 2 para melhorar a eficiência de algumas operações de DDL. No Aurora MySQL versão 3, o modo de laboratório foi removido e a implementação da DDL rápida foi substituída pelo recurso do MySQL 8.0 chamado DDL instantânea.

Antes de fazer a atualização para o Aurora MySQL versão 3, todas as tabelas que usam a DDL rápida no modo de laboratório precisarão ser recriadas executando o comando OPTIMIZE TABLE ou ALTER TABLE ... ENGINE=InnoDB para garantir a compatibilidade com o Aurora MySQL versão 3.

Essa pré-verificação exibe uma lista dessas tabelas. Depois que você recriar as tabelas exibidas, você poderá tentar fazer a atualização novamente.

Exemplos de resultado:

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "description": "Aurora fast DDL is not supported from 3.x onwards. This check verifies that the database does not have artifacts related to the feature",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html#AuroraMySQL.Managing.FastDDL-v2",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test",
        "description": "Your table has pending Aurora fast DDL operations. Run 'OPTIMIZE TABLE <table name>' for the table to apply all the pending DDL updates. Then try the upgrade again."
      }
  ]
}

A pré-verificação informa que a tabela test.test tem operações de DDL rápida pendentes.

Para permitir que a atualização prossiga, você pode recriar a tabela e tentar fazer upload novamente.

mysql> optimize table test.test;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table     | Op       | Msg_type | Msg_text                                                          |
+-----------+----------+----------+-------------------------------------------------------------------+
| test.test | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.test | optimize | status   | OK                                                                |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)

Depois que você recria a tabela, a pré-verificação é bem-sucedida.

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Tabelas com referência de índice FULLTEXT pendente

Antes do MySQL 5.6.26, era possível que, após a eliminação de um índice de pesquisa de texto completo, as colunas ocultas FTS_DOC_ID e FTS_DOC_ID_INDEX ficassem órfãs. Consulte mais informações em Bug #76012.

Se você tiver alguma tabela criada em versões anteriores do MySQL em que isso tenha ocorrido, as atualizações para o Aurora MySQL versão 3 poderão falhar. Essa pré-verificação confere se esses índices órfãos ou “pendentes” de texto completo não existem no cluster de banco de dados antes da atualização para o MySQL 8.0. Se essa pré-verificação falhar, recrie todas as tabelas que contenham esses índices de texto completo pendentes.

Exemplos de resultado:

{
  "id": "auroraGetDanglingFulltextIndex",
  "title": "Tables with dangling FULLTEXT index reference",
  "status": "OK",
  "description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_fts_index",
        "description": "Table `test.table_with_fts_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
      }
  ]
},

A pré-verificação relata um erro na tabela test.table_with_fts_index porque ela contém um índice de texto completo pendente. Para permitir que a atualização prossiga, recrie a tabela para limpar as tabelas auxiliares de índice de texto completo. Use OPTIMIZE TABLE test.table_with_fts_index ou ALTER TABLE test.table_with_fts_index, ENGINE=INNODB.

Depois que você recria a tabela, a pré-verificação é concluída com êxito.

{
  "id": "auroraGetDanglingFulltextIndex",
  "title": "Tables with dangling FULLTEXT index reference",
  "status": "OK",
  "detectedProblems": []
},

Nível de pré-verificação: erro

Verifique a inconsistência relacionada ao caminho do arquivo ibd

Essa pré-verificação se aplica apenas ao Aurora MySQL versão 3.03.0 e anterior. Se você encontrar um erro com essa pré-verificação, faça a atualização para o Aurora MySQL versão 3.04 ou posterior.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForDatafilePathInconsistency",
  "title": "Check for inconsistency related to ibd file path.",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Verifique o índice de texto completo com o ID do espaço como zero

No MySQL, quando você adiciona um índice de texto completo a uma tabela do InnoDB, vários espaços de tabela de índice auxiliares são criados. Devido a um erro nas versões anteriores do MySQL, que foi corrigido na versão 5.6.20, era possível que essas tabelas de índice auxiliares fossem criadas no espaço de tabela do sistema, em vez de em seu próprio espaço de tabela do InnoDB.

Se existirem espaços de tabela auxiliares desse tipo, a atualização falhará. Recrie os índices de texto completo mencionados no erro de pré-verificação e tente fazer a atualização novamente.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForFtsSpaceIdZero",
  "title": "Check for fulltext index with space id as zero",
  "status": "OK",
  "description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.fts_space_zero_check",
        "description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
      }
  ]
},

A pré-verificação relata um erro na tabela test.fts_space_zero_check, pois ela tem tabelas auxiliares de pesquisa de texto completo (FTS) no espaço de tabela do sistema.

Depois que eliminar e recriar os índices de FTS associados a essa tabela, a pré-verificação será bem-sucedida.

{
 "id": "auroraUpgradeCheckForFtsSpaceIdZero",
 "title": "Check for fulltext index with space id as zero",
 "status": "OK",
 "detectedProblems": []
}

Nível de pré-verificação: erro

Verifique se há transações XA no estado preparado

Ao executar o processo de atualização da versão principal, é essencial que a instância de banco de dados do Aurora MySQL versão 2 passe por um desligamento limpo. Isso garante que todas as transações sejam confirmadas ou revertidas e que o InnoDB tenha eliminado todos os registros de logs undo. Como a reversão de transações é necessária, se o banco de dados tiver alguma transação XA em um estado preparado, ele poderá impedir que o desligamento limpo continue. Por esse motivo, se alguma transação XA preparada for detectada, a atualização não poderá continuar enquanto você não tomar medidas para confirmá-la ou revertê-la.

Consulte mais informações sobre como encontrar transações de XA em um estado preparado usando XA RECOVER em XA Transaction SQL Statements na documentação do MySQL. Consulte mais informações sobre estados de transações de XA em XA Transaction States na documentação do MySQL.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForIncompleteXATransactions",
  "title": "Pre-checks for XA Transactions in prepared state.",
  "status": "OK",
  "description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions."
      }
  ]
}

Essa pré-verificação informa um erro porque há transações em um estado preparado que devem ser confirmadas ou revertidas.

Depois de fazer login no banco de dados, você pode verificar mais informações na tabela information_schema.innodb_trx e na saída XA RECOVER.

mysql> select trx_started,
    trx_mysql_thread_id,
    trx_id,trx_state,
    trx_operation_state,
    trx_rows_modified,
    trx_rows_locked 
from 
    information_schema.innodb_trx;
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| trx_started         | trx_mysql_thread_id | trx_id  | trx_state | trx_operation_state | trx_rows_modified | trx_rows_locked |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| 2024-08-12 01:09:39 |                   0 | 2849470 | RUNNING   | NULL                |                 1 |               0 |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
1 row in set (0.00 sec)

mysql> xa recover;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data   |
+----------+--------------+--------------+--------+
|        1 |            6 |            0 | xatest |
+----------+--------------+--------------+--------+
1 row in set (0.00 sec)

Nesse caso, revertemos a transação preparada.

mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)

Depois que a transação XA for revertida, a pré-verificação será bem-sucedida.

{
  "id": "auroraUpgradeCheckForIncompleteXATransactions",
  "title": "Pre-checks for XA Transactions in prepared state.",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Verifique se a atualização é compatível com a classe de instância atual

No momento, não é possível fazer atualização no local do Aurora MySQL versão 2.12.0 ou 2.12.1, em que a classe de instância de banco de dados do gravador é db.r6i.32xlarge. Nesse caso, a pré-verificação exibe um erro. Para permitir que a atualização continue, você pode alterar a classe de instância de banco de dados para db.r6i.24xlarge ou menor. Ou você pode fazer a atualização para o Aurora MySQL versão 2.12.2 ou posterior, na qual a atualização no local para o Aurora MySQL versão 3 é compatível com db.r6i.32xlarge.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForInstanceLimit",
  "title": "Checks if upgrade is supported on the current instance class",
  "status": "OK",
  "description": "Upgrade from Aurora Version 2.12.0 and 2.12.1 may fail for 32.xl and above instance class.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Upgrade is not supported on this instance size for Aurora MySql Version 2.12.1. Before upgrading to Aurora MySql 3, please consider either: 1. Changing the instance class to 24.xl or lower. -or- 2. Upgrading to patch version 2.12.2 or higher."
      }
  ]
},

A pré-verificação exibe um erro porque a instância de banco de dados do gravador está usando a classe de instância db.r6i.32xlarge e está sendo executada no Aurora MySQL versão 2.12.1.

Nível de pré-verificação: erro

Verifique se há usuários internos da versão 8.0

Essa pré-verificação se aplica apenas ao Aurora MySQL versão 3.03.0 e anterior. Se você encontrar um erro com essa pré-verificação, faça a atualização para o Aurora MySQL versão 3.04 ou posterior.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForInternalUsers",
  "title": "Check for 8.0 internal users.",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Verifique se o usuário principal do RDS existe

O MySQL 8 adicionou um novo modelo de privilégios com suporte para perfil e privilégios dinâmicos a fim de tornar o gerenciamento de privilégios mais fácil e refinado. Como parte dessa mudança, o Aurora MySQL introduziu o novo rds_superuser_role, que é concedido automaticamente ao usuário principal do banco de dados na atualização do Aurora MySQL versão 2 para a versão 3.

Consulte mais informações sobre os perfis e privilégios atribuídos ao usuário principal no Aurora MySQL em Privilégios da conta de usuário mestre. Consulte mais informações sobre o modelo de privilégio baseado em perfil do Aurora MySQL versão 3 em Modelo de privilégios baseados em funções.

Essa pré-verificação confere se o usuário principal existe no banco de dados. Se o usuário principal não existir, a pré-verificação falhará. Para permitir que a atualização continue, recrie o usuário principal redefinindo a senha dele ou criando o usuário manualmente. Tente realizar a atualização novamente. Consulte mais informações sobre como redefinir a senha do usuário principal em Alterar a senha do usuário mestre do banco de dados.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForMasterUser",
  "title": "Check if master user exists",
  "status": "OK",
  "description": "Throws error if master user has been dropped!",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Your Master User on host '%' has been dropped. To proceed with the upgrade, recreate the master user `reinvent` on default host '%'"
      }
  ]
}

Depois de redefinir sua senha do usuário principal, a pré-verificação será concluída com êxito e você poderá tentar fazer a atualização novamente.

O exemplo a seguir usa a AWS CLI para redefinir a senha. As alterações de senha são aplicadas imediatamente.

aws rds modify-db-cluster \
    --db-cluster-identifier my-db-cluster \
    --master-user-password my-new-password

Depois, a pré-verificação é bem-sucedida.

{
  "id": "auroraUpgradeCheckForMasterUser",
  title": "Check if master user exists",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Verifique as colunas de geometria nos índices de prefixo

Desde o MySQL 8.0.12, você não pode mais criar um índice prefixado em uma coluna usando o tipo de dados GEOMETRY. Consulte mais informações em WL#11808.

Se algum desses índices existir, a atualização falhará. Para resolver o problema, descarte os índices prefixados GEOMETRY nas tabelas mencionadas na falha de pré-verificação.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexs",
  "status": "OK",
  "description": "Consider dropping the prefix Indexes of geometry columns and restart the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.geom_index_prefix",
        "description": "Table `test`.`geom_index_prefix` has an index `LatLon` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `LatLon` ON `test`.`geom_index_prefix`;"
      }
  ]
}

A pré-verificação relata um erro porque a tabela test.geom_index_prefix contém um índice com um prefixo em uma coluna GEOMETRY.

Depois que você descartar esse índice, a pré-verificação será bem-sucedida.

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexs",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Verifique se há inconsistência relacionada a caracteres especiais em procedimentos armazenados

Antes do MySQL 8.0, nomes de bancos de dados, nomes de tabelas e outros objetos correspondiam a arquivos no diretório de dados, ou seja, metadados baseados em arquivos. Como parte da atualização para o MySQL 8.0, todos os objetos do banco de dados são migrados para as novas tabelas internas do dicionário de dados que são armazenadas no esquema mysql para dar suporte ao recém-implementado Atomic Data Dictionary. Como parte da migração de procedimentos armazenados, a definição e o corpo de cada procedimento são validados à medida que são inseridos no novo dicionário de dados.

Antes do MySQL 8, em alguns casos era possível criar rotinas armazenadas ou inserir diretamente na tabela mysql.proc procedimentos que continham caracteres especiais. Por exemplo, você podia criar um procedimento armazenado que continha um comentário com o caractere de espaço rígido incompatível \xa0. Se algum desses procedimentos for encontrado, a atualização falhará.

Essa pré-verificação confirma se o corpo e a definição de seus procedimentos armazenados não contêm esses caracteres. Para que a atualização continue, recrie esses procedimentos armazenados sem nenhum caractere oculto ou especial.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
  "title": "Check for inconsistency related to special characters in stored procedures.",
  "status": "OK",
  "description": "Following procedure(s) has special characters inconsistency.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "information_schema.routines",
        "description": "Data Dictionary Metadata is inconsistent for the procedure `get_version_proc` in the database `test` due to usage of special characters in procedure body. To avoid that, drop and recreate the procedure without any special characters before proceeding with the Upgrade."
      }
  ]
}

A pré-verificação informa que o cluster de banco de dados contém um procedimento chamado get_version_proc no banco de dados test que contém caracteres especiais no corpo do procedimento.

Depois que você descarta e recria o procedimento armazenado, a pré-verificação é bem-sucedida, permitindo que a atualização continue.

{
  "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
  "title": "Check for inconsistency related to special characters in stored procedures.",
  "status": "OK",
  "detectedProblems": []
},

Nível de pré-verificação: erro

Verifique a incompatibilidade do tipo de objeto para o esquema sys

O esquema sys é um conjunto de objetos e visualizações em um banco de dados do MySQL que ajuda os usuários a solucionar problemas em instâncias de banco de dados, bem como a otimizá-las e monitorá-las. Quando é feita uma atualização de uma versão principal do Aurora MySQL versão 2 para a versão 3, as visualizações do esquema sys são recriadas e atualizadas para as novas definições do Aurora MySQL versão 3.

Se, na atualização, algum objeto no esquema sys for definido usando mecanismos de armazenamento (sys_config/BASE TABLE em INFORMATION_SCHEMA.TABLES), em vez de visualizações, a atualização falhará. Essas tabelas podem ser encontradas na tabela information_schema.tables. Esse não é um comportamento esperado, mas em alguns casos pode ocorrer devido a um erro do usuário.

Essa pré-verificação valida todos os objetos do esquema sys para garantir que eles usem as definições de tabela corretas e que as visualizações não sejam definidas erroneamente como tabelas do InnoDB ou MyISAM. Para resolver o problema, corrija manualmente todos os objetos exibidos renomeando-os ou descartando-os. Tente realizar a atualização novamente.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
  "title": "Check object type mismatch for sys schema.",
  "status": "OK",
  "description": "Database contains objects with type mismatch for sys schema.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "sys.waits_global_by_latency",
        "description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
      }
  ]
}

A pré-verificação informa que a visualização sys.waits_global_by_latency no esquema sys tem uma incompatibilidade de tipo que está impedindo que a atualização continue.

Depois de fazer login na instância de banco de dados, você pode ver que esse objeto está definido como uma tabela do InnoDB, quando deveria ser uma visualização.

mysql> show create table sys.waits_global_by_latency\G
*************************** 1. row ***************************
       Table: waits_global_by_latency
Create Table: CREATE TABLE `waits_global_by_latency` (
  `events` varchar(128) DEFAULT NULL,
  `total` bigint(20) unsigned DEFAULT NULL,
  `total_latency` text,
  `avg_latency` text,
  `max_latency` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

Para resolver esse problema, podemos descartar e recriar a visualização com a definição correta ou renomeá-la. Durante o processo de atualização, ela será criada automaticamente com a definição correta da tabela.

mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)

Após isso, a pré-verificação é concluída com êxito.

{
  "id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
  "title": "Check object type mismatch for sys schema.",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Verifique o limite superior do nome da coluna na visualização

A extensão máxima permitida para um nome de coluna no MySQL é 64 caracteres. Antes do MySQL 8.0, em alguns casos era possível criar uma visualização com um nome de coluna com mais de 64 caracteres. Se alguma dessas visualizações existir na instância de banco de dados, um erro de pré-verificação será retornado e a atualização falhará. Para que a atualização continue, você deve recriar as visualizações em questão, garantindo que as extensões de coluna tenham menos de 64 caracteres. Tente realizar a atualização novamente.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForViewColumnNameLength",
  "title": "Check for upperbound limit related to column name in view.",
  "status": "OK",
  "description": "Following view(s) has column(s) with length greater than 64.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.colname_view_test.col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad",
        "description": "View `test`.`colname_view_test`has column `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` with invalid column name length. To avoid Upgrade errors, view should be altered by renaming the column name so that its length is not 0 and doesn't exceed 64."
      }
  ]
}

A pré-verificação informa que a visualização test.colname_view_test contém uma coluna col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad que excede o tamanho máximo permitido de 64 caracteres.

Observando a definição da visualização, podemos ver a coluna incorreta.

mysql> desc `test`.`colname_view_test`;
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| Field                                                            | Type        | Null | Key | Default | Extra |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| col1                                                             | varchar(20) | YES  |     | NULL    |       |
| col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11)     | YES  |     | NULL    |       |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

Para que a atualização continue, recrie a visualização, garantindo que o tamanho da coluna não exceda 64 caracteres.

mysql> drop view `test`.`colname_view_test`;
Query OK, 0 rows affected (0.01 sec)

mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test;
Query OK, 0 rows affected (0.01 sec)

mysql> desc `test`.`colname_view_test`;
+------------+-------------+------+-----+---------+-------+
| Field      | Type        | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| col1       | varchar(20) | YES  |     | NULL    |       |
| col2_nopad | int(11)     | YES  |     | NULL    |       |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

Após isso, a pré-verificação é bem-sucedida.

{
  "id": "auroraUpgradeCheckForViewColumnNameLength",
  "title": "Check for upperbound limit related to column name in view.",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Verifique se há tabelas com índices definidos com uma extensão de prefixo com mais de 255 bytes em colunas minúsculas

Ao criar um índice em uma coluna usando um tipo de dados binário no MySQL, você deve adicionar uma extensão de prefixo na definição do índice. Antes do MySQL 8.0, em alguns casos era possível especificar uma extensão de prefixo superior ao tamanho máximo permitido desses tipos de dados. Um exemplo são as colunas TINYTEXT e TINYBLOB, em que o tamanho máximo de dados permitido é 255 bytes, mas prefixos de índice maiores eram permitidos. Consulte mais informações em InnoDB Limits na documentação do MySQL.

Se essa pré-verificação falhar, descarte o índice incorreto ou reduza a extensão do prefixo das colunas TINYTEXT e TINYBLOB do índice para menos de 255 bytes. Tente realizar a atualização novamente.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
  "status": "OK",
  "description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.tintxt_prefixed_index.col1",
        "description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63."
      }
  ]
}

A pré-verificação relata um erro referente à tabela test.tintxt_prefixed_index, porque ela tem um índice PRIMARY com um prefixo com mais de 255 bytes em uma coluna TINYTEXT ou TINYBLOB.

Observando a definição dessa tabela, podemos ver que a chave primária tem um prefixo de 65 na coluna TINYTEXT col1. Como a tabela é definida usando o conjunto de caracteres utf8mb4, que armazena 4 bytes por caractere, o prefixo excede o limite de 255 bytes.

mysql> show create table `test`.`tintxt_prefixed_index`\G
*************************** 1. row ***************************
       Table: tintxt_prefixed_index
Create Table: CREATE TABLE `tintxt_prefixed_index` (
  `col1` tinytext NOT NULL,
  `col2` tinytext,
  `col_id` tinytext,
  PRIMARY KEY (`col1`(65))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC
1 row in set (0.00 sec)

Modificar o prefixo do índice para 63 ao usar o conjunto de caracteres utf8mb4 permitirá que a atualização continue.

mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD  PRIMARY KEY (`col1`(63));
Query OK, 0 rows affected (0.04 sec)
Records: 0  Duplicates: 0  Warnings: 0

Após isso, a pré-verificação é bem-sucedida.

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: erro

Verifique a inconsistência dos metadados do InnoDB ausentes na tabela mysql.host

Essa é uma pré-verificação somente interna realizada pelo serviço RDS. Os erros serão gerenciados automaticamente na atualização e podem ser ignorados com segurança.

Se você encontrar algum erro nessa pré-verificação, abra um caso no AWS Support para solicitar que a inconsistência de metadados seja resolvida. Ou você pode tentar fazer a atualização novamente executando um despejo lógico e, depois, restaurando para um novo cluster de banco de dados do Aurora MySQL versão 3.

Nível de pré-verificação: erro

Verifique se há comentários de coluna utf8mb3 inválidos

Essa pré-verificação identifica tabelas que contêm comentários de coluna com codificação de caracteres utf8mb3 inválida. No MySQL 8.0, uma validação mais rigorosa é aplicada à codificação de caracteres nos metadados, incluindo comentários de coluna. Se algum comentário de coluna contiver caracteres que não sejam válidos no conjunto de caracteres utf8mb3, a atualização falhará.

A causa mais comum desse problema é a presença de caracteres fora do plano multilíngue básico (BMP) nos comentários de coluna. Os caracteres fora do BMP exigem codificação UTF-8 de 4 bytes (utf8mb4), mas utf8mb3 aceita apenas sequências de 3 bytes, que não podem representar esses caracteres.

Para resolver esse problema, antes de tentar fazer a atualização, você deve modificar os comentários de coluna para remover ou substituir quaisquer caracteres fora do BMP. Você pode usar a instrução ALTER TABLE para atualizar os comentários de coluna.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
  "title": "Check for invalid utf8mb3 column comments.",
  "status": "OK",
  "description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.t2",
        "description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
      }
  ]
}

A pré-verificação informa que a tabela test.t2 contém caracteres utf8mb3 inválidos em um ou mais comentários de coluna, especificamente devido à presença de caracteres fora do BMP.

Para resolver esse problema, você pode identificar as colunas problemáticas e atualizar os respectivos comentários. Primeiro, examine a estrutura da tabela para identificar colunas com comentários:

mysql> SHOW CREATE TABLE test.t2\G

Depois de identificar as colunas com comentários problemáticos, atualize-as usando a instrução ALTER TABLE. Por exemplo:

mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';

Também é possível remover o comentário completamente:

mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';

Depois de atualizar todos os comentários problemáticos da coluna, a pré-verificação será aprovada e a atualização poderá prosseguir:

{
  "id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
  "title": "Check for invalid utf8mb3 column comments.",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: aviso

Considerações sobre o novo plug-in de autenticação padrão

No MySQL 8.0, o plug-in de autenticação caching_sha2_password foi introduzido, fornecendo criptografia de senha mais segura e melhor desempenho do que o plug-in obsoleto mysql_native_password. No Aurora MySQL versão 3, o plug-in de autenticação padrão usado para usuários do banco de dados é o mysql_native_password.

Essa pré-verificação avisa que esse plug-in será removido e o padrão alterado em uma futura versão principal. Considere avaliar a compatibilidade dos clientes e usuários da aplicação antes dessa mudança.

Consulte mais informações em caching_sha2_password Compatibility Issues and Solutions na documentação do MySQL.

Exemplos de resultado:

{
  "id": "defaultAuthenticationPlugin",
  "title": "New default authentication plugin considerations",
  "description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection authentication). However, it also has compatibility implications that may affect existing MySQL installations. If your MySQL installation must serve pre-8.0 clients and you encounter compatibility issues after upgrading, the simplest way to address those issues is to reconfigure the server to revert to the previous default authentication plugin (mysql_native_password). For example, use these lines in the server option file:\n\n[mysqld]\ndefault_authentication_plugin=mysql_native_password\n\nHowever, the setting should be viewed as temporary, not as a long term or permanent solution, because it causes new accounts created with the setting in effect to forego the improved authentication security.\nIf you are using replication please take time to understand how the authentication plugin changes may impact you.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication"
},

Nível de pré-verificação: aviso

Uso do sinalizador obsoleto MAXDB sql_mode

No MySQL 8.0, várias opções obsoletas de variáveis de sistema sql_mode foram removidas, como a MAXDB. Essa pré-verificação examina todas as sessões atualmente conectadas, bem como rotinas e gatilhos, para garantir que nenhuma tenha sql_mode definido para qualquer combinação que inclua MAXDB.

Exemplos de resultado:

{
  "id": "maxdbFlagCheck",
  "title": "Usage of obsolete MAXDB sql_mode flag",
  "status": "OK",
  "description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.maxdb_stored_routine",
        "description": "PROCEDURE uses obsolete MAXDB sql_mode",
        "dbObjectType": "Routine"
      }
  ]
}

A pré-verificação informa que a rotina test.maxdb_stored_routine contém uma opção sql_mode incompatível.

Depois de fazer login no banco de dados, você pode ver na definição de rotina que sql_mode contém MAXDB.

 > SHOW CREATE PROCEDURE test.maxdb_stored_routine\G

*************************** 1. row ***************************
           Procedure: maxdb_stored_routine
            sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
    Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
    SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Para resolver o problema, recrie o procedimento depois de definir o sql_mode correto no cliente.

Recrie o procedimento sem o sql_mode incompatível.

mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)

mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
    -> SQL SECURITY DEFINER
    -> BEGIN
    ->     SELECT * FROM test;
    -> END$$
Query OK, 0 rows affected (0.00 sec)

mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
           Procedure: maxdb_stored_routine
            sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
    Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
    SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

A pré-verificação é bem-sucedida.

{
  "id": "maxdbFlagCheck",
  "title": "Usage of obsolete MAXDB sql_mode flag",
  "status": "OK",
  "detectedProblems": []
}

Nível de pré-verificação: aviso

Verifique se estão sendo usados cifrões únicos obsoletos em nomes de objeto

Desde o MySQL 8.0.32, o uso do cifrão ($) como o primeiro caractere de um identificador sem aspas foi descontinuado. Se você tiver esquemas, tabelas, visualizações, colunas ou rotinas contendo $ como primeiro caractere, essa pré-verificação exibirá um aviso. Embora esse aviso não impeça a continuidade da atualização, recomendamos que você tome medidas o quanto antes para resolver isso. A partir do MySQL 8.4, qualquer um desses identificadores retornará um erro de sintaxe em vez de um aviso.

Exemplos de resultado:

{
  "id": "mysqlDollarSignNameCheck",
  "title": "Check for deprecated usage of single dollar signs in object names",
  "status": "OK",
  "description": "Warning: The following objects have names with deprecated usage of dollar sign ($) at the begining of the identifier. To correct this warning, ensure, that names starting with dollar sign, also end with it, similary to quotes ($example$). ",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.$deprecated_syntx",
        "description": " name starts with $ sign."
      }
  ]
},

A pré-verificação exibe um aviso porque a tabela $deprecated_syntx no esquema test contém um $ como o primeiro caractere.

Nível de pré-verificação: aviso

Uso de objetos de banco de dados com nomes conflitantes com novas palavras-chave reservadas

Essa verificação é semelhante à routineSyntaxCheck, pois verifica o uso de objetos de banco de dados com nomes conflitantes com novas palavras-chave reservadas. Embora eles não impeçam as atualizações, você precisa avaliar os avisos com cuidado.

Exemplos de resultado:

Usando o exemplo anterior com a tabela chamada except, a pré-verificação exibe um aviso:

{
  "id": "reservedKeywordsCheck",
  "title": "Usage of db objects with names conflicting with new reserved keywords",
  "status": "OK",
  "description": "Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.except",
        "description": "Table name",
        "dbObjectType": "Table"
      }
  ]
}

Esse aviso permite que você saiba que pode haver algumas consultas de aplicação a serem analisadas. Se as consultas da aplicação não tiverem o escape dos literais de string correto, elas poderão apresentar erros após a atualização para o MySQL 8.0. Analise as aplicações para confirmar, testando com base em um clone ou snapshot do cluster de banco de dados do Aurora MySQL em execução na versão 3.

Exemplo de uma consulta de aplicação sem escape que falhará após a atualização:

SELECT * FROM escape;

Exemplo de uma consulta de aplicação com escape correto que será bem-sucedida após a atualização:

SELECT * FROM 'escape';

Nível de pré-verificação: aviso

Uso do conjunto de caracteres utf8mb3

No MySQL 8.0, o conjunto de caracteres utf8mb3 foi descontinuado e será removido em uma futura versão principal do MySQL. Essa pré-verificação é implementada para gerar um aviso se algum objeto de banco de dados que usa esse conjunto de caracteres for detectado. Embora isso não impeça a continuidade de uma atualização, é altamente recomendável que você avalie a possibilidade de migrar as tabelas para o conjunto de caracteres utf8mb4, que é o padrão a partir do MySQL 8.0. Consulte mais informações sobre utf8mb3 e utf8mb4 em Converting Between 3-Byte and 4-Byte Unicode Character Sets na documentação do MySQL.

Exemplos de resultado:

{
  "id": "utf8mb3",
  "title": "Usage of utf8mb3 charset",
  "status": "OK",
  "description": "Warning: The following objects use the deprecated utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support. The utf8mb3 character is subject to removal in the future.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.t1.col1",
        "description": "column's default character set: utf8",
        "dbObjectType": "Column"
      },
      {
        "level": "Warning",
        "dbObject": "test.t1.col2",
        "description": "column's default character set: utf8",
        "dbObjectType": "Column"
      }
  ]
}

Para resolver esse problema, recrie as tabelas e os objetos referidos. Antes de fazer isso, consulte mais informações e pré-requisitos em Converting Between 3-Byte And 4-Byte Unicode Character Sets na documentação do MySQL.

Nível de pré-verificação: aviso

Valores de data zero, data e hora e carimbo de data/hora

O MySQL agora impõe regras mais rígidas em relação ao uso de valores zero nas colunas de data, data e hora e carimbo de data/hora. Recomendamos que você use os modos NO_ZERO_IN_DATE e NO_ZERO_DATE SQL em conjunto com o modo strict, pois eles serão mesclados com o modo strict em uma versão futura do MySQL.

Se a configuração sql_mode de qualquer uma de suas conexões de banco de dados, no momento da execução da pré-verificação, não incluir esses modos, um aviso será gerado na pré-verificação. Talvez os usuários ainda consigam inserir valores de data, data e hora e carimbo de data/hora contendo valores zero. No entanto, é altamente recomendável substituir valores zero por valores válidos, pois no futuro eles podem mudar de comportamento e não funcionar corretamente. Como é um aviso, isso não impede as atualizações, mas recomendamos que você comece a pensar em agir.

Exemplos de resultado:

{
  "id": "zeroDatesCheck",
  "title": "Zero Date, Datetime, and Timestamp values",
  "status": "OK",
  "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
  "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "global.sql_mode",
        "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      },
      {
        "level": "Warning",
        "dbObject": "session.sql_mode",
        "description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      }
  ]
}

Nível de pré-verificação: aviso

Verifica se a extensão da lista de histórico do segmento de reversão para o cluster é alto

Como mencionado em auroraUpgradeCheckForIncompleteXATransactions, ao executar o processo de atualização da versão principal, é essencial que a instância de banco de dados do Aurora MySQL versão 2 passe por um desligamento limpo. Isso garante que todas as transações sejam confirmadas ou revertidas e que o InnoDB tenha eliminado todos os registros de logs undo.

Se o tamanho da lista de histórico (HLL) de segmentos de reversão do cluster de banco de dados for grande, isso poderá prolongar o tempo que o InnoDB leva para concluir a limpeza dos registros de log undo, aumentando o tempo de inatividade durante o processo de atualização da versão principal. Se a pré-verificação detectar que o valor de HLL no cluster de banco de dados está alto, ela emitirá um aviso. Embora isso não impeça que a atualização continue, recomendamos que você monitore de perto o HLL no cluster de banco de dados. Mantê-lo em níveis baixos reduz o tempo de inatividade necessário durante a atualização de uma versão principal. Consulte mais informações sobre o monitoramento de HLL em O tamanho da lista de histórico do InnoDB aumentou significativamente.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForRollbackSegmentHistoryLength",
  "title": "Checks if the rollback segment history length for the cluster is high",
  "status": "OK",
  "description": "Rollback Segment History length is greater than 1M. Upgrade may take longer time.",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "information_schema.innodb_metrics",
        "description": "The InnoDB undo history list length('trx_rseg_history_len') is 82989114. Upgrade may take longer due to purging of undo information for old row versions."
      }
  ]
}

A pré-verificação exibe um aviso porque detectou que o valor de HLL de undo do InnoDB estava alto no cluster de banco de dados (82989114). Embora a atualização continue, dependendo da quantidade de undo a limpar, isso pode estender o tempo de inatividade necessário durante o processo de atualização.

Recomendamos que você investigue as transações abertas no cluster de banco de dados antes de executar atualização na produção, para garantir que o HLL seja mantido em um valor gerenciável.

Nível de pré-verificação: aviso

Verifica se há muitas modificações de linha não confirmadas

Como mencionado em auroraUpgradeCheckForIncompleteXATransactions, ao executar o processo de atualização da versão principal, é essencial que a instância de banco de dados do Aurora MySQL versão 2 passe por um desligamento limpo. Isso garante que todas as transações sejam confirmadas ou revertidas e que o InnoDB tenha eliminado todos os registros de logs undo.

Se o cluster de banco de dados tiver transações que modificaram um grande número de linhas, isso poderá prolongar o tempo que o InnoDB leva para concluir uma reversão dessa transação como parte do processo de desligamento limpo. Se a pré-verificação encontrar transações de longa execução, com um grande número de linhas modificadas no cluster de banco de dados, ela gerará um aviso. Embora isso não impeça que a atualização continue, recomendamos que você monitore de perto o tamanho das transações ativas no cluster de banco de dados. Mantê-lo em níveis baixos reduz o tempo de inatividade necessário durante a atualização de uma versão principal.

Exemplos de resultado:

{
  "id": "auroraUpgradeCheckForUncommittedRowModifications",
  "title": "Checks if there are many uncommitted modifications to rows",
  "status": "OK",
  "description": "Database contains uncommitted row changes greater than 10M. Upgrade may take longer time.",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "information_schema.innodb_trx",
        "description": "The database contains 11000000 uncommitted row change(s) in 1 transaction(s). Upgrade may take longer due to transaction rollback."
      }
  ]
},

A pré-verificação informa que o cluster de banco de dados contém uma transação com 11 milhões de alterações de linha não confirmadas que precisarão ser revertidas durante o processo de desligamento limpo. A atualização continuará, mas para reduzir o tempo de inatividade durante o processo, recomendamos que você monitore e investigue isso antes de realizar a atualização nos clusters de produção.

Para visualizar transações ativas na instância de banco de dados do gravador, você pode usar a tabela information_schema.innodb_trx. A consulta a seguir na instância de banco de dados do gravador mostra as transações atuais, o tempo de execução, o estado e as linhas modificadas do cluster de banco de dados.

# Example of uncommitted transaction
mysql> SELECT trx_started,
       TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
       trx_mysql_thread_id AS show_processlist_connection_id,
       trx_id,
       trx_state,
       trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| trx_started         | seconds_trx_has_been_running | show_processlist_connection_id | trx_id   | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| 2024-08-12 18:32:52 |                         1592 |                          20041 | 52866130 | RUNNING   |      11000000 |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
1 row in set (0.01 sec)

# Example of transaction rolling back
mysql> SELECT trx_started,
       TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
       trx_mysql_thread_id AS show_processlist_connection_id,
       trx_id,
       trx_state,
       trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| trx_started         | seconds_trx_has_been_running | show_processlist_connection_id | trx_id   | trx_state    | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| 2024-08-12 18:32:52 |                         1719 |                          20041 | 52866130 | ROLLING BACK |      10680479 |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
1 row in set (0.01 sec)

Depois que a transação é confirmada ou revertida, a pré-verificação não exibe mais um aviso. Consulte a documentação do MySQL e sua equipe de aplicação antes de reverter qualquer transação grande, pois a conclusão da reversão pode levar algum tempo, dependendo do tamanho da transação.

{
  "id": "auroraUpgradeCheckForUncommittedRowModifications",
  "title": "Checks if there are many uncommitted modifications to rows",
  "status": "OK",
  "detectedProblems": []
},

Consulte mais informações sobre como otimizar o gerenciamento de transações do InnoDB e o possível impacto da execução e reversão de grandes transações em instâncias do banco de dados do MySQL em Optimizing InnoDB Transaction Management na documentação do MySQL.

Nível de pré-verificação: aviso

Uso dos sinalizadores obsoletos sql_mode

Além de MAXDB, várias outras opções de sql_mode foram removidas: DB2, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS e NO_TABLE_OPTIONS. A partir do MySQL 8.0, nenhum desses valores pode ser atribuído à variável de sistema sql_mode. Se essa pré-verificação encontrar alguma sessão aberta usando essas configurações de sql_mode, garanta que os grupos de parâmetros da instância e do cluster de banco de dados, bem como as configurações e aplicações cliente, estejam atualizados para desativá-las. Consulte mais informações na documentação do MySQL.

Exemplos de resultado:

{
  "id": "sqlModeFlagCheck",
  "title": "Usage of obsolete sql_mode flags",
  "status": "OK",
  "detectedProblems": []
}

Para resolver qualquer uma dessas falhas de pré-verificação, consulte maxdbFlagCheck.

Nível de pré-verificação: erro, aviso ou alerta

Problemas relatados pelo comando check table x for upgrade

Antes de iniciar a atualização para o Aurora MySQL versão 3, check table for upgrade é executado em cada tabela nos esquemas do usuário no cluster de banco de dados. Essa pré-verificação não é a mesma que checkTableMysqlSchema.

O comando check table for upgrade examina as tabelas em busca de possíveis problemas que possam surgir durante uma atualização para uma versão mais recente do MySQL. Executar esse comando antes de tentar fazer a atualização pode ajudar a identificar e resolver quaisquer incompatibilidades com antecedência, facilitando o respectivo processo.

Esse comando executa várias verificações em cada tabela, como as seguintes:

Ao contrário de outras pré-verificações, ela pode exibir um erro, aviso ou alerta, dependendo da saída check table. Se essa pré-verificação exibir alguma tabela, examine-a cuidadosamente, assim como o código de retorno e a mensagem, antes de iniciar a atualização. Consulte mais informações em CHECK TABLE Statement na documentação do MySQL.

Aqui, fornecemos um exemplo de erro e um exemplo de aviso.

Exemplo de erro:

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.parent",
        "description": "Table 'test.parent' doesn't exist"
      }
  ]
},

A pré-verificação relata um erro de que a tabela test.parent não existe.

O arquivo mysql-error.log da instância de banco de dados do gravador mostra que há um erro de chave externa.

2024-08-13T15:32:10.676893Z 62 [Warning] InnoDB: Load table `test`.`parent` failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.
2024-08-13T15:32:10.676905Z 62 [Warning] InnoDB: Cannot open table test/parent from the internal data dictionary of InnoDB though the .frm file for the table exists.
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.

Faça login na instância de banco de dados do gravador e execute show engine innodb status\G para ter mais informações sobre o erro de chave externa.

mysql> show engine innodb status\G
*************************** 1. row ***************************
  Type: InnoDB
  Name:
Status:
=====================================
2024-08-13 15:33:33 0x14ef7b8a1700 INNODB MONITOR OUTPUT
=====================================
.
.
.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-08-13 15:32:10 0x14ef6dbbb700 Error in foreign key constraint of table test/child:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match the ones in table. Constraint:
,
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
The index in the foreign key in table is p_name_idx
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html for correct foreign key definition.
.
.

A mensagem LATEST FOREIGN KEY ERROR informa que a restrição de chave externa fk_pname na tabela test.child, que faz referência à tabela test.parent, tem um índice ausente ou uma incompatibilidade de tipo de dados. A documentação do MySQL sobre restrições de chave externa menciona que as colunas referidas em uma chave externa devem ter um índice associado e que as colunas principal/secundárias devem usar o mesmo tipo de dados.

Para verificar se isso está relacionado a um índice ausente ou a uma incompatibilidade de tipo de dados, faça login no banco de dados e verifique as definições da tabela desativando temporariamente a variável de sessão foreign_key_checks. Depois de fazer isso, podemos ver que a restrição secundária em questão (fk_pname) usa p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL para se referir à tabela principal name varchar(20) NOT NULL. A tabela principal usa DEFAULT CHARSET=utf8, mas a coluna p_name da tabela secundária usa latin1, então o erro de incompatibilidade do tipo de dados é gerado.

mysql> show create table parent\G
ERROR 1146 (42S02): Table 'test.parent' doesn't exist

mysql> show create table child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int(11) NOT NULL,
  `p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `p_name_idx` (`p_name`),
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> set foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)

mysql> show create table parent\G
*************************** 1. row ***************************
       Table: parent
Create Table: CREATE TABLE `parent` (
  `name` varchar(20) NOT NULL,
  PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> show create table child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int(11) NOT NULL,
  `p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `p_name_idx` (`p_name`),
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

Para resolver esse problema, podemos alterar a tabela secundária para que use o mesmo conjunto de caracteres da tabela principal ou alterar a tabela principal para que use o mesmo conjunto de caracteres da tabela secundária. Aqui, como a tabela secundária usa explicitamente latin1 na definição da coluna p_name, executamos ALTER TABLE para modificar o conjunto de caracteres para utf8.

mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL;
Query OK, 0 rows affected (0.06 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> flush tables;
Query OK, 0 rows affected (0.01 sec)

Depois disso, a pré-verificação é concluída com êxito e a atualização pode continuar.

Exemplo de aviso:

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.orders",
        "description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute."
      }
  ]
}

A pré-verificação exibe um aviso para o gatilho delete_audit_trigg na tabela test.orders porque ela não tem um atributo CREATED. De acordo com Checking Version Compatibility na documentação do MySQL, essa mensagem é informativa e é impressa para gatilhos criados antes do MySQL 5.7.2.

Como é um aviso, isso não impede que a atualização continue. No entanto, se quiser resolver o problema, você pode recriar o gatilho em questão e a pré-verificação será bem-sucedida sem nenhum aviso.

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": []
},