Aurora MySQL 的预检查描述参考 - Amazon Aurora
错误警告版权声明错误、警告或通知
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

Aurora MySQL 的预检查描述参考

此处详细描述了 Aurora MySQL 的升级预检查。

错误

以下预检查失败时会生成错误，升级无法继续。

报告错误的 MySQL 预检查

以下预检查来自社区 MySQL：

checkTableMysqlSchema

预检查级别：错误

check table x for upgrade 命令针对 mysql 架构报告的问题

在开始升级到 Aurora MySQL 版本 3 之前，将对数据库实例的 mysql 架构中的每个表运行 check table for upgrade。check table for upgrade 命令检查表中是否存在升级到较新 MySQL 版本期间可能出现的任何潜在问题。在尝试升级之前运行此命令，有助于提前确定和解决任何不兼容性，从而使实际升级过程更加顺畅。

此命令对每个表执行各种检查，例如：

  • 验证表结构和元数据是否与目标 MySQL 版本兼容

  • 检查表是否使用了任何已弃用或已移除的功能

  • 确保表可以正确地升级而不会丢失数据

有关更多信息，请参阅 MySQL 文档中的 CHECK TABLE statement。

输出示例：

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

此项预检查的输出取决于遇到的错误以及遇到错误的时间，因为 check table for upgrade 会执行多项检查。

如果您在此项预检查中遇到任何错误，请向 Amazon Support 提交案例，来请求解决元数据不一致性。或者，可以通过执行逻辑转储，然后还原到新的 Aurora MySQL 版本 3 数据库集群来重试升级。

circularDirectoryCheck

预检查级别：错误

表空间数据文件路径中的循环目录引用

从 MySQL 8.0.17 开始，CREATE TABLESPACE ... ADD DATAFILE 子句不再允许循环目录引用。为避免出现升级问题，请在升级到 Aurora MySQL 版本 3 之前，从表空间数据文件路径中移除所有循环目录引用。

输出示例：

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

如果您收到此错误，请使用 file-per-table tablespace 来重建表。对所有表空间和表定义使用默认文件路径。

注意

Aurora MySQL 不支持一般表空间或 CREATE TABLESPACE 命令。

在重建表空间之前，请参阅 MySQL 文档中的 Online DDL operations，来了解锁定和数据移动对前台事务的影响。

重建后，预检查通过，支持升级继续进行。

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

预检查级别：错误

不能有默认值的列

在 MySQL 8.0.13 之前，BLOB、TEXT、GEOMETRY 和 JSON 列不能有 default values。在升级到 Aurora MySQL 版本 3 之前，请移除这些列上的所有默认子句。有关这些数据类型的默认处理方式的变化的更多信息，请参阅 MySQL 文档中的 Data type default values。

输出示例：

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

预检查会返回错误，因为 test.test_blob_default 表中的 geo_col 列使用指定了默认值的 BLOB、TEXT、GEOMETRY 或 JSON 数据类型。

查看表定义，我们可以看到 geo_col 列定义为 geo_col geometry NOT NULL default ''。

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

移除此默认子句可支持预检查通过。

注意

在运行 ALTER TABLE 语句或重建表空间之前，请参阅 MySQL 文档中的 Online DDL operations，来了解锁定和数据移动对前台事务的影响。

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

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

预检查通过，您可以重试升级。

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

预检查级别：错误

在定义中使用弃用的关键词

MySQL 8.0 移除了 query cache。因此，移除了一些特定于查询缓存的 SQL 语法。如果任何数据库对象包含 QUERY CACHE、SQL_CACHE 或 SQL_NO_CACHE 关键字，则会返回预检查错误。要解决此问题，请重新创建这些对象，并移除提到的关键字。

输出示例：

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

预检查报告 test.no_query_cache_check 存储过程正在使用其中一个已移除的关键字。查看过程定义，可以看到它使用了 SQL_NO_CACHE。

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

移除该关键字。

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

mysql> delimiter //

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

mysql> delimiter ;

移除该关键字后，预检查成功完成。

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

预检查级别：错误

InnoDB 识别的属于不同引擎的表

与 schemaInconsistencyCheck 类似，此项预检查在继续升级之前验证 MySQL 中的表元数据是否一致。

如果您在此项预检查中遇到任何错误，请向 Amazon Support 提交案例，来请求解决元数据不一致性。或者，可以通过执行逻辑转储，然后还原到新的 Aurora MySQL 版本 3 数据库集群来重试升级。

输出示例：

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

预检查级别：错误

ENUM 和 SET 列定义包含长度超过 255 个字符的元素

表和存储过程的 ENUM 或 SET 列元素不得超过 255 个字符或 1020 个字节。在 MySQL 8.0 之前，最大组合长度为 64 K，但 8.0 将单个元素限制为 255 个字符或 1020 字节（支持多字节）。如果针对 enumSetElementLengthCheck 的预检查失败，请在重试升级之前修改任何超出这些新限制的元素。

输出示例：

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

预检查会报告错误，因为 test.large_set 表中的列 s 包含一个大于 255 个字符的 SET 元素。

在减小此列的 SET 大小后，预检查通过，支持升级继续进行。

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

预检查级别：错误

外键约束名称长度超过 64 个字符

在 MySQL 中，标识符的长度限制为 64 个字符，如 MySQL documentation 中所述。由于发现了外键长度可能等于或超过该值的 issues，导致升级失败，因此实施了这项预检查。如果您在此项预检查中遇到错误，则应 alter or rename 约束，使其少于 64 个字符，然后重试升级。

输出示例：

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

预检查级别：错误

数据库中的所有触发器名称都必须是唯一的。

由于数据字典实现的变化，MySQL 8.0 不支持数据库中区分大小写的触发器。此项预检查可验证数据库集群中没有一个或多个包含重复触发器的数据库。有关更多信息，请参阅 MySQL 文档中的 Identifier case sensitivity。

输出示例：

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

此项预检查报告了一个错误，即数据库集群有两个同名但使用不同大小写的触发器：test.before_insert_product 和 test.before_insert_PRODUCT。

在升级之前，请重命名这些触发器，或删除它们并使用新名称重新创建。

将 test.before_insert_PRODUCT 重命名为 test.before_insert_product_2 后，预检查成功。

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

预检查级别：错误

mysql.event 的定义者列不能为 null 或为空。

DEFINER 属性指定拥有存储对象定义（例如触发器、存储过程或事件）的 MySQL 账户。在您想要控制存储对象在其中运行的安全上下文的情况下，此属性特别有用。创建存储对象时，如果未指定 DEFINER，则默认为创建了该对象的用户。

升级到 MySQL 8.0 时，MySQL 数据字典中不能有任何具有 null 或空定义者的存储对象。如果有这样的存储对象，则会引发预检查错误。必须先修复此问题，然后才能继续升级。

错误示例：

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

由于 test.get_version event 具有 null 定义者，因此预检查会返回一个错误。

要解决这个问题，可以检查事件定义。如您所见，定义者为 null 或空。

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

删除该事件，或使用有效的定义者重新创建该事件。

注意

在删除或重新定义 DEFINER 之前，请仔细查看并检查您的应用程序和权限要求。有关更多信息，请参阅 MySQL 文档中的 Stored object access control。

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

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

mysql> DELIMITER ;

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

现在，预检查通过。

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

预检查级别：错误

InnoDB 数据字典和实际表定义之间的列定义不匹配

与 schemaInconsistencyCheck 类似，此项预检查在继续升级之前验证 MySQL 中的表元数据是否一致。在这种情况下，预检查会验证 InnoDB 数据字典和 MySQL 表定义之间的列定义是否匹配。如果检测到不匹配，则升级将无法继续。

如果您在此项预检查中遇到任何错误，请向 Amazon Support 提交案例，来请求解决元数据不一致性。或者，可以通过执行逻辑转储，然后还原到新的 Aurora MySQL 版本 3 数据库集群来重试升级。

输出示例：

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

预检查报告 test.mismatchTable 表中 id 列的元数据不匹配。具体而言，MySQL 元数据的列名称为 iD，而 InnoDB 的列名称为 id。

getTriggersWithNullDefiner

预检查级别：错误

information_schema.triggers 的定义者列不能为 null 或为空。

此项预检查验证您的数据库中没有使用 null 或空定义者定义的触发器。有关存储对象的定义者要求的更多信息，请参阅 getEventsWithNullDefiner。

输出示例：

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

由于 test 架构中的 example_trigger 触发器具有 null 定义者，因此预检查会返回错误。要更正此问题，请使用有效的用户重新创建触发器来修复定义者，或者删除此触发器。有关更多信息，请参阅 getEventsWithNullDefiner 中的示例。

注意

在删除或重新定义 DEFINER 之前，请仔细查看并检查您的应用程序和权限要求。有关更多信息，请参阅 MySQL 文档中的 Stored object access control。

getValueOfVariablelower_case_table_names

预检查级别：错误

将 lower_case_table_names 参数设置为 1 时，所有数据库和表名称都必须为小写。

在 MySQL 8.0 之前，数据库名称、表名称和其它对象对应于数据目录中的文件，例如基于文件的元数据 (.frm)。lower_case_table_names 系统变量可让用户控制服务器如何处理数据库对象的标识符区分大小写，以及此类元数据对象的存储。重启后，可以在已经初始化的服务器上更改此参数。

但是，在 MySQL 8.0 中，虽然此参数仍然控制服务器如何处理标识符区分大小写，但在数据字典初始化后无法对其进行更改。升级或创建 MySQL 8.0 数据库时，首次在 MySQL 上启动数据字典时为 lower_case_table_names 设置的值将用于该数据库的生命周期。此限制是作为 Atomic Data Dictionary 实现的一部分而实施的，其中数据库对象从基于文件的元数据迁移到 mysql 架构中的内部 InnoDB 表。

有关更多信息，请参阅 MySQL 文档中的 Data dictionary changes。

为了避免在升级过程中将基于文件的元数据更新到新的原子数据字典时出现问题，此项预检查验证当 lower_case_table_names = 1 时，所有表都以小写存储在磁盘上。如果不是，则会返回预检查错误，您必须在继续升级之前更正元数据。

输出示例：

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

由于表 test.TEST 包含大写字母，但 lower_case_table_names 设置为 1，因此返回错误。

要解决此问题，可以将表重命名为使用小写，或在开始升级之前修改数据库集群上的 lower_case_table_names 参数。

注意

请仔细测试和查看有关 MySQL 中 case sensitivity 的文档，以及任何此类更改可能会如何影响您的应用程序。

另请查看 MySQL 8.0 文档，了解在 MySQL 8.0 中如何以不同的方式处理 lower_case_table_names。

groupByAscSyntaxCheck

预检查级别：错误

使用已移除的 GROUP BY ASC/DESC 语法

从 MySQL 8.0.13 开始，GROUP BY 子句的已弃用 ASC 或 DESC 语法已被移除。依赖于 GROUP BY 排序的查询现在可能产生不同的结果。要获得特定的排序顺序，请改用 ORDER BY 子句。如果数据库中存在使用此语法的任何对象，则在重试升级之前，必须使用 ORDER BY 子句重新创建这些对象。有关更多信息，请参阅 MySQL 文档中的 SQL changes。

输出示例：

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

预检查级别：错误

检查例程中是否使用了弃用的 .<table> 语法。

在 MySQL 8.0 中，例程不能再包含已弃用的标识符语法 (\".<table>\")。如果任何存储例程或触发器包含此类标识符，则升级将失败。例如，不再允许使用以下 .dot_table 引用：

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

重新创建例程和触发器以使用正确的标识符语法和转义后，预检查通过，升级就可以继续了。有关标识符的更多信息，请参阅 MySQL 文档中的 Schema object names。

输出示例：

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

预检查会返回 test 数据库中 incorrect_procedure 例程的错误，因为它包含已弃用的语法。

更正例程后，预检查成功，您可以重试升级。

mysqlIndexTooLargeCheck

预检查级别：错误

检查索引是否过大，无法在高于 5.7 的 MySQL 版本上发挥作用

对于紧凑或冗余的行格式，应无法创建前缀大于 767 字节的索引。但是，在 MySQL 版本 5.7.35 之前，这是可能的。有关更多信息，请参阅 MySQL 5.7.35 release notes。

升级到 MySQL 8.0 后，任何受此错误影响的索引都将变得无法访问。此项预检查可识别在可以升级继续之前必须重建的违规索引。

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

预检查会返回错误，因为 test.table_with_large_idx 表包含对于某个表的索引，此索引使用压缩或冗余行格式且大于 767 字节。升级到 MySQL 8.0 后，这些表将变得无法访问。在继续升级之前，请执行以下操作之一：

  • 删除预检查中提到的索引。

  • 添加预检查中提到的索引。

  • 更改表使用的行格式。

在此，我们重建表来解决预检查失败问题。在重建表之前，请确保 innodb_file_format 设置为 Barracuda，innodb_default_row_format 设置为 dynamic。这些是 MySQL 5.7 中的默认设置。有关更多信息，请参阅 MySQL 文档中的 InnoDB row formats 和 InnoDB file-format management。

注意

在重建表空间之前，请参阅 MySQL 文档中的 Online DDL operations，来了解锁定和数据移动对前台事务的影响。

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

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

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

重建表后，预检查通过，升级可以继续进行。

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

预检查级别：错误

检查 MySQL 5.7 中使用的无效表名称和架构名称

迁移到 MySQL 8.0 中的新数据字典时，数据库实例不能包含前缀为 #mysql50# 的架构或表。如果存在任何此类对象，则升级将失败。要解决此问题，请对返回的架构和表运行 mysqlcheck。

注意

请务必使用 MySQL 5.7 version 的 mysqlcheck，因为 --fix-db-names 和 --fix-table-names 已从 MySQL 8.0 中移除。

输出示例：

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

预检查报告架构 #mysql50#fix_db_names 的名称无效。

修复架构名称后，预检查通过，支持升级继续进行。

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

预检查级别：错误

检查 5.7 中的孤立例程

在 MySQL 8.0 中迁移到新的数据字典时，如果数据库中有任何存储过程不再存在架构，则升级失败。此项预检查可验证数据库实例上的存储过程中引用的所有架构是否仍存在。要让升级继续进行，请删除这些存储过程。

输出示例：

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

预检查报告 dropped_db 数据库中的 get_version 存储过程是孤立的。

要清理此过程，可以重新创建缺失的架构。

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

重新创建架构后，可以删除该过程来让升级继续进行。

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

预检查级别：错误

mysql 架构中的表名称与 MySQL 8.0 中的新表冲突

MySQL 8.0 中引入的新 Atomic Data Dictionary 将所有元数据存储在 mysql 架构的一组内部 InnoDB 表中。在升级期间，将在 mysql 架构中创建新的 internal data dictionary tables。为避免产生命名冲突而导致升级失败，预检查会检查 mysql 架构中的所有表名称，来确保没有任何新的表名称已被使用。如果是这样，则会返回错误，并且不支持继续升级。

输出示例：

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

返回错误是因为 mysql 架构中有一个名为 tablespaces 的表。这是 MySQL 8.0 中新的内部数据字典表名称之一。在升级之前，必须使用 RENAME TABLE 命令重命名任何此类表，或移除它们。

nonNativePartitioningCheck

预检查级别：错误

使用具有非原生分区的引擎对表进行分区

根据 MySQL 8.0 documentation，两个存储引擎目前提供原生分区支持：InnoDB 和 NDB。其中，Aurora MySQL 版本 3 只支持 InnoDB，它与 MySQL 8.0 兼容。使用任何其它存储引擎在 MySQL 8.0 中创建分区表的任何尝试都会失败。此项预检查会查找数据库集群中使用非原生分区的表。如果返回任何表，则必须移除分区或将存储引擎转换为 InnoDB。

输出示例：

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

在此处，MyISAM 表正在使用分区，需要先执行操作才能继续升级。

oldTemporalCheck

预检查级别：错误

使用旧的时间类型

“旧时间”是指在 MySQL 版本 5.5 及更低版本中创建的时间类型列（例如 TIMESTAMP 和 DATETIME）。在 MySQL 8.0 中，移除了对这些旧的时间数据类型的支持，这意味着，如果数据库包含这些旧的时间类型，则无法从 MySQL 5.7 就地升级到 8.0。要修复此问题，在继续升级之前，必须 rebuild 包含此类旧时间数据类型的所有表。

有关在 MySQL 5.7 中弃用旧的时间数据类型的更多信息，请参阅此 blog。有关在 MySQL 8.0 中移除旧的时间数据类型的更多信息，请参阅此 blog。

注意

在重建表空间之前，请参阅 MySQL 文档中的 Online DDL operations，来了解锁定和数据移动对前台事务的影响。

输出示例：

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

表 test.55_temporal_table 中的 timestamp_column 列报告了一个错误，因为它使用了不再支持的旧时间磁盘存储格式。

要解决此问题并让升级继续进行，请重建表，来将旧时间磁盘存储格式转换为 MySQL 5.6 中引入的新格式。有关在执行此操作之前的更多信息和先决条件，请参阅 MySQL 文档中的 Converting between 3-byte and 4-byte Unicode character sets。

运行以下命令来重建此项预检查中提到的表，可将旧的时间类型转换为具有小数秒精度的较新格式。

ALTER TABLE ... ENGINE=InnoDB;

有关重建表的更多信息，请参阅 MySQL 文档中的 ALTER TABLE statement。

重建相关表并重新启动升级后，兼容性检查通过，并支持升级继续进行。

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

预检查级别：错误

在共享表空间中使用了分区表

从 MySQL 8.0.13 开始，不再支持在共享表空间中放置表分区。升级之前，请将任何此类表从共享表空间移至 file-per-table 表空间。

注意

在重建表空间之前，请参阅 MySQL 文档中的 Partitioning operations，来了解锁定和数据移动对前台事务的影响。

输出示例：

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

预检查失败，因为表 test.partInnoDBTable 中的分区 p1 位于系统表空间中。

要解决此问题，请重建 test.partInnodbTable 表，将违规分区 p1 放在 file-per-table 表空间中。

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

完成后，预检查通过。

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

预检查级别：错误

使用了从最新 MySQL 版本中移除的函数

在 MySQL 8.0 中，已移除了许多内置函数。此项预检查会检查数据库中是否存在可能使用这些函数的对象。如果找到此类对象，则将返回错误。在重试升级之前，必须先解决这些问题。

移除的大多数函数是 spatial functions，这些函数已被等效的 ST_* 函数所取代。在这些情况下，可以修改数据库对象来使用新的过程命名。有关更多信息，请参阅 MySQL 文档中的 MySQL 8.0 中删除的功能。

输出示例：

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

预检查报告 test.GetLocationsInPolygon 存储过程正在使用两个已移除的函数：POLYGONFROMTEXT 和 POINTFROMTEXT。它还建议您使用新的 ST_POLYGONFROMTEXT 和 ST_POINTFROMTEXT 作为替换函数。使用建议重新创建该过程后，预检查成功完成。

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

虽然在大多数情况下，弃用的函数有直接的替换函数，但请务必测试您的应用程序并查看文档，来了解由于更改而导致的任何行为变化。

routineSyntaxCheck

预检查级别：错误

MySQL 语法检查是否有类似于例程的对象

MySQL 8.0 引入了以前未保留的 reserved keywords。升级预检查工具将评估保留关键字在数据库对象名称及其定义和正文中的使用情况。如果它检测到数据库对象（例如存储过程、函数、事件和触发器）中正在使用保留关键字，则升级将失败并向 upgrade-prechecks.log 文件中发布一个错误。要解决此问题，必须在升级之前，更新这些对象定义并将所有此类引用括在单引号（'）中。有关在 MySQL 中对保留字进行转义的更多信息，请参阅 MySQL 文档中的 String literals。

或者，可以将名称更改为其它名称，这可能需要更改应用程序。

输出示例：

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

要解决此问题，请检查例程定义。

SHOW CREATE PROCEDURE test.select_res_word\G

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

该过程使用名为 except 的表，这是 MySQL 8.0 中的一个新关键字。通过对字符串文本进行转义来重新创建该过程。

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

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

 > DELIMITER ;

预检查现已通过。

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

预检查级别：错误

文件移除或损坏导致的架构不一致

如前所述，MySQL 8.0 引入了 Atomic Data Dictionary，它将所有元数据存储在 mysql 架构内的一组内部 InnoDB 表中。这种新架构提供了一种事务性、符合 ACID 的方法来管理数据库元数据，解决了基于文件的旧方法中的“原子 DDL”问题。在 MySQL 8.0 之前，如果 DDL 操作意外中断，架构对象可能会变成孤立对象。在升级期间将基于文件的元数据迁移到新的原子数据字典表，可确保数据库实例中没有此类孤立的架构对象。如果遇到任何孤立对象，则升级将失败。

为了有助于在启动升级之前检测这些孤立对象，将运行 schemaInconsistencyCheck 预检查，来确保所有数据字典元数据对象都处于同步状态。如果检测到任何孤立的元数据对象，则升级不会继续。要继续升级，请清理这些孤立的元数据对象。

如果您在此项预检查中遇到任何错误，请向 Amazon Support 提交案例，来请求解决元数据不一致性。或者，可以通过执行逻辑转储，然后还原到新的 Aurora MySQL 版本 3 数据库集群来重试升级。

输出示例：

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

预检查报告 test.schemaInconsistencyCheck_failure 表的元数据不一致。在这种情况下，表存在于 InnoDB 存储引擎元数据 (information_schema.INNODB_SYS_TABLES) 中，但不存在于 MySQL 元数据 (information_schema.TABLES) 中。

报告错误的 Aurora MySQL 预检查

以下预检查特定于 Aurora MySQL：

auroraCheckDDLRecovery

预检查级别：错误

检查是否存在与 Aurora DDL 恢复功能相关的构件

作为 Aurora MySQL 中数据定义语言（DDL）恢复实现的一部分，正在运行的 DDL 语句的元数据保留在 mysql 架构内的 ddl_log_md_table 和 ddl_log_table 表中。Aurora 对于 DDL 恢复的实现在版本 3 及后续版本中不受支持，因为该功能是 MySQL 8.0 中新的 Atomic Data Dictionary 实现的一部分。如果在兼容性检查期间有任何 DDL 语句正在运行，则此项预检查可能会失败。我们建议您在没有任何 DDL 语句正在运行的情况下尝试升级。

如果在没有任何 DDL 语句正在运行的情况下，此项预检查失败，请向 Amazon Support 提交案例，来请求解决元数据不一致问题。或者，可以通过执行逻辑转储，然后还原到新的 Aurora MySQL 版本 3 数据库集群来重试升级。

如果有任何 DDL 语句正在运行，则预检查输出将显示以下消息：

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

输出示例：

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

由于正在运行的 DDL 与兼容性检查同时运行，因此预检查返回了一个错误。我们建议您在没有任何 DDL 正在运行的情况下重试升级。

auroraCheckRdsUpgradePrechecksTable

预检查级别：错误

检查 mysql.rds_upgrade_prechecks 表是否存在

这是 RDS 服务执行的仅限内部的预检查。任何错误都将在升级时自动得以处理，可以安全地忽略。

如果您在此项预检查中遇到任何错误，请向 Amazon Support 提交案例，来请求解决元数据不一致性。或者，可以通过执行逻辑转储，然后还原到新的 Aurora MySQL 版本 3 数据库集群来重试升级。

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

预检查级别：错误

检查是否存在与 Aurora 快速 DDL 功能相关的构件

Aurora MySQL 版本 2 在实验室模式下引入了快速 DDL 优化，来提高某些 DDL 操作的效率。在 Aurora MySQL 版本 3 中，实验室模式已被移除，快速 DDL 实现已被名为 Instant DDL 的 MySQL 8.0 功能所取代。

在升级到 Aurora MySQL 版本 3 之前，任何在实验室模式下使用快速 DDL 的表都必须通过运行 OPTIMIZE TABLE 或 ALTER TABLE ... ENGINE=InnoDB 命令进行重建，以确保与 Aurora MySQL 版本 3 兼容。

此项预检查将返回任何此类表的列表。重建返回的表后，可以重试升级。

输出示例：

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

预检查报告表 test.test 具有待处理的快速 DDL 操作。

要让升级继续进行，可以重建表，然后重试升级。

注意

在重建表空间之前，请参阅 MySQL 文档中的 Online DDL operations，来了解锁定和数据移动对前台事务的影响。

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 #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 时，会创建许多辅助索引表空间。由于 MySQL 的早期版本中存在一个 bug（在 5.6.20 版本中已修复），这些辅助索引表可能是在 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，来了解锁定和数据移动对前台事务的影响。

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

预检查级别：错误

检查 XA 事务是否处于已准备状态

在运行主要版本升级过程时，务必对 Aurora MySQL 版本 2 数据库实例执行 clean shutdown。这可以确保所有事务都已提交或回滚，并且 InnoDB 已清除所有撤消日志记录。由于事务回滚是必需的，因此，如果数据库中有任何 XA transactions 处于已准备状态，则可能会阻止继续进行干净关闭。因此，如果检测到任何已准备的 XA 事务，则在您采取措施来提交或回滚这些事务之前，升级将无法继续。

有关使用 XA RECOVER 查找处于已准备状态的 XA 事务的更多信息，请参阅 MySQL 文档中的 XA transaction SQL statements。有关 XA 事务状态的更多信息，请参阅 MySQL 文档中的 XA transaction states。

输出示例：

{
  "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_schema.innodb_trx 表和 XA RECOVER 输出来获取更多信息。

重要

在提交或回滚事务之前，建议您查看 MySQL documentation 和您的应用程序要求。

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（其中写入器数据库实例类为 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 和 dynamic privileges 的新权限模型，使权限管理变得更简单、更精细。作为此次变更的一部分，Aurora MySQL 引入了新的 rds_superuser_role，从 Aurora MySQL 版本 2 升级到版本 3 时，会自动向数据库的主用户授予此角色。

有关 Aurora MySQL 中分配给主用户的角色和权限的更多信息，请参阅主用户账户权限。有关 Aurora MySQL 版本 3 中基于角色的权限模型的更多信息，请参阅基于角色的权限模型。

此项预检查验证数据库中是否存在主用户。如果主用户不存在，则预检查失败。要让升级继续进行，请通过重置主用户密码或手动创建用户来重新创建主用户。然后重试升级。有关重置主用户密码的更多信息，请参阅更改数据库主用户的密码。

输出示例：

{
  "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 开始，无法再使用 GEOMETRY 数据类型在列上创建 prefixed 索引。有关更多信息，请参阅 WL#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。作为迁移存储过程的一部分，在将每个过程的过程定义和主体摄取到新的数据字典中时，都会对其进行验证。

在 MySQL 8 之前，在某些情况下，可以创建存储例程，或将包含特殊字符的过程直接插入 mysql.proc 表中。例如，可以创建一个存储过程，其中包含带有不合规、不换行空格字符 \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 是 MySQL 数据库中的一组对象和视图，有助于用户对其数据库实例进行故障排除、优化和监控。当执行从 Aurora MySQL 版本 2 到版本 3 的主要版本升级时，将重新创建 sys 架构视图，并将其更新为新的 Aurora MySQL 版本 3 定义。

作为升级的一部分，如果 sys 架构中的任何对象是使用存储引擎（INFORMATION_SCHEMA.TABLES 中的 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_global_by_latency 视图具有类型不匹配，导致无法继续升级。

登录数据库实例后，可以看到此对象被定义为 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 重新创建该视图，也可以对其进行重命名。在升级过程中，将使用正确的表定义自动创建该视图。

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 为 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 对某个列创建索引时，必须在索引定义中添加 prefix 长度。在 MySQL 8.0 之前，在某些情况下，可以指定比此类数据类型支持的最大大小更大的前缀长度。例如 TINYTEXT 和 TINYBLOB 列，其中允许的最大数据大小为 255 字节，但允许使用大于此值的索引前缀。有关更多信息，请参阅 MySQL 文档中的 InnoDB limits。

如果此项预检查失败，请删除违规索引，或将索引的 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 提交案例，来请求解决元数据不一致性。或者，可以通过执行逻辑转储，然后还原到新的 Aurora MySQL 版本 3 数据库集群来重试升级。

警告

以下预检查失败时会生成警告，但升级可以继续。

报告警告的 MySQL 预检查

以下预检查来自社区 MySQL：

defaultAuthenticationPlugin

预检查级别：警告

新的默认身份验证插件注意事项

在 MySQL 8.0 中，引入了 caching_sha2_password 身份验证插件，与已弃用的 mysql_native_password 插件相比，它提供了更安全的密码加密和更好的性能。对于 Aurora MySQL 版本 3，用于数据库用户的默认身份验证插件是 mysql_native_password 插件。

此项预检查警告称，在将来的主要版本中，此插件将被移除并会更改默认插件。请考虑在此项更改之前评估应用程序客户端和用户的兼容性。

有关更多信息，请参阅 MySQL 文档中的 caching_sha2_password compatibility issues and solutions。

输出示例：

{
  "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 了许多已弃用的 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，MySQL 存储在创建或更改例程时生效的 sql_mode 设置。它始终使用此设置运行例程，而不管例程启动时 sql_mode 设置如何。

在更改 sql_mode 之前，请参阅 MySQL 文档中的 Server SQL modes。仔细评估这样做对应用程序产生的任何潜在影响。

在不使用不受支持的 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 开始，弃用将美元符号 ($) 作为未加引号的标识符的第一个字符。如果有任何以 $ 为第一个字符的架构、表、视图、列或例程，则此项预检查会返回警告。虽然此警告不会阻止升级继续进行，但我们建议您尽快采取措施来解决此问题。从 MySQL 8.4 开始，任何此类标识符都将返回语法错误而不是警告。

输出示例：

{
  "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 类似，因为它会检查是否使用了名称与新的保留关键字冲突的数据库对象。虽然它们不会阻止升级，但您需要仔细评估警告。

输出示例：

将前面的示例用于名为 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，则在升级到 MySQL 8.0 之后，这些查询可能会遇到错误。检查应用程序以进行确认，并针对在版本 3 上运行的 Aurora MySQL 数据库集群的克隆或快照进行测试。

升级后将失败的未转义的应用程序查询示例：

SELECT * FROM escape;

升级后将成功执行的经正确转义的应用程序查询示例：

SELECT * FROM 'escape';
utf8mb3Check

预检查级别：警告

使用 utf8mb3 字符集

在 MySQL 8.0 中，utf8mb3 字符集已弃用，并会在将来的 MySQL 主要版本中移除。实现此项预检查是为了在检测到任何使用此字符集的数据库对象时发出警告。虽然这不会阻止升级继续进行，但我们强烈建议您考虑将表迁移到 utf8mb4 字符集，这是 MySQL 8.0 中的默认字符集。有关 utf8mb3 和 utf8mb4 的更多信息，请参阅 MySQL 文档中的 Converting between 3-byte and 4-byte Unicode character sets。

输出示例：

{
  "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。

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

预检查级别：警告

检查集群的回滚段历史记录列表长度是否很高

如在 auroraUpgradeCheckForIncompleteXATransactions 中所提到的那样，在运行主要版本升级过程时，务必对 Aurora MySQL 版本 2 数据库实例执行 clean shutdown。这可以确保所有事务都已提交或回滚，并且 InnoDB 已清除所有撤消日志记录。

如果数据库集群具有较高的回滚段历史记录列表长度（HLL），则可能会延长 InnoDB 完成其清除撤消日志记录所需的时间量，从而导致主要版本升级过程中的停机时间延长。如果预检查检测到数据库集群上的 HLL 很高，则会发出警告。虽然这不会阻止升级继续进行，但建议您密切监控数据库集群上的 HLL。将其保持在较低水平，可以减少主要版本升级期间所需的停机时间。有关监控 HLL 的更多信息，请参阅 InnoDB 历史记录列表长度显著增加。

输出示例：

{
  "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）。尽管升级继续进行，但根据要清除的撤消量，可能会延长升级过程中所需的停机时间。

我们建议您在生产环境中运行升级之前，先调查数据库集群上的未结事务，以确保 HLL 保持为可管理的大小。

auroraUpgradeCheckForUncommittedRowModifications

预检查级别：警告

检查是否有许多未提交的行修改

如在 auroraUpgradeCheckForIncompleteXATransactions 中所提到的那样，在运行主要版本升级过程时，务必对 Aurora MySQL 版本 2 数据库实例执行 clean 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_schema.innodb_trx 表。以下针对写入器数据库实例的查询显示了数据库集群的当前事务、运行时间、状态和修改的行。

# 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。

版权声明

以下预检查失败时会生成通知，但升级可以继续。

sqlModeFlagCheck

预检查级别：通知

使用过时的 sql_mode 标志

除了 MAXDB 外，还 removed 许多其它 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。

输出示例：

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

要解决其中任何预检查失败，请参阅 maxdbFlagCheck。

错误、警告或通知

根据预检查输出，以下预检查可能会返回错误、警告或通知。

checkTableOutput

预检查级别：错误、警告或通知

check table x for upgrade 命令报告的问题

在开始升级到 Aurora MySQL 版本 3 之前，check table for upgrade 会在数据库集群中用户架构的每个表上运行。此项预检查与 checkTableMysqlSchema 不一样。

check table for upgrade 命令检查表中是否存在升级到较新 MySQL 版本期间可能出现的任何潜在问题。在尝试升级之前运行此命令，有助于提前确定和解决任何不兼容性，从而使实际升级过程更加顺畅。

此命令对每个表执行各种检查，例如：

  • 验证表结构和元数据是否与目标 MySQL 版本兼容

  • 检查表是否使用了任何已弃用或已移除的功能

  • 确保表可以正确地升级而不会丢失数据

与其它预检查不同，此项预检查可以根据 check table 输出返回错误、警告或通知。如果此项预检查返回了任何表，请在启动升级之前，仔细查看这些表以及返回代码和消息。有关更多信息，请参阅 MySQL 文档中的 CHECK TABLE statement。

在此，我们提供了一个错误示例和一个警告示例。

错误示例：

{
  "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 的 MySQL 文档指出，外键中引用的列必须具有关联的索引，并且父/子列必须使用相同的数据类型。

要验证这是否与缺失索引或数据类型不匹配有关，请登录数据库，并通过暂时禁用会话变量 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，此消息是信息性的，是针对在 MySQL 5.7.2 之前创建的触发器显示的。

因为这是一个警告，所以它不会阻止升级继续进行。但是，如果您希望解决此问题，可以重新创建这个有问题的触发器，预检查将成功而没有警告。

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