' 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.
Antes de recriar espaços de tabela, consulte [Online DDL Operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html) na documentação do MySQL para entender os efeitos do bloqueio e da movimentação de dados nas transações em primeiro plano.
```
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": []
}
```
**auroraGetDanglingFulltextIndex**
**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 \$176012](https://bugs.mysql.com/bug.php?id=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": []
},
```
**auroraUpgradeCheckForDatafilePathInconsistency**
**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": []
}
```
**auroraUpgradeCheckForFtsSpaceIdZero**
**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](https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html) a uma tabela do InnoDB, vários espaços de tabela de índice auxiliares são criados. Devido a um [erro](https://bugs.mysql.com/bug.php?id=72132) 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](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace), 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.
Antes de recriar espaços de tabela, consulte [Partitioning Operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning) na documentação do MySQL para entender os efeitos do bloqueio e da movimentação de dados nas transações em primeiro plano.
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForIncompleteXATransactions**
**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](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown). 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](https://dev.mysql.com/doc/refman/5.7/en/xa.html) 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](https://dev.mysql.com/doc/refman/5.7/en/xa-statements.html) na documentação do MySQL. Consulte mais informações sobre estados de transações de XA em [XA Transaction States](https://dev.mysql.com/doc/refman/5.7/en/xa-states.html) 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\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) e na saída `XA RECOVER`.
Antes de confirmar ou reverter uma transação, recomendamos que você consulte a [documentação do MySQL](https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html) e os requisitos da aplicação.
```
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": []
}
```
**auroraUpgradeCheckForInstanceLimit**
**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](Concepts.DBInstanceClass.md) 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.
**auroraUpgradeCheckForInternalUsers**
**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": []
}
```
**auroraUpgradeCheckForMasterUser**
**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](https://dev.mysql.com/doc/refman/8.0/en/roles.html) e [privilégios dinâmicos](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges) 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](UsingWithRDS.MasterAccounts.md). 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](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
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](Aurora.Modifying.md#Aurora.Modifying.Password).
**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": []
}
```
**auroraUpgradeCheckForPrefixIndexOnGeometryColumns**
**Nível de pré-verificação: erro**
**Verifique as colunas de geometria nos índices de prefixo**
Desde o [MySQL 8.0.12](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-12.html#mysqld-8-0-12-spatial-support), você não pode mais criar um índice [prefixado](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) em uma coluna usando o tipo de dados [GEOMETRY](https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html). Consulte mais informações em [WL\$111808](https://dev.mysql.com/worklog/task/?id=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": []
}
```
**auroraUpgradeCheckForSpecialCharactersInProcedures**
**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](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html). 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](https://en.wikipedia.org/wiki/Non-breaking_space) 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": []
},
```
**auroraUpgradeCheckForSysSchemaObjectTypeMismatch**
**Nível de pré-verificação: erro**
**Verifique a incompatibilidade do tipo de objeto para o esquema `sys`**
O [esquema sys](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html) é 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\$1SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html)), 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\$1global\$1by\$1latency](https://dev.mysql.com/doc/refman/5.7/en/sys-waits-global-by-latency.html) 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](https://github.com/mysql/mysql-server/blob/mysql-5.7.44/scripts/sys_schema/views/p_s/waits_global_by_latency.sql) 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": []
}
```
**auroraUpgradeCheckForViewColumnNameLength**
**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](https://dev.mysql.com/doc/refman/5.7/en/identifier-length.html) 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": []
}
```
**auroraUpgradeCheckIndexLengthLimitOnTinyColumns**
**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](https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html) no MySQL, você deve adicionar uma extensão de [prefixo](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) 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](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) 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": []
}
```
**auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**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](https://aws.amazon.com/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.
**auroraUpgradeCheckForInvalidUtf8mb3ColumnComments**
**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": []
}
```
Antes de modificar os comentários da coluna, você deve atualizar adequadamente qualquer código ou documentação da aplicação que dependa desses comentários. Considere migrar para o conjunto de caracteres utf8mb4 para obter melhor suporte a Unicode se sua aplicação exigir caracteres fora do BMP.
## Avisos
As pré-verificações a seguir geram avisos quando a pré-verificação falha e a atualização pode continuar.
**Topics**
+ [Pré-verificações do MySQL que exibem avisos](#precheck-descriptions-warnings.mysql)
+ [Pré-verificações do Aurora MySQL que exibem avisos](#precheck-descriptions-warnings.aurora)
### Pré-verificações do MySQL que exibem avisos
As seguintes pré-verificações são do MySQL Community:
+ [defaultAuthenticationPlugin](#defaultAuthenticationPlugin)
+ [maxdbFlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [reservedKeywordsCheck](#reservedKeywordsCheck)
+ [utf8mb3Check](#utf8mb3Check)
+ [zeroDatesCheck](#zeroDatesCheck)
**defaultAuthenticationPlugin**
**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\$1sha2\$1password Compatibility Issues and Solutions](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues) 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"
},
```
**maxdbFlagCheck**
**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\$1mode](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode) foram [removidas](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html), 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.
De acordo com a [documentação do MySQL](https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html), o MySQL armazena a configuração `sql_mode` em vigor quando uma rotina é criada ou alterada. Ele sempre executa a rotina com essa configuração, independentemente da configuração `sql_mode` quando a rotina é iniciada.
Antes de alterar `sql_mode`, consulte [Server SQL Modes](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html) na documentação do MySQL. Avalie cuidadosamente qualquer possível impacto de fazer isso na aplicação.
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": []
}
```
**mysqlDollarSignNameCheck**
**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](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-32.html#mysqld-8-0-32-deprecation-removal), 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](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html), 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.
**reservedKeywordsCheck**
**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](#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](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html) 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';
```
**utf8mb3Check**
**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](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html) e [utf8mb4](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html) em [Converting Between 3-Byte and 4-Byte Unicode Character Sets](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) 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](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) na documentação do MySQL.
**zeroDatesCheck**
**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"
}
]
}
```
### Pré-verificações do Aurora MySQL que exibem avisos
As pré-verificações a seguir são específicas do Aurora MySQL:
+ [auroraUpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [auroraUpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
**auroraUpgradeCheckForRollbackSegmentHistoryLength**
**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](#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](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown). 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](proactive-insights.history-list.md).
**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](proactive-insights.history-list.md) 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.
**auroraUpgradeCheckForUncommittedRowModifications**
**Nível de pré-verificação: aviso**
**Verifica se há muitas modificações de linha não confirmadas**
Como mencionado em [auroraUpgradeCheckForIncompleteXATransactions](#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](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown). 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\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html). 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](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) na documentação do MySQL.
## Avisos
A pré-verificação a seguir gera um aviso quando a pré-visualização falha e a atualização pode continuar.
**sqlModeFlagCheck**
**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](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html): `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](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html).
**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](#maxdbFlagCheck).
## Erros, avisos ou alertas
A pré-verificação a seguir pode exibir um erro, aviso ou alerta, dependendo da saída da pré-verificação.
**checkTableOutput**
**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](#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:
+ Verificar se os metadados e a estrutura da tabela são compatíveis com a versão de destino do MySQL
+ Verificar se há algum recurso obsoleto ou removido usado pela tabela
+ Garantir que a atualização da tabela seja feito adequadamente sem perda de dados
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](https://dev.mysql.com/doc/refman/5.7/en/check-table.html) 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](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html) 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\$1key\$1checks](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html#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](https://dev.mysql.com/doc/refman/5.7/en/check-table.html#check-table-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": []
},
```
# Como realizar uma atualização local
Recomendamos revisar o material de base em [Como funciona a atualização da versão principal no local Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence).
Execute qualquer planejamento e teste de pré-atualização, conforme descrito em [Planejando uma atualização de versão principal para um cluster de Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning).
## Console
O exemplo a seguir atualiza o cluster de banco de dados `mydbcluster-cluster` para o Aurora MySQL versão 3.04.1.
**Para atualizar a versão principal de um cluster de bancos de dados Aurora MySQL**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Se você usou um grupo de parâmetros personalizado com o cluster de banco de dados original, crie um grupo de parâmetros correspondente compatível com a nova versão principal. Faça todos os ajustes necessários aos parâmetros de configuração nesse novo grupo de parâmetro. Para ter mais informações, consulte [Como as atualizações locais afetam os grupos de parâmetros de um cluster](#AuroraMySQL.Upgrading.ParamGroups).
1. No painel de navegação, escolha **Databases (Bancos de dados)**.
1. Na lista, escolha o cluster de banco de dados que deseja modificar.
1. Selecione **Modify**.
1. Em **Version** (Versão), selecione uma versão principal do Aurora MySQL.
Recomendamos usar a versão secundária mais recente da versão principal. Aqui, escolhemos a versão padrão atual.
![\[Atualização no local de um cluster de banco de dados do Aurora MySQL da versão 2 para a versão 3\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. Escolha **Continue**.
1. Na próxima página, especifique quando executar a atualização. Escolha **During the next scheduled maintenance window (Durante a próxima janela de manutenção programada)** ou **Immediately (Imediatamente)**.
1. (Opcional) Examine periodicamente a página **Events (Eventos)** no console do RDS durante a atualização. Isso ajuda você a monitorar o progresso da atualização e identificar quaisquer problemas. Se a atualização encontrar quaisquer problemas, consulte [Solução de problemas para atualização no local de Aurora MySQL](AuroraMySQL.Upgrading.Troubleshooting.md) para as etapas a serem realizadas.
1. Se você criou um grupo de parâmetros no início deste procedimento, associe o grupo de parâmetros personalizado ao cluster atualizado. Para ter mais informações, consulte [Como as atualizações locais afetam os grupos de parâmetros de um cluster](#AuroraMySQL.Upgrading.ParamGroups).
**nota**
A execução desta etapa exige que você reinicie o cluster novamente para aplicar o novo grupo de parâmetro.
1. (Opcional) Depois de concluir qualquer teste pós-atualização, exclua o snapshot manual que Aurora criado no início da atualização.
## AWS CLI
Para atualizar a versão principal de um cluster de bancos de dados Aurora MySQL, use o comando da AWS CLI [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) com os seguintes parâmetros obrigatórios:
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` ou `--no-apply-immediately`
Se o cluster usar quaisquer grupos de parâmetros personalizados, inclua também uma ou ambas as opções a seguir:
+ `--db-cluster-parameter-group-name`, se o cluster usar um grupo de parâmetros de cluster personalizado
+ `--db-instance-parameter-group-name`, se alguma instância no cluster usar um grupo de parâmetro de banco de dados personalizado
O exemplo a seguir atualiza o cluster de banco de dados `sample-cluster` para o Aurora MySQL versão 3.04.1. A atualização acontece imediatamente, em vez de aguardar a próxima janela de manutenção.
**Example**
Para Linux, macOS ou Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 8.0.mysql_aurora.3.04.1 \
--allow-major-version-upgrade \
--apply-immediately
```
Para Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 8.0.mysql_aurora.3.04.1 ^
--allow-major-version-upgrade ^
--apply-immediately
```
Você pode combinar outros comandos CLI com `modify-db-cluster` para criar um processo completo automatizado para executar e verificar atualizações. Para ter mais informações e exemplos, consulte [Tutorial de atualização no local de Aurora MySQL](AuroraMySQL.Upgrading.Tutorial.md).
**nota**
Se o cluster fizer parte de um banco de dados Aurora global, o procedimento de atualização local será ligeiramente diferente. Você chama a operação de comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) em vez de `modify-db-cluster`. Para ter mais informações, consulte [Principais atualizações no local para bancos de dados globais](#AuroraMySQL.Upgrading.GlobalDB).
## API do RDS
Para atualizar a versão principal de um cluster de banco de dados do Aurora MySQL, use a operação [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) da API do RDS com os seguintes parâmetros necessários:
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately` (definido como `true` ou `false`)
**nota**
Se o cluster fizer parte de um banco de dados Aurora global, o procedimento de atualização local será ligeiramente diferente. Você chama a operação [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html) em vez de `ModifyDBCluster`. Para ter mais informações, consulte [Principais atualizações no local para bancos de dados globais](#AuroraMySQL.Upgrading.GlobalDB).
## Como as atualizações locais afetam os grupos de parâmetros de um cluster
Os grupos de parâmetros do Aurora têm diferentes conjuntos de configurações para clusters que são compatíveis com MySQL 5.7 ou 8.0. Quando você realiza uma atualização no local, o cluster atualizado e todas as instâncias devem usar grupos de parâmetros de instância e cluster correspondentes:
Seu cluster e suas instâncias podem usar os grupos de parâmetros padrão compatíveis com 5.7. Em caso afirmativo, o cluster atualizado e a instância iniciarão com os grupos de parâmetros padrão compatíveis com 8.0. Se o cluster e as instâncias usarem quaisquer grupos de parâmetros personalizados, crie grupos de parâmetros correspondentes ou compatíveis com 8.0. Além disso, especifique-os durante o processo de atualização.
**nota**
Para a maioria das configurações de parâmetros, é possível selecionar o grupo de parâmetros personalizado em dois pontos. É quando você cria o cluster ou associa o grupo de parâmetros ao cluster mais tarde.
No entanto, se você utilizar uma configuração não padrão para o parâmetro `lower_case_table_names`, deverá configurar o grupo de parâmetros personalizado com essa configuração com antecedência. Em seguida, especifique o grupo de parâmetros ao realizar a restauração do snapshot para criar o cluster. Qualquer alteração no parâmetro `lower_case_table_names` não terá efeito após a criação do cluster.
Recomendamos que você use a mesma configuração para `lower_case_table_names` ao atualizar do Aurora MySQL versão 2 para a versão 3.
Com um banco de dados Aurora global baseado no Aurora MySQL, você não poderá executar uma atualização no local do Aurora MySQL versão 2 para a versão 3 se o parâmetro `lower_case_table_names` estiver ativado. Para ter mais informações sobre os métodos que você pode usar, consulte [Atualizações de versão principal](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major).
**Importante**
Se você especificar qualquer grupo de parâmetros personalizado durante o processo de atualização, será necessário reinicializar manualmente o cluster após a conclusão da atualização. Isso faz com que o cluster comece a usar suas configurações de parâmetros personalizadas.
## Alterações nas propriedades do cluster entre as versões do Aurora MySQL
Ao realizar o upgrade do Aurora MySQL versão 2 para a versão 3, verifique todas as aplicações ou scripts utilizados para configurar ou gerenciar clusters e instâncias de banco de dados do Aurora MySQL.
Além disso, altere seu código que manipula grupos de parâmetros para explicar o fato de que os nomes dos grupos de parâmetros padrão são diferentes para os clusters compatíveis com as versões 5.7 e 8.0. Os nomes dos grupos de parâmetros padrão para clusters do Aurora MySQL versão 2 e 3 são `default.aurora-mysql5.7` e `default.aurora-mysql8.0`, respectivamente.
Por exemplo, você pode ter um código como abaixo que se aplica ao cluster antes de uma atualização.
```
# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1
```
Depois de atualizar a versão principal do cluster, altere esse código da seguinte forma.
```
# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1
```
## Principais atualizações no local para bancos de dados globais
Para um Aurora Global Database, você atualiza o cluster de banco de dados global. O Aurora atualiza automaticamente todos os clusters ao mesmo tempo e garante que todos eles executem a mesma versão do mecanismo. Esse requisito ocorre porque todas as alterações nas tabelas do sistema, formatos de arquivo de dados e outros são replicadas automaticamente para todos os clusters secundários.
Siga as instruções em [Como funciona a atualização da versão principal no local Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence). Quando você especificar o que deve ser atualizado, escolha o cluster de banco de dados global em vez de um dos clusters que ele contém.
Se você usar o Console de gerenciamento da AWS, escolha o item com a função **Global database** (Banco de dados global).
![\[Atualizar o cluster de banco de dados global\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
Se você usar a AWS CLI ou a API do RDS, inicie o processo de atualização chamando o comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) ou a operação [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html). Você usa um desses em vez de `modify-db-cluster` ou `ModifyDBCluster`.
**nota**
Você não pode especificar um grupo de parâmetros personalizado para o cluster de banco de dados global enquanto estiver realizando uma atualização de versão principal desse banco de dados global do Aurora. Crie seus grupos de parâmetros personalizados em cada região do cluster global. Depois, aplique-os manualmente aos clusters regionais após a atualização.
Para atualizar a versão principal de um cluster de bancos de dados do Aurora MySQL, use o comando [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) da AWS CLI com os seguintes parâmetros obrigatórios:
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
O exemplo a seguir atualiza o cluster de banco de dados global para a Aurora MySQL versão 2.10.2.
**Example**
Para Linux, macOS ou Unix:
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine aurora-mysql \
--engine-version 5.7.mysql_aurora.2.10.2 \
--allow-major-version-upgrade
```
Para Windows:
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine aurora-mysql ^
--engine-version 5.7.mysql_aurora.2.10.2 ^
--allow-major-version-upgrade
```
## Considerações sobre retrocesso
Se o cluster que você atualizou tiver o recurso de retrocesso ativado, você não poderá retroceder o cluster atualizado para antes da atualização.
# Tutorial de atualização no local de Aurora MySQL
Os exemplos do Linux a seguir mostram como você pode executar as etapas gerais do procedimento de atualização no local usando AWS CLI.
Este primeiro exemplo cria um cluster de banco de dados do Aurora que está executando uma versão 2.x do Aurora MySQL. O cluster inclui uma instância de banco de dados de gravador e uma instância de banco de dados de leitor. O comando `wait db-instance-available` pausa até que a instância de banco de dados do gravador esteja disponível. Esse é o ponto em que o cluster está pronto para ser atualizado.
```
aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
--db-cluster-version 5.7.mysql_aurora.2.11.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
--db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
As versões 3.x do Aurora MySQL para as quais é possível fazer upgrade do cluster dependem da versão 2.x em que o cluster está sendo executado no momento e da Região da AWS em que o cluster está localizado. O primeiro comando com `--output text` apenas mostra a versão de destino disponível. O segundo comando mostra a saída JSON completa da resposta. Nessa resposta, você pode ver detalhes, como o valor `aurora-mysql` que você usa para o parâmetro `engine`. Você também pode ver o fato de que fazer upgrade para a versão 3.04.0 representa um upgrade de versão principal.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.2 \
--query '*[].[ValidUpgradeTarget]'
...
{
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.04.0",
"Description": "Aurora MySQL 3.04.0 (compatible with MySQL 8.0.28)",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": true,
"SupportedEngineModes": [
"provisioned"
],
"SupportsParallelQuery": true,
"SupportsGlobalDatabases": true,
"SupportsBabelfish": false,
"SupportsIntegrations": false
},
...
```
Este exemplo mostra que, se você inserir um número de versão de destino que não seja um destino de atualização válido para o cluster, o Aurora não realizará a atualização. O Aurora também não realiza uma atualização de versão principal, a menos que você inclua o parâmetro `--allow-major-version-upgrade`. Dessa forma, você não pode executar acidentalmente uma atualização que precise exigir testes e alterações amplas no código do aplicativo.
```
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.11.2 with requested version 5.7.mysql_aurora.2.09.2.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --apply-immediately --allow-major-version-upgrade
{
"DBClusterIdentifier": "mynewdbcluster",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2"
}
```
Demora alguns momentos para que o status do cluster e das instâncias de banco de dados associadas mudem para `upgrading`. Os números de versão para as instâncias de cluster e banco de dados só mudam quando a atualização for concluída. Novamente, você pode usar o comando `wait db-instance-available` para que a instância de banco de dados do gravador aguarde até que a atualização seja concluída antes de prosseguir.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.11.2
aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
--query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
"DBInstanceIdentifier": "mynewdbcluster-instance1",
"DBInstanceStatus": "upgrading"
}
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
Neste ponto, o número da versão para o cluster corresponde ao que foi especificado para a atualização.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.04.0
```
O exemplo anterior fez uma atualização imediata especificando o parâmetro `--apply-immediately`. Para que a atualização aconteça em um momento conveniente quando o cluster não estiver ocupado, você pode especificar o parâmetro `--no-apply-immediately`. Isso faz com que a atualização inicie durante a próxima janela de manutenção para o cluster. A janela de manutenção define o período durante o qual as operações de manutenção podem ser iniciadas. Uma operação de longa duração pode não ser concluída durante a janela de manutenção. Assim, você não precisa definir uma janela de manutenção maior mesmo se esperar que a atualização possa levar muito tempo.
O exemplo a seguir faz upgrade de um cluster que está executando inicialmente o Aurora MySQL versão 2.11.2. Na saída `describe-db-engine-versions`, os valores `False` e `True` representam a propriedade `IsMajorVersionUpgrade`. A partir da versão 2.11.2, é possível fazer upgrade para algumas outras versões 2.\$1. Essas atualizações não são consideradas atualizações de versão principais e, portanto, não exigem uma atualização no local. O upgrade no local só está disponível para upgrades para as versões 3.\$1 que são mostradas na lista.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
--query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text
5.7.mysql_aurora.2.11.3 False
5.7.mysql_aurora.2.11.4 False
5.7.mysql_aurora.2.11.5 False
5.7.mysql_aurora.2.11.6 False
5.7.mysql_aurora.2.12.0 False
5.7.mysql_aurora.2.12.1 False
5.7.mysql_aurora.2.12.2 False
5.7.mysql_aurora.2.12.3 False
8.0.mysql_aurora.3.04.0 True
8.0.mysql_aurora.3.04.1 True
8.0.mysql_aurora.3.04.2 True
8.0.mysql_aurora.3.04.3 True
8.0.mysql_aurora.3.05.2 True
8.0.mysql_aurora.3.06.0 True
8.0.mysql_aurora.3.06.1 True
8.0.mysql_aurora.3.07.1 True
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --no-apply-immediately --allow-major-version-upgrade
...
```
Quando um cluster é criado sem uma janela de manutenção especificada, Aurora seleciona um dia aleatório da semana. Nesse caso, o comando `modify-db-cluster` é enviado em uma segunda-feira. Assim, mudamos a janela de manutenção para terça-feira de manhã. Todos os horários são representados no fuso horário UTC. A janela `tue:10:00-tue:10:30` corresponde ao intervalo das 2h às 2h30 no horário do Pacífico. A alteração na janela de manutenção entra em vigor imediatamente.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"sat:08:20-sat:08:50"
]
]
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"tue:10:00-tue:10:30"
]
]
```
O exemplo a seguir mostra como obter um relatório dos eventos gerados pela atualização. O argumento `--duration` representa o número de minutos para recuperar as informações do evento. Ele é necessário porque, por padrão, `describe-events` só exibe eventos da última hora.
```
aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
"Events": [
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "DB cluster created",
"EventCategories": [
"creation"
],
"Date": "2022-11-17T01:24:11.093000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing online pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:08.450000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:59.519000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:00:22.318000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Cloning volume.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:01:45.428000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:02:25.141000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:23.036000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Upgrading database objects.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:48.208000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster major version has been upgraded",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:10:28.999000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
}
]
}
```
# Descobrir os motivos das falhas de atualização da versão principal do Aurora MySQL
No [tutorial](AuroraMySQL.Upgrading.Tutorial.md), a atualização do Aurora MySQL versão 2 para a versão 3 foi bem-sucedida. Mas, se a atualização tivesse falhado, seria útil saber o motivo.
É possível começar usando o comando `describe-events` da AWS CLI para examinar os eventos do cluster de banco de dados. Este exemplo mostra os eventos de `mydbcluster` nas últimas dez horas.
```
aws rds describe-events \
--source-type db-cluster \
--source-identifier mydbcluster \
--duration 600
```
Nesse caso, tivemos uma falha na pré-verificação da atualização.
```
{
"Events": [
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster engine version upgrade started.",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:22.846000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
},
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the
upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:24.373000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
}
]
}
```
Para diagnosticar a causa exata do problema, examine os logs do banco de dados para a instância de banco de dados de gravador. Quando uma atualização para o Aurora MySQL versão 3 falha, a instância de gravador contém um arquivo de log com o nome do arquivo `upgrade-prechecks.log`. Este exemplo mostra como detectar a presença desse log e, em seguida, baixá-lo para um arquivo local para exame.
```
aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
--query '*[].[LogFileName]' --output text
error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log
aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
--log-file-name upgrade-prechecks.log \
--starting-token 0 \
--output text >upgrade_prechecks.log
```
O arquivo `upgrade-prechecks.log` está no formato JSON. Nós o baixamos usando a opção `--output text` para evitar codificar a saída JSON em outro wrapper JSON. Para atualizações do Aurora MySQL versão 3, esse log sempre inclui determinadas mensagens informativas e de aviso. Ele só inclui mensagens de erro se a atualização falhar. Se a atualização for bem-sucedida, o arquivo de log não será produzido.
Para resumir todos esses erros e exibir os campos de objeto e descrição associados, é possível executar o comando `grep -A 2 '"level": "Error"'` no conteúdo do arquivo `upgrade-prechecks.log`. Isso exibe cada linha de erro e as duas linhas depois dela. Elas contêm o nome do objeto de banco de dados correspondente e orientações sobre como corrigir o problema.
```
$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'
"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
```
Neste exemplo, é possível executar o comando SQL a seguir na tabela com problemas para tentar corrigi-los ou recriar a tabela sem o índice pendente.
```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```
Tente realizar a atualização novamente.
# Solução de problemas para atualização no local de Aurora MySQL
Use as dicas a seguir para ajudar a solucionar problemas com as atualizações no local do Aurora MySQL. Estas dicas não se aplicam a clusters de banco de dados do Aurora Serverless.
| Motivo para a atualização no local ser cancelada ou lenta | Efeito | Solução para permitir que a atualização no local seja concluída dentro da janela de manutenção |
| --- | --- | --- |
| A réplica associada entre regiões do Aurora ainda não foi corrigida | Aurora cancela a atualização. | Atualize a réplica entre regiões do Aurora e tente novamente. |
| Cluster tem transações XA no estado preparado | Aurora cancela a atualização. | Confirmar ou reverter todas as transações XA preparadas. |
| O cluster está processando qualquer instrução DDL (Data Definition Language) | Aurora cancela a atualização. | Considere esperar e executar a atualização depois que todas as instruções DDL estiverem concluídas. |
| Cluster tem alterações não confirmadas para muitas linhas | A atualização pode levar muito tempo. | O processo de atualização reverte as alterações não confirmadas. O indicador para esta condição é o valor de `TRX_ROWS_MODIFIED` na tabela `INFORMATION_SCHEMA.INNODB_TRX`. Considere executar a atualização somente depois que todas as grandes transações forem confirmadas ou revertidas. |
| Cluster tem um número elevado de registros para desfazer | A atualização pode levar muito tempo. | Mesmo que as transações não confirmadas não afetem um grande número de linhas, podem envolver um grande volume de dados. Por exemplo, você pode inserir BLOBs grandes. O Aurora não detecta nem gera automaticamente um evento para esse tipo de atividade de transação. O indicador para essa condição é o tamanho da lista de histórico (HLL). O processo de atualização reverte as alterações não confirmadas. É possível conferir o HLL na saída do comando `SHOW ENGINE INNODB STATUS` SQL ou diretamente usando a seguinte consulta SQL: SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
Também é possível monitorar a métrica `RollbackSegmentHistoryListLength` no Amazon CloudWatch. Pense em realizar a atualização somente quando o HLL for menor. |
| O cluster está no processo de confirmação de uma grande transação de log binário | A atualização pode levar muito tempo. | O processo de atualização aguarda até que as alterações de log binário sejam aplicadas. Mais transações ou instruções DDL podem começar durante esse período, retardando ainda mais o processo de atualização. Agende o processo de atualização quando o cluster não estiver ocupado gerando alterações de replicação de log binário. O Aurora não detecta nem gera automaticamente um evento para esta condição. |
| Inconsistências em esquemas resultantes da remoção ou corrupção de arquivos | Aurora cancela a atualização. | Altere o mecanismo de armazenamento padrão para tabelas temporárias do MyISAM para o InnoDB. Siga estas etapas: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| O usuário mestre foi excluído. | Aurora cancela a atualização. | Não exclua o usuário mestre. No entanto, se por algum motivo você excluir o usuário mestre, restaure-o usando os seguintes comandos SQL: CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES,
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT,
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;
|
Para ver mais detalhes sobre a solução de problemas que fazem com que as verificações prévias de atualização falhem, consulte os seguintes blogs:
+ [Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 1](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-1/)
+ [Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 2](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/)
Você pode usar as etapas a seguir para executar suas próprias verificações para algumas das condições na tabela anterior. Dessa forma, você pode agendar a atualização em um momento em que você sabe que o banco de dados está em um estado onde a atualização pode ser concluída com sucesso e rapidamente.
+ Você pode verificar se há transações XA abertas executando a instrução `XA RECOVER`. Você pode então confirmar ou reverter as transações XA antes de iniciar a atualização.
+ Você pode verificar se há instruções DDL executando uma instrução `SHOW PROCESSLIST` e procurando `CREATE`, `DROP`, `ALTER`, `RENAME` e `TRUNCATE` na saída. Permita que todas as instruções DDL terminem antes de iniciar a atualização.
+ Você pode verificar o número total de linhas não confirmadas consultando a tabela `INFORMATION_SCHEMA.INNODB_TRX`. A tabela contém uma linha para cada transação. A coluna `TRX_ROWS_MODIFIED` contém o número de linhas modificadas ou inseridas pela transação.
+ Você pode verificar o comprimento da lista de histórico do InnoDB executando a instrução `SHOW ENGINE INNODB STATUS SQL` e procurando o `History list length` na saída. Você também pode verificar o valor diretamente executando a seguinte consulta:
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
O comprimento da lista de histórico corresponde à quantidade de informações desfeitas armazenadas pelo banco de dados para implementar o controle de simultaneidade de várias versões (MVCC).
# Limpeza pós-upgrade do Aurora MySQL versão 3
Depois de concluir o upgrade de qualquer cluster do Aurora MySQL versão 2 para o Aurora MySQL versão 3, você poderá executar essas outras ações de limpeza:
+ Crie novas versões compatíveis com o MySQL 8.0 de qualquer grupo de parâmetros personalizado. Aplique todos os valores de parâmetros personalizados necessários aos novos grupos de parâmetros.
+ Atualize todos os alarmes do CloudWatch, scripts de configuração e assim por diante para utilizar os novos nomes de qualquer métrica cujos nomes tenham sido afetados por alterações inclusivas de idioma. Para obter uma lista dessas métricas, consulte [Alterações de linguagem inclusiva do Aurora MySQL versão 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
+ Atualize qualquer template do CloudFormation para utilizar os novos nomes para quaisquer parâmetros de configuração cujos nomes tenham sido afetados por alterações inclusivas de linguagem. Para obter uma lista completa desses parâmetros, consulte [Alterações de linguagem inclusiva do Aurora MySQL versão 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
## Índices espaciais
Depois de atualizar para o Aurora MySQL versão 3, verifique se você precisa descartar ou recriar objetos e índices relacionados a índices espaciais. Antes do MySQL 8.0, o Aurora podia otimizar consultas espaciais utilizando índices que não continham um identificador de recursos espaciais (SRID). O Aurora MySQL versão 3 utiliza apenas índices espaciais contendo SRIDs. Durante um upgrade, o Aurora descarta automaticamente todos os índices espaciais sem SRIDs e imprime mensagens de aviso no log do banco de dados. Se você observar essas mensagens de aviso, crie novos índices espaciais com SRIDs após o upgrade. Para obter mais informações sobre alterações em funções espaciais e tipos de dados no MySQL 8.0, consulte o tópico sobre [Alterações feitas no MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html), no *Guia de referência do MySQL*.