' for the table to apply all the pending DDL updates. Then try the upgrade again."
}
]
}
```
预检查报告表 `test.test` 具有待处理的快速 DDL 操作。
要让升级继续进行，可以重建表，然后重试升级。
在重建表空间之前，请参阅 MySQL 文档中的 [Online DDL operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html)，来了解锁定和数据移动对前台事务的影响。
```
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)
```
重建表后，预检查成功。
```
{
"id": "auroraFODUpgradeCheck",
"title": "Check for artifacts related to Aurora fast DDL feature",
"status": "OK",
"detectedProblems": []
}
```
**auroraGetDanglingFulltextIndex**
**预检查级别：错误**
**带有悬挂的 `FULLTEXT` 索引引用的表**
在 MySQL 5.6.26 之前，删除全文搜索索引后，隐藏的 `FTS_DOC_ID` 和 `FTS_DOC_ID_INDEX` 列可能会变成孤立的列。有关更多信息，请参阅 [Bug \$176012](https://bugs.mysql.com/bug.php?id=76012)。
如果您在早期版本的 MySQL 上创建了任何出现这种情况的表，则可能会导致升级到 Aurora MySQL 版本 3 失败。此项预检查可验证在升级到 MySQL 8.0 之前，数据库集群上不存在此类孤立或“悬挂”的全文索引。如果此项预检查失败，请重建任何包含此类悬挂全文索引的表。
**输出示例：**
```
{
"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."
}
]
},
```
预检查报告 `test.table_with_fts_index` 表存在错误，因为它包含悬挂的全文索引。要让升级继续进行，请重建表来清理全文索引辅助表。使用 `OPTIMIZE TABLE test.table_with_fts_index` 或者 `ALTER TABLE test.table_with_fts_index, ENGINE=INNODB`。
重建表后，预检查通过。
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForDatafilePathInconsistency**
**预检查级别：错误**
**检查与 `ibd` 文件路径相关的不一致性**
此项预检查仅适用于 Aurora MySQL 版本 3.03.0 及更低版本。如果您在此项预检查中遇到错误，请升级到 Aurora MySQL 版本 3.04 或更高版本。
**输出示例：**
```
{
"id": "auroraUpgradeCheckForDatafilePathInconsistency",
"title": "Check for inconsistency related to ibd file path.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForFtsSpaceIdZero**
**预检查级别：错误**
**检查是否有空间 ID 为零的全文索引**
在 MySQL 中，当您向 InnoDB 表添加 [full-text index](https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html) 时，会创建许多辅助索引表空间。由于 MySQL 的早期版本中存在一个 [bug](https://bugs.mysql.com/bug.php?id=72132)（在 5.6.20 版本中已修复），这些辅助索引表可能是在 [system tablespace](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace) 中创建的，而不是在它们自己的 InnoDB 表空间中创建的。
如果存在任何此类辅助表空间，则升级将失败。重新创建在预检查错误中提到的全文索引，然后重试升级。
**输出示例：**
```
{
"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."
}
]
},
```
预检查报告 `test.fts_space_zero_check` 表的一个错误，因为该表在系统表空间中有辅助全文搜索（FTS）表。
删除并重新创建与此表关联的 FTS 索引后，预检查成功。
在重建表空间之前，请参阅 MySQL 文档中的 [Partitioning operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning)，来了解锁定和数据移动对前台事务的影响。
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForIncompleteXATransactions**
**预检查级别：错误**
**检查 XA 事务是否处于已准备状态**
在运行主要版本升级过程时，务必对 Aurora MySQL 版本 2 数据库实例执行 [clean shutdown](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)。这可以确保所有事务都已提交或回滚，并且 InnoDB 已清除所有撤消日志记录。由于事务回滚是必需的，因此，如果数据库中有任何 [XA transactions](https://dev.mysql.com/doc/refman/5.7/en/xa.html) 处于已准备状态，则可能会阻止继续进行干净关闭。因此，如果检测到任何已准备的 XA 事务，则在您采取措施来提交或回滚这些事务之前，升级将无法继续。
有关使用 `XA RECOVER` 查找处于已准备状态的 XA 事务的更多信息，请参阅 MySQL 文档中的 [XA transaction SQL statements](https://dev.mysql.com/doc/refman/5.7/en/xa-statements.html)。有关 XA 事务状态的更多信息，请参阅 MySQL 文档中的 [XA transaction states](https://dev.mysql.com/doc/refman/5.7/en/xa-states.html)。
**输出示例：**
```
{
"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."
}
]
}
```
此项预检查报告一个错误，因为有处于已准备状态的事务应提交或回滚。
登录数据库后，可以检查 [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) 表和 `XA RECOVER` 输出来获取更多信息。
在提交或回滚事务之前，建议您查看 [MySQL documentation](https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html) 和您的应用程序要求。
```
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)
```
在这种情况下，我们会回滚已准备的事务。
```
mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)
```
XA 事务回滚后，预检查成功。
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInstanceLimit**
**预检查级别：错误**
**检查当前实例类是否支持升级**
目前不支持从 Aurora MySQL 版本 2.12.0 或 2.12.1（其中写入器[数据库实例类](Concepts.DBInstanceClass.md)为 db.r6i.32xlarge）运行就地升级。在这种情况下，预检查会返回错误。要让升级继续进行，可以将数据库实例类更改为 db.r6i.24xlarge 或更小。或者，可以升级到 Aurora MySQL 版本 2.12.2 或更高版本，其中 db.r6i.32xlarge 支持就地升级到 Aurora MySQL 版本 3。
**输出示例：**
```
{
"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."
}
]
},
```
预检查会返回错误，因为写入器数据库实例使用的是 db.r6i.32xlarge 实例类，并且在 Aurora MySQL 版本 2.12.1 上运行。
**auroraUpgradeCheckForInternalUsers**
**预检查级别：错误**
**检查是否有 8.0 内部用户**
此项预检查仅适用于 Aurora MySQL 版本 3.03.0 及更低版本。如果您在此项预检查中遇到错误，请升级到 Aurora MySQL 版本 3.04 或更高版本。
**输出示例：**
```
{
"id": "auroraUpgradeCheckForInternalUsers",
"title": "Check for 8.0 internal users.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForMasterUser**
**预检查级别：错误**
**检查 RDS 主用户是否存在**
MySQL 8 添加了支持 [role](https://dev.mysql.com/doc/refman/8.0/en/roles.html) 和 [dynamic privileges](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges) 的新权限模型，使权限管理变得更简单、更精细。作为此次变更的一部分，Aurora MySQL 引入了新的 `rds_superuser_role`，从 Aurora MySQL 版本 2 升级到版本 3 时，会自动向数据库的主用户授予此角色。
有关 Aurora MySQL 中分配给主用户的角色和权限的更多信息，请参阅[主用户账户权限](UsingWithRDS.MasterAccounts.md)。有关 Aurora MySQL 版本 3 中基于角色的权限模型的更多信息，请参阅[基于角色的权限模型](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)。
此项预检查验证数据库中是否存在主用户。如果主用户不存在，则预检查失败。要让升级继续进行，请通过重置主用户密码或手动创建用户来重新创建主用户。然后重试升级。有关重置主用户密码的更多信息，请参阅[更改数据库主用户的密码](Aurora.Modifying.md#Aurora.Modifying.Password)。
**输出示例：**
```
{
"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 '%'"
}
]
}
```
重置主用户密码后，预检查将通过，可以重试升级。
以下示例使用 Amazon CLI 来重置密码。密码更改会立即应用。
```
aws rds modify-db-cluster \
--db-cluster-identifier my-db-cluster \
--master-user-password my-new-password
```
然后，预检查成功。
```
{
"id": "auroraUpgradeCheckForMasterUser",
title": "Check if master user exists",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForPrefixIndexOnGeometryColumns**
**预检查级别：错误**
**检查前缀索引上是否有几何列**
从 [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) 开始，无法再使用 [GEOMETRY](https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html) 数据类型在列上创建 [prefixed](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) 索引。有关更多信息，请参阅 [WL\$111808](https://dev.mysql.com/worklog/task/?id=11808)。
如果存在任何此类索引，则升级将失败。要解决此问题，请删除预检查失败中提及的表上的带前缀 `GEOMETRY` 索引。
**输出示例：**
```
{
"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`;"
}
]
}
```
预检查会报告错误，因为 `test.geom_index_prefix` 表中包含的索引在 `GEOMETRY` 列上带有前缀。
删除此索引后，预检查成功。
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForSpecialCharactersInProcedures**
**预检查级别：错误**
**检查存储过程中是否存在与特殊字符相关的不一致性**
在 MySQL 8.0 之前，数据库名称、表名称和其它对象对应于数据目录中的文件，即基于文件的元数据。作为升级到 MySQL 8.0 的一部分，所有数据库对象都迁移到存储在 `mysql` 架构中的新的内部数据字典表中，以支持新实现的 [Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html)。作为迁移存储过程的一部分，在将每个过程的过程定义和主体摄取到新的数据字典中时，都会对其进行验证。
在 MySQL 8 之前，在某些情况下，可以创建存储例程，或将包含特殊字符的过程直接插入 `mysql.proc` 表中。例如，可以创建一个存储过程，其中包含带有不合规、[不换行空格字符](https://en.wikipedia.org/wiki/Non-breaking_space) `\xa0` 的注释。如果遇到任何此类过程，则升级失败。
此项预检查可验证存储过程的主体和定义中是否不包含任何此类字符。要让升级继续进行，请重新创建这些存储过程，而不包含任何隐藏或特殊字符。
**输出示例：**
```
{
"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."
}
]
}
```
预检查报告数据库集群在 `test` 数据库包含一个名为 `get_version_proc` 的过程，该过程在过程主体中包含特殊字符。
删除并重新创建该存储过程后，预检查成功，并支持升级继续进行。
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForSysSchemaObjectTypeMismatch**
**预检查级别：错误**
**检查 `sys` 架构的对象类型不匹配**
[sys schema](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html) 是 MySQL 数据库中的一组对象和视图，有助于用户对其数据库实例进行故障排除、优化和监控。当执行从 Aurora MySQL 版本 2 到版本 3 的主要版本升级时，将重新创建 `sys` 架构视图，并将其更新为新的 Aurora MySQL 版本 3 定义。
作为升级的一部分，如果 `sys` 架构中的任何对象是使用存储引擎（[INFORMATION\$1SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html) 中的 `sys_config/BASE TABLE`）而不是视图定义的，则升级将失败。这类表可以在 `information_schema.tables` 表中找到。这不是预期的行为，但在某些情况下可能是由于用户错误造成的。
此项预检查会验证所有 `sys` 架构对象，以确保它们使用正确的表定义，并且视图不会被错误地定义为 InnoDB 或 MyISAM 表。要解决此问题，请通过重命名或删除所有返回的对象来手动修复它们。然后重试升级。
**输出示例：**
```
{
"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). "
}
]
}
```
预检查报告 `sys` 架构中的 [sys.waits\$1global\$1by\$1latency](https://dev.mysql.com/doc/refman/5.7/en/sys-waits-global-by-latency.html) 视图具有类型不匹配，导致无法继续升级。
登录数据库实例后，可以看到此对象被定义为 InnoDB 表，而它应该是一个视图。
```
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)
```
要解决这个问题，可以删除该视图并使用 [correct definition](https://github.com/mysql/mysql-server/blob/mysql-5.7.44/scripts/sys_schema/views/p_s/waits_global_by_latency.sql) 重新创建该视图，也可以对其进行重命名。在升级过程中，将使用正确的表定义自动创建该视图。
```
mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)
```
完成此操作后，预检查通过。
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForViewColumnNameLength**
**预检查级别：错误**
**检查视图中列名称的上限**
MySQL 中的 [maximum permitted length of a column name](https://dev.mysql.com/doc/refman/5.7/en/identifier-length.html) 为 64 个字符。在 MySQL 8.0 之前，在某些情况下，可以创建列名称大于 64 个字符的视图。如果数据库实例上存在任何此类视图，则会返回预检查错误，升级将失败。要让升级继续进行，必须重新创建有问题的视图，确保其列长度小于 64 个字符。然后重试升级。
**输出示例：**
```
{
"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."
}
]
}
```
预检查报告 `test.colname_view_test` 视图包含的列 `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` 超过了支持的最大列长度 64 个字符。
通过查看视图定义，我们可以看到违规的列。
```
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)
```
要让升级继续进行，请重新创建该视图，确保列长度不超过 64 个字符。
```
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)
```
完成此操作后，预检查成功。
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckIndexLengthLimitOnTinyColumns**
**预检查级别：错误**
**检查是否有些表在微小列上定义了前缀长度大于 255 字节的索引**
在 MySQL 中使用 [binary data type](https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html) 对某个列创建索引时，必须在索引定义中添加 [prefix](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) 长度。在 MySQL 8.0 之前，在某些情况下，可以指定比此类数据类型支持的最大大小更大的前缀长度。例如 `TINYTEXT` 和 `TINYBLOB` 列，其中允许的最大数据大小为 255 字节，但允许使用大于此值的索引前缀。有关更多信息，请参阅 MySQL 文档中的 [InnoDB limits](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html)。
如果此项预检查失败，请删除违规索引，或将索引的 `TINYTEXT` 和 `TINYBLOB` 列的前缀长度减少到小于 255 字节。然后重试升级。
**输出示例：**
```
{
"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."
}
]
}
```
预检查报告表 `test.tintxt_prefixed_index` 存在错误，因为它的索引 `PRIMARY` 在 TINYTEXT 或 TINYBLOB 列上的前缀大于 255 字节。
查看此表的定义，可以看到主键在 `TINYTEXT` 列 `col1` 上的前缀为 65。由于表是使用 `utf8mb4` 字符集定义的，该字符集对于每个字符存储 4 个字节，因此前缀超过了 255 字节的限制。
```
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)
```
在使用 `utf8mb4` 字符集时将索引前缀修改为 63，可让升级继续进行。
```
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
```
完成此操作后，预检查成功。
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**预检查级别：错误**
**检查 `mysql.host` 表缺少的 InnoDB 元数据不一致性**
这是 RDS 服务执行的仅限内部的预检查。任何错误都将在升级时自动得以处理，可以安全地忽略。
如果您在此项预检查中遇到任何错误，请向 [Amazon Support](https://www.amazonaws.cn/support) 提交案例，来请求解决元数据不一致性。或者，可以通过执行逻辑转储，然后还原到新的 Aurora MySQL 版本 3 数据库集群来重试升级。
**auroraUpgradeCheckForInvalidUtf8mb3ColumnComments**
**预检查级别：错误**
**检查是否存在无效的 utf8mb3 列注释**
此项预检查识别出的表所包含的列注释具有无效的 utf8mb3 字符编码。在 MySQL 8.0 中，对元数据（包括列注释）中的字符编码应用了更严格的验证。如果任何列注释包含在 utf8mb3 字符集中无效的字符，则升级将失败。
此问题最常见的原因是列注释中存在非 BMP（基本多语言平面）字符。非 BMP 字符需要 4 字节的 UTF-8 编码（utf8mb4），但 utf8mb3 仅支持 3 字节序列，而无法表示这些字符。
要解决此问题，在尝试升级之前，必须修改列注释以移除或替换任何非 BMP 字符。您可以使用 `ALTER TABLE` 语句来更新列注释。
**输出示例：**
```
{
"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."
}
]
}
```
此项预检查报告 `test.t2` 表在一个或多个列注释中包含无效 utf8mb3 字符，特别是由于存在非 BMP 字符。
要解决此问题，您可以识别有问题的列并更新其注释。首先，检查表结构以识别带有注释的列：
```
mysql> SHOW CREATE TABLE test.t2\G
```
识别出带有问题注释的列后，使用 `ALTER TABLE` 语句对其进行更新。例如：
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';
```
或者，您可以完全移除注释：
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';
```
更新所有有问题的列注释后，预检查将通过，升级可以继续进行：
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
在修改列注释之前，请确保依赖于这些注释的任何应用程序代码或文档都已相应更新。如果应用程序需要非 BMP 字符，可以考虑迁移到 utf8mb4 字符集以获得更好的 Unicode 支持。
## 警告
以下预检查失败时会生成警告，但升级可以继续。
**Topics**
+ [
### 报告警告的 MySQL 预检查
](#precheck-descriptions-warnings.mysql)
+ [
### 报告警告的 Aurora MySQL 预检查
](#precheck-descriptions-warnings.aurora)
### 报告警告的 MySQL 预检查
以下预检查来自社区 MySQL：
+ [defaultAuthenticationPlugin](#defaultAuthenticationPlugin)
+ [maxdbFlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [reservedKeywordsCheck](#reservedKeywordsCheck)
+ [utf8mb3Check](#utf8mb3Check)
+ [zeroDatesCheck](#zeroDatesCheck)
**defaultAuthenticationPlugin**
**预检查级别：警告**
**新的默认身份验证插件注意事项**
在 MySQL 8.0 中，引入了 `caching_sha2_password` 身份验证插件，与已弃用的 `mysql_native_password` 插件相比，它提供了更安全的密码加密和更好的性能。对于 Aurora MySQL 版本 3，用于数据库用户的默认身份验证插件是 `mysql_native_password` 插件。
此项预检查警告称，在将来的主要版本中，此插件将被移除并会更改默认插件。请考虑在此项更改之前评估应用程序客户端和用户的兼容性。
有关更多信息，请参阅 MySQL 文档中的 [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)。
**输出示例：**
```
{
"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**
**预检查级别：警告**
**使用过时的 `MAXDB` `sql_mode` 标志**
在 MySQL 8.0 中，[removed](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) 了许多已弃用的 [sql\$1mode](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode) 系统变量选项，其中一个是 `MAXDB`。此项预检查会检查所有当前连接的会话，以及例程和触发器，来确保没有任何会话将 `sql_mode` 设置为任何包含 `MAXDB` 的组合。
**输出示例：**
```
{
"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"
}
]
}
```
预检查报告 `test.maxdb_stored_routine` 例程包含不受支持的 `sql_mode` 选项。
登录数据库后，可以在例程定义中看到 `sql_mode` 包含 `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)
```
要解决此问题，请在客户端上设置正确的 `sql_mode` 后重新创建该过程。
根据 [MySQL documentation](https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html)，MySQL 存储在创建或更改例程时生效的 `sql_mode` 设置。它始终使用此设置运行例程，而不管例程启动时 `sql_mode` 设置如何。
在更改 `sql_mode` 之前，请参阅 MySQL 文档中的 [Server SQL modes](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html)。仔细评估这样做对应用程序产生的任何潜在影响。
在不使用不受支持的 `sql_mode` 的情况下重新创建该过程。
```
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)
```
预检查成功。
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"detectedProblems": []
}
```
**mysqlDollarSignNameCheck**
**预检查级别：警告**
**检查对象名称中是否已弃用单美元符号**
从 [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) 开始，弃用将美元符号 (`$`) 作为未加引号的标识符的第一个字符。如果有任何以 `$` 为第一个字符的架构、表、视图、列或例程，则此项预检查会返回警告。虽然此警告不会阻止升级继续进行，但我们建议您尽快采取措施来解决此问题。从 [MySQL 8.4](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html) 开始，任何此类标识符都将返回语法错误而不是警告。
**输出示例：**
```
{
"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."
}
]
},
```
预检查会报告警告，因为 `test` 架构中的 `$deprecated_syntx` 表包含 `$` 作为第一个字符。
**reservedKeywordsCheck**
**预检查级别：警告**
**使用名称与新的保留关键字冲突的数据库对象**
此检查与 [routineSyntaxCheck](#routineSyntaxCheck) 类似，因为它会检查是否使用了名称与新的保留关键字冲突的数据库对象。虽然它们不会阻止升级，但您需要仔细评估警告。
**输出示例：**
将前面的示例用于名为 `except` 的表，预检查返回警告：
```
{
"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"
}
]
}
```
此警告让您了解可能需要查看一些应用程序查询。如果应用程序查询未正确地 [escaping string literals](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html)，则在升级到 MySQL 8.0 之后，这些查询可能会遇到错误。检查应用程序以进行确认，并针对在版本 3 上运行的 Aurora MySQL 数据库集群的克隆或快照进行测试。
升级后将失败的未转义的应用程序查询示例：
```
SELECT * FROM escape;
```
升级后将成功执行的经正确转义的应用程序查询示例：
```
SELECT * FROM 'escape';
```
**utf8mb3Check**
**预检查级别：警告**
**使用 `utf8mb3` 字符集**
在 MySQL 8.0 中，`utf8mb3` 字符集已弃用，并会在将来的 MySQL 主要版本中移除。实现此项预检查是为了在检测到任何使用此字符集的数据库对象时发出警告。虽然这不会阻止升级继续进行，但我们强烈建议您考虑将表迁移到 `utf8mb4` 字符集，这是 MySQL 8.0 中的默认字符集。有关 [utf8mb3](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html) 和 [utf8mb4](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html) 的更多信息，请参阅 MySQL 文档中的 [Converting between 3-byte and 4-byte Unicode character sets](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html)。
**输出示例：**
```
{
"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"
}
]
}
```
要解决此问题，您需要重建引用的对象和表。有关在执行此操作之前的更多信息和先决条件，请参阅 MySQL 文档中的 [Converting between 3-byte and 4-byte Unicode character sets](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html)。
**zeroDatesCheck**
**预检查级别：警告**
**日期、日期时间和时间戳值为零**
MySQL 现在对在日期、日期时间和时间戳列中使用零值实施更严格的规则。我们建议您将 `NO_ZERO_IN_DATE` 和 `NO_ZERO_DATE SQL` 模式与 `strict` 模式结合使用，因为在将来的 MySQL 版本中，它们将与 `strict` 模式合并。
如果在运行预检查时，任何数据库连接的 `sql_mode` 设置不包括这些模式，则会在预检查中发出警告。用户可能仍然能够插入包含零值的日期、日期时间和时间戳值。但是，我们强烈建议将任何零值替换为有效值，因为其行为将来可能会发生变化，并且这些零值可能无法正常发挥作用。由于这是一个警告，因此不会阻止升级，但我们建议您开始计划采取措施。
**输出示例：**
```
{
"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"
}
]
}
```
### 报告警告的 Aurora MySQL 预检查
以下预检查特定于 Aurora MySQL：
+ [auroraUpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [auroraUpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
**auroraUpgradeCheckForRollbackSegmentHistoryLength**
**预检查级别：警告**
**检查集群的回滚段历史记录列表长度是否很高**
如在 [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions) 中所提到的那样，在运行主要版本升级过程时，务必对 Aurora MySQL 版本 2 数据库实例执行 [clean shutdown](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)。这可以确保所有事务都已提交或回滚，并且 InnoDB 已清除所有撤消日志记录。
如果数据库集群具有较高的回滚段历史记录列表长度（HLL），则可能会延长 InnoDB 完成其清除撤消日志记录所需的时间量，从而导致主要版本升级过程中的停机时间延长。如果预检查检测到数据库集群上的 HLL 很高，则会发出警告。虽然这不会阻止升级继续进行，但建议您密切监控数据库集群上的 HLL。将其保持在较低水平，可以减少主要版本升级期间所需的停机时间。有关监控 HLL 的更多信息，请参阅 [InnoDB 历史记录列表长度显著增加](proactive-insights.history-list.md)。
**输出示例：**
```
{
"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."
}
]
}
```
预检查返回警告，因为它检测到数据库集群上的 InnoDB 撤消 HLL 很高（82989114）。尽管升级继续进行，但根据要清除的撤消量，可能会延长升级过程中所需的停机时间。
我们建议您在生产环境中运行升级之前，先[调查数据库集群上的未结事务](proactive-insights.history-list.md)，以确保 HLL 保持为可管理的大小。
**auroraUpgradeCheckForUncommittedRowModifications**
**预检查级别：警告**
**检查是否有许多未提交的行修改**
如在 [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions) 中所提到的那样，在运行主要版本升级过程时，务必对 Aurora MySQL 版本 2 数据库实例执行 [clean shutdown](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)。这可以确保所有事务都已提交或回滚，并且 InnoDB 已清除所有撤消日志记录。
如果数据库集群具有修改了大量行的事务，则它可能会延长 InnoDB 完成回滚此事务（作为干净关闭过程的一部分）所需的时间量。如果预检查在数据库集群上发现长时间运行的事务且具有大量的已修改行，则会发出警告。虽然这不会阻止升级继续进行，但建议您密切监控数据库集群上活动事务的大小。将其保持在较低水平，可以减少主要版本升级期间所需的停机时间。
**输出示例：**
```
{
"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."
}
]
},
```
预检查报告称，数据库集群包含一个事务，其中有 11000000 个未提交的行更改将需要在干净关闭过程中回滚。升级将继续进行，但为了减少升级过程中的停机时间，建议您在生产集群上运行升级之前对此进行监控和调查。
要查看写入器数据库实例上的活动事务，可以使用 [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) 表。以下针对写入器数据库实例的查询显示了数据库集群的当前事务、运行时间、状态和修改的行。
```
# 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)
```
事务提交或回滚后，预检查将不再返回警告。在回滚任何大型事务之前，请查阅 MySQL 文档和咨询应用程序团队，因为回滚可能需要一些时间才能完成，具体取决于事务大小。
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"detectedProblems": []
},
```
有关优化 InnoDB 事务管理以及在 MySQL 数据库实例上运行和回滚大型事务的潜在影响的更多信息，请参阅 MySQL 文档中的 [Optimizing InnoDB transaction management](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)。
## 版权声明
以下预检查失败时会生成通知，但升级可以继续。
**sqlModeFlagCheck**
**预检查级别：通知**
**使用过时的 `sql_mode` 标志**
除了 `MAXDB` 外，还 [removed](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) 许多其它 `sql_mode` 选项：`DB2`、`MSSQL`、`MYSQL323`、`MYSQL40`、`ORACLE`、`POSTGRESQL`、`NO_FIELD_OPTIONS`、`NO_KEY_OPTIONS` 和 `NO_TABLE_OPTIONS`。从 MySQL 8.0 开始，这些值都不能分配给 `sql_mode` 系统变量。如果此项预检查发现任何使用这些 `sql_mode` 设置的处于打开状态的会话，请确保更新您的数据库实例和数据库集群参数组以及客户端应用程序和配置来将其禁用。有关更多信息，请参阅 [MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)。
**输出示例：**
```
{
"id": "sqlModeFlagCheck",
"title": "Usage of obsolete sql_mode flags",
"status": "OK",
"detectedProblems": []
}
```
要解决其中任何预检查失败，请参阅 [maxdbFlagCheck](#maxdbFlagCheck)。
## 错误、警告或通知
根据预检查输出，以下预检查可能会返回错误、警告或通知。
**checkTableOutput**
**预检查级别：错误、警告或通知**
**`check table x for upgrade` 命令报告的问题**
在开始升级到 Aurora MySQL 版本 3 之前，`check table for upgrade` 会在数据库集群中用户架构的每个表上运行。此项预检查与 [checkTableMysqlSchema](#checkTableMysqlSchema) 不一样。
`check table for upgrade` 命令检查表中是否存在升级到较新 MySQL 版本期间可能出现的任何潜在问题。在尝试升级之前运行此命令，有助于提前确定和解决任何不兼容性，从而使实际升级过程更加顺畅。
此命令对每个表执行各种检查，例如：
+ 验证表结构和元数据是否与目标 MySQL 版本兼容
+ 检查表是否使用了任何已弃用或已移除的功能
+ 确保表可以正确地升级而不会丢失数据
与其它预检查不同，此项预检查可以根据 `check table` 输出返回错误、警告或通知。如果此项预检查返回了任何表，请在启动升级之前，仔细查看这些表以及返回代码和消息。有关更多信息，请参阅 MySQL 文档中的 [CHECK TABLE statement](https://dev.mysql.com/doc/refman/5.7/en/check-table.html)。
在此，我们提供了一个错误示例和一个警告示例。
**错误示例：**
```
{
"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"
}
]
},
```
预检查报告了一个错误，即 `test.parent` 表不存在。
写入器数据库实例的 `mysql-error.log` 文件显示存在外键错误。
```
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.
```
登录到写入器数据库实例并运行 `show engine innodb status\G`，来获取有关外键错误的更多信息。
```
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.
.
.
```
`LATEST FOREIGN KEY ERROR` 消息报告称，`test.child` 表中引用 `test.parent` 表的 `fk_pname` 外键约束缺少索引或数据类型不匹配。有关 [foreign key constraints](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html) 的 MySQL 文档指出，外键中引用的列必须具有关联的索引，并且父/子列必须使用相同的数据类型。
要验证这是否与缺失索引或数据类型不匹配有关，请登录数据库，并通过暂时禁用会话变量 [foreign\$1key\$1checks](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html#foreign-key-checks) 来检查表定义。这样做之后，可以看到这个有问题的子约束 (`fk_pname`) 使用 `p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL` 来引用父表 `name varchar(20) NOT NULL`。父表使用 `DEFAULT CHARSET=utf8`，但子表的 `p_name` 列使用 `latin1`，因此引发数据类型不匹配错误。
```
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)
```
要解决这个问题，可以将子表更改为与父表使用相同的字符集，也可以将父表更改为与子表使用相同的字符集。在这里，由于子表在 `p_name` 列定义中显式使用 `latin1`，因此我们运行 `ALTER TABLE` 来将字符集修改为 `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)
```
完成此操作后，预检查通过，升级可以继续进行。
**警告示例：**
```
{
"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."
}
]
}
```
预检查对于 `test.orders` 表上的 `delete_audit_trigg` 触发器报告了警告，因为该触发器没有 `CREATED` 属性。根据 MySQL 文档中的 [Checking version compatibility](https://dev.mysql.com/doc/refman/5.7/en/check-table.html#check-table-version-compatibility)，此消息是信息性的，是针对在 MySQL 5.7.2 之前创建的触发器显示的。
因为这是一个警告，所以它不会阻止升级继续进行。但是，如果您希望解决此问题，可以重新创建这个有问题的触发器，预检查将成功而没有警告。
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": []
},
```
# 如何执行就地升级
我们建议您查看 [Aurora MySQL 主要版本就地升级的工作原理](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence)中的背景材料。
按[为 Aurora MySQL 集群计划主要版本升级](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning)中所述执行任何升级前的计划和测试。
## 控制台
以下示例将 `mydbcluster-cluster` 数据库集群升级到 Aurora MySQL 版本 3.04.1。
**要升级 Aurora MySQL 数据库集群的主要版本**
1. 登录 Amazon Web Services 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.amazonaws.cn/rds/)。
1. 如果您将自定义参数组用于原始数据库集群，请创建与新的主要版本兼容的相应参数组。对这个新参数组中的配置参数进行任何必要的调整。有关更多信息，请参阅“[就地升级如何影响集群的参数组](#AuroraMySQL.Upgrading.ParamGroups)”。
1. 在导航窗格中，选择 **Databases (数据库)**。
1. 在列表中，选择您要修改的数据库集群。
1. 选择 **Modify (修改)**。
1. 对于 **Version**（版本），选择新的 Aurora MySQL 主要版本。
我们通常建议使用主要版本的最新次要版本。在这里，我们选择当前的默认版本。
![\[Aurora MySQL 数据库集群从版本 2 就地升级到版本 3\]](http://docs.amazonaws.cn/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. 选择 **Continue (继续)**。
1. 在下一页上，指定何时执行升级。选择 **During the next scheduled maintenance window**（在下一个计划的维护时段内）或 **Immediately**（立即）。
1. （可选）在升级过程中定期检查 RDS 控制台中的 **Events**（事件）页面。这样做可以帮助您监控升级进度并识别问题。如果升级遇到任何问题，请参阅[Aurora MySQL 就地升级的故障排除](AuroraMySQL.Upgrading.Troubleshooting.md)以了解要采取的步骤。
1. 如果您在此过程开始时创建了一个新的参数组，请将自定义参数组与升级的集群关联起来。有关更多信息，请参阅 [就地升级如何影响集群的参数组](#AuroraMySQL.Upgrading.ParamGroups)。
**注意**
执行此步骤需要您再次重新启动集群以应用新的参数组。
1. （可选）完成任何升级后测试后，请删除升级开始时 Aurora 创建的手动快照。
## Amazon CLI
要升级 Aurora MySQL 数据库集群的主要版本，请结合使用 Amazon CLI [modify-db-cluster](https://docs.amazonaws.cn/cli/latest/reference/rds/modify-db-cluster.html) 命令与以下所需的参数：
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` 或者 `--no-apply-immediately`
如果您的集群使用任何自定义参数组，则还要包含以下一个或两个选项：
+ `--db-cluster-parameter-group-name`，如果集群使用自定义集群参数组
+ `--db-instance-parameter-group-name`，如果集群中的任何实例使用自定义数据库参数组
以下示例将 `sample-cluster` 数据库集群升级到 Aurora MySQL 版本 3.04.1。升级会立即进行，而不是等待下一个维护时段。
**Example**
对于 Linux、macOS 或 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
```
对于 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
```
您可以将其他 CLI 命令与 `modify-db-cluster` 结合使用，以创建执行和验证升级的自动端到端流程。有关更多信息以及示例，请参阅 [Aurora MySQL 就地升级教程](AuroraMySQL.Upgrading.Tutorial.md)。
**注意**
如果您的集群属于 Aurora 全局数据库的一部分，则就地升级程序会略有不同。您可以调用 [modify-global-cluster](https://docs.amazonaws.cn/cli/latest/reference/rds/modify-global-cluster.html) 命令操作而不是 `modify-db-cluster`。有关更多信息，请参阅“[全局数据库的就地主要版本升级](#AuroraMySQL.Upgrading.GlobalDB)”。
## RDS API
要升级 Aurora MySQL 数据库集群的主要版本，请结合使用 RDS API 操作 [ModifyDBCluster](https://docs.amazonaws.cn/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) 与以下所需的参数：
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately`（设置为 `true` 或 `false`）
**注意**
如果您的集群属于 Aurora 全局数据库的一部分，则就地升级程序会略有不同。您将调用 [ModifyGlobalCluster](https://docs.amazonaws.cn/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html) 操作而不是 `ModifyDBCluster`。有关更多信息，请参阅“[全局数据库的就地主要版本升级](#AuroraMySQL.Upgrading.GlobalDB)”。
## 就地升级如何影响集群的参数组
对于与 MySQL 5.7 或 8.0 兼容的集群，Aurora 参数组具有不同的配置设置集。执行就地升级时，升级后的集群及其所有实例必须使用相应的集群和实例参数组：
您的集群和实例可能使用与 5.7 兼容的原定设置参数组。如果是这样，则升级后的集群和实例将以与 8.0 兼容的原定设置参数组开始。如果您的集群和实例使用任何自定义参数组，则确保创建相应的与 8.0 兼容的参数组。此外，请确保在升级过程中指定这些参数组。
**注意**
对于大多数参数设置，您可以在两个点选择自定义参数组。也即，在您创建集群或稍后将参数组与集群关联时。
但是，如果您将非原定设置设置用于 `lower_case_table_names` 参数，则必须提前使用此设置来设置自定义参数组。然后，在执行快照还原操作以创建集群时指定参数组。创建集群后，`lower_case_table_names` 参数的任何更改不会产生任何影响。
我们建议您在从 Aurora MySQL 版本 2 升级到版本 3 时对 `lower_case_table_names` 使用相同的设置。
使用基于 Aurora MySQL 的 Aurora 全局数据库时，如果开启了 `lower_case_table_names` 参数，则无法执行从 Aurora MySQL 版本 2 到版本 3 的就地升级。有关可以使用的方法的更多信息，请参阅[主要版本升级。](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major)。
**重要**
如果在升级过程中指定了任何自定义参数组，请确保在升级完成后手动重启集群。这样做会使集群开始使用您的自定义参数设置。
## Aurora MySQL 版本之间的集群属性更改
当从 Aurora MySQL 版本 2 升级到版本 3 时，请确保检查用于设置或管理 Aurora MySQL 集群和数据库实例的任何应用程序或脚本。
此外，请更改操作参数组的代码，以考虑到原定设置参数组名称对于 5.7 和 8.0 兼容的集群各不相同这一事实。Aurora MySQL 版本 2 和 3 集群的原定设置参数组名称分别为 `default.aurora-mysql5.7` 和 `default.aurora-mysql8.0`。
例如，升级之前，您可能有适用于您的集群的类似以下内容的代码。
```
# 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
```
升级集群的主要版本后，请按如下方式修改该代码。
```
# 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
```
## 全局数据库的就地主要版本升级
对于 Aurora Global Database，您可升级全局数据库集群。Aurora 会同时自动升级所有集群，并确保所有集群运行相同的引擎版本。此要求是因为对系统表、数据文件格式等所做的任何更改都会自动复制到所有辅助集群。
按照[Aurora MySQL 主要版本就地升级的工作原理](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence)中的说明进行操作。指定要升级的内容时，请确保选择全局数据库集群，而不是其包含的集群之一。
如果您使用 Amazon Web Services 管理控制台，请选择具有角色 **Global database**（全局数据库）的项目。
![\[升级全局数据库集群\]](http://docs.amazonaws.cn/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
如果您使用 Amazon CLI 或 RDS API，请通过调用 [modify-global-cluster](https://docs.amazonaws.cn/cli/latest/reference/rds/modify-global-cluster.html) 命令或 [ModifyGlobalCluster](https://docs.amazonaws.cn/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html) 操作来启动升级过程。您可以使用其中一个操作来代替 `modify-db-cluster` 或 `ModifyDBCluster`。
**注意**
在对该 Aurora 全局数据库执行主要版本升级时，无法为全局数据库集群指定自定义参数组。在全局集群的每个区域中创建自定义参数组。然后，在升级后手动将它们应用于区域集群。
要使用 Amazon CLI 升级 Aurora MySQL 全局数据库集群的主要版本，请结合使用 [modify-global-cluster](https://docs.amazonaws.cn/cli/latest/reference/rds/modify-global-cluster.html) 命令与以下所需的参数：
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
以下示例将全局数据库集群升级到 Aurora MySQL 版本 2.10.2。
**Example**
对于 Linux、macOS 或 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
```
对于 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
```
## 回溯注意事项
如果您升级的集群启用了回溯功能，您无法将升级的集群回溯到升级之前的时间。
# Aurora MySQL 就地升级教程
Aurora MySQL 就地升级教程
以下 Linux 示例展示了如何使用 Amazon CLI 执行就地升级过程的一般步骤。
第一个示例创建了运行 Aurora MySQL 版本 2.x 的 Aurora 数据库集群。该集群包括写入器数据库实例和读取器数据库实例。`wait db-instance-available` 命令会暂停，直到写入器数据库实例可用。此时，集群做好升级准备。
```
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
```
您可以将集群升级到的 Aurora MySQL 3.x 版本取决于集群当前正在运行的 2.x 版本和集群所在的 Amazon Web Services 区域。第一个命令（带 `--output text`）只显示可用的目标版本。第二个命令显示响应的完整 JSON 输出。在该响应中，您可以看到详细信息，例如您用于 `engine` 参数的 `aurora-mysql` 值。您还可以看到这样一个事实，即升级到 3.04.0 表示一次主要版本升级。
```
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
},
...
```
此示例表示，如果您输入的目标版本号不是集群的有效升级目标，Aurora 不会执行升级。Aurora 也不会执行主要版本升级，除非您包含 `--allow-major-version-upgrade` 参数。这样一来，您就不能意外执行有可能需要大量测试和更改应用程序代码的升级。
```
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"
}
```
集群和关联数据库实例的状态需要一段时间才能更改为 `upgrading`。集群和数据库实例的版本号仅在升级完成后才会更改。同样，您可以使用 `wait db-instance-available` 命令让写入器数据库实例等到升级完成后再继续。
```
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
```
此时，集群的版本号与为升级指定的版本号匹配。
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.04.0
```
前面的示例通过指定 `--apply-immediately` 参数进行了立即升级。为了让升级在集群预计不繁忙的方便之时进行，您可以指定 `--no-apply-immediately` 参数。这样做可以在集群的下一个维护时段内启动升级。维护时段定义了可以启动维护操作的时间段。在维护时段内，长时间运行的操作可能无法完成。因此，即使您预计升级可能需要很长时间，也不需要定义更大的维护时段。
以下示例升级最初运行 Aurora MySQL 版本 2.11.2 的集群。在 `describe-db-engine-versions` 输出中，`False` 和 `True` 值表示 `IsMajorVersionUpgrade` 属性。您可以从版本 2.11.2 升级到一些其他 2.\$1 版本。这些升级不被视为主要版本升级，因此不需要就地升级。就地升级仅适用于升级到列表中显示的 3.\$1 版本。
```
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
...
```
如果在没有指定的维护时段的情况下创建集群，Aurora 会随机选择一周中的一天。在这种情况下，`modify-db-cluster` 命令将在星期一提交。因此，我们将维护时段更改为星期二早上。所有时间都以 UTC 时区表示。`tue:10:00-tue:10:30` 时段对应于太平洋时间凌晨 2:00-2:30。维护时段的更改会立即生效。
```
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"
]
]
```
以下示例说明如何获取升级所生成的事件的报告。`--duration` 参数表示检索事件信息的分钟数。系统需要此参数，因为默认情况下，`describe-events` 仅返回最后一个小时的事件。
```
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"
}
]
}
```
# 查找 Aurora MySQL 主要版本升级失败的原因
查找主要版本升级失败的原因
在[教程](AuroraMySQL.Upgrading.Tutorial.md)中，从 Aurora MySQL 版本 2 升级到版本 3 已获成功。但是，如果升级失败，您会想知道原因。
您可以首先使用 `describe-events` Amazon CLI 命令来查看数据库集群事件。此示例显示过去 10 小时 `mydbcluster` 的事件。
```
aws rds describe-events \
--source-type db-cluster \
--source-identifier mydbcluster \
--duration 600
```
在本例中，我们遇到了升级预检查失败。
```
{
"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"
}
]
}
```
要诊断问题的确切原因，请检查写入器数据库实例的数据库日志。如果升级到 Aurora MySQL 版本 3 失败，写入器实例将包含一个名为 `upgrade-prechecks.log` 的日志文件。此示例说明了如何检测该日志是否存在，然后将其下载到本地文件以供检查。
```
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
```
`upgrade-prechecks.log` 文件为 JSON 格式。我们使用 `--output text` 选项下载该文件，避免在另一个 JSON 包装器中对 JSON 输出进行编码。对于 Aurora MySQL 版本 3 升级，此日志始终包含某些信息和警告消息。如果升级失败，日志仅包含错误消息。如果升级成功，则根本不会生成日志文件。
要汇总所有错误并显示关联的对象和描述字段，您可以对 `upgrade-prechecks.log` 文件的内容运行命令 `grep -A 2 '"level": "Error"'`。这样做会显示每个错误行及其后两行。其中包含相应数据库对象的名称以及有关如何解决问题的指导。
```
$ 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."
```
在此示例中，您可以对有问题的表运行以下 SQL 命令来尝试修复问题，也可以重新创建没有悬挂索引的表。
```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```
然后重试升级。
# Aurora MySQL 就地升级的故障排除
可以使用以下提示帮助排查 Aurora MySQL 就地升级问题。这些提示不适用于 Aurora Serverless 数据库集群。
| 就地升级被取消或减慢的原因 | 效果 | 允许在维护时段内完成就地升级的解决方案 |
| --- | --- | --- |
| 尚未修补关联的 Aurora 跨区域副本 | Aurora 取消升级。 | 升级 Aurora 跨区域副本并重试。 |
| 集群具有处于准备状态的 XA 事务 | Aurora 取消升级。 | 提交或回滚所有准备好的 XA 事务。 |
| 集群正在处理数据定义语言 (DDL) 语句 | Aurora 取消升级。 | 考虑等待并在所有 DDL 语句完成后执行升级。 |
| 集群有很多行未提交的更改 | 升级可能需要较长时间。 | 升级过程将回滚未提交的更改。这种情况的指示器为 `TRX_ROWS_MODIFIED` 表中的 `INFORMATION_SCHEMA.INNODB_TRX` 值。 考虑仅在提交或回退所有大型事务后才执行升级。 |
| 集群有大量的撤消记录 | 升级可能需要较长时间。 | 即使未提交的事务不会影响大量行，也可能涉及大量数据。例如，您可能正在插入大型 BLOB。Aurora 不会自动检测或生成此类事务活动的事件。这种情况的指示器为历史记录列表长度（HLL）。升级过程将回滚未提交的更改。 您可以在 `SHOW ENGINE INNODB STATUS` SQL 命令的输出中检查 HLL，也可以直接使用以下 SQL 查询进行检查： SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
还可以在 Amazon CloudWatch 中监控 `RollbackSegmentHistoryListLength` 指标。 考虑仅在 HLL 较小之后才执行升级。 |
| 集群正在提交大型二进制日志事务 | 升级可能需要较长时间。 | 升级过程将等到应用二进制日志更改时。在此期间，可能会启动更多事务或 DDL 语句，从而进一步减慢升级过程。 将升级过程安排在集群不忙于生成二进制日志复制更改的时间段。Aurora 不会自动检测或生成此情况的事件。 |
| 文件删除或损坏导致的模式不一致 | Aurora 取消升级。 | 将临时表的原定设置存储引擎从 MyISAM 更改为 InnoDB。执行以下步骤： [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| 已删除主用户 | Aurora 取消升级。 | 不要删除主用户。 但是，如果由于某种原因您碰巧删除了主用户，请使用以下 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;
|
有关对导致升级预检查失败的问题进行故障排除的更多详细信息，请参阅以下博客：
+ [Amazon Aurora MySQL version 2 (with MySQL 5.7 compatibility) to version 3 (with MySQL 8.0 compatibility) upgrade checklist, Part 1](https://www.amazonaws.cn/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://www.amazonaws.cn/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/)
您可以使用以下步骤对上表中的某些条件执行自己的检查。这样，您可以在知道数据库处于可以成功快速地完成升级的状态时安排升级。
+ 您可以通过执行 `XA RECOVER` 语句来检查未完成的 XA 事务。然后，您可以在开始升级之前提交或回滚 XA 事务。
+ 您可以通过执行 `SHOW PROCESSLIST` 语句并在输出中查找 `CREATE`、`DROP`、`ALTER`、`RENAME` 和 `TRUNCATE` 语句来检查 DDL 语句。在开始升级之前，等待所有 DDL 语句完成。
+ 您可以通过查询 `INFORMATION_SCHEMA.INNODB_TRX` 表来检查未提交的行总数。该表为每个事务包含一行。`TRX_ROWS_MODIFIED` 列包含事务修改或插入的行数。
+ 您可以通过执行 `SHOW ENGINE INNODB STATUS SQL` 语句并在输出中查找 `History list length` 来检查 InnoDB 历史记录列表的长度。您还可以通过运行以下查询直接检查值：
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
历史记录列表的长度对应于数据库为实施多版本并发控制 (MVCC) 而存储的撤消信息量。
# Aurora MySQL 版本 3 的升级后清理
将任何 Aurora MySQL 版本 2 集群升级到 Aurora MySQL 版本 3 后，您可以执行以下其他清理操作：
+ 为任何自定义参数组创建与 MySQL 8.0 兼容的新版本。将所有必要的自定义参数值应用于新参数组。
+ 更新任何 CloudWatch 告警、设置脚本等，以便对名称受到包含性语言更改影响的任何指标使用新名称。有关此类指标的列表，请参阅 [Aurora MySQL 版本 3 的包容性语言更改](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language)。
+ 更新任何 Amazon CloudFormation 模板，以对名称受到包含性语言更改影响的任何配置参数使用新名称。有关此类参数的列表，请参阅 [Aurora MySQL 版本 3 的包容性语言更改](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language)。
## 空间索引
升级到 Aurora MySQL 版本 3 后，检查是否需要删除或重新创建与空间索引相关的对象和索引。在 MySQL 8.0 之前，Aurora 可以使用不包含空间资源标识符 (SRID) 的索引来优化空间查询。Aurora MySQL 版本 3 仅使用包含 SRID 的空间索引。在升级过程中，Aurora 会自动删除任何没有 SRID 的空间索引，并在数据库日志中打印警告消息。如果观察到此类警告消息，请在升级后使用 SRID 创建新的空间索引。有关 MySQL 8.0 中空间函数和数据类型更改的更多信息，请参阅 *MySQL 参考手册*中的 [MySQL 8.0 中的变化](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html)。