升级到 Aurora MySQL 版本 3 - Amazon Aurora
Aurora MySQL 版本 3 的升级计划使用快照还原方法从 Aurora MySQL 版本 2 升级到版本 3 的示例从 Aurora MySQL 版本 1 升级到版本 3 的示例排查 Aurora MySQL 版本 3 升级问题Aurora MySQL 版本 3 的升级后清理
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

升级到 Aurora MySQL 版本 3

对于将数据库从 Aurora MySQL 版本 1 或 2 升级到版本 3 的特定升级路径，可以使用以下方法之一：

  • 要将 Aurora MySQL 版本 2 集群升级到版本 3，您可以执行就地升级。按照如何执行就地升级中的程序进行操作。

    您还可以创建版本 2 集群的快照，并还原此快照以创建新的版本 3 集群。按照从数据库集群快照还原中的程序进行操作。

  • 要从 Aurora MySQL 版本 1 进行升级，首先进行到 Aurora MySQL 版本 2 的中间升级。使用 升级 Amazon Aurora MySQL 数据库集群 中的任何升级方法。

    然后，从 Aurora MySQL 版本 2 升级到 Aurora MySQL 版本 3。无法直接从 Aurora MySQL 版本 1 集群（与 MySQL 5.6 兼容）升级到 Aurora MySQL 版本 3。

提示

在某些情况下，您可以指定在升级时将数据库日志上载到 CloudWatch 的选项。若如此，请检查 CloudWatch 中的日志，以诊断升级操作期间出现的任何问题。此部分中的 CLI 示例演示如何使用 --enable-cloudwatch-logs-exports 选项执行此操作。

Aurora MySQL 版本 3 的升级计划

为了帮助您决定正确的升级时间和方法，您可以了解 Aurora MySQL 版本 3 与当前的 Aurora 和 MySQL 环境之间的区别：

  • 如果您要从 RDS for MySQL 8.0 或 MySQL 8.0 社区版进行转换，请参阅比较 Aurora MySQL 版本 3 和 MySQL 8.0 社群版。

  • 如果您要从 Aurora MySQL 版本 2、RDS for MySQL 5.7 或社群 MySQL 5.7 升级，请参阅 比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3。

  • 为任何自定义参数组创建新的 MySQL 8.0 兼容版本。将所有必要的自定义参数值应用于新参数组。咨询 Aurora MySQL 版本 3 的参数更改 以了解参数更改。

    注意

    对于大多数参数设置，您可以在两个点选择自定义参数组。也即，在您创建集群或稍后将参数组与集群关联时。

    但是，如果您将非原定设置设置用于 lower_case_table_names 参数，则必须提前使用此设置来设置自定义参数组。然后，在执行快照还原操作以创建集群时指定参数组。创建集群后，lower_case_table_names 参数的任何更改不会产生任何影响。

    我们建议您在从 Aurora MySQL 版本 2 升级到版本 3 时对 lower_case_table_names 使用相同的设置。

  • 请查看您的 Aurora MySQL 版本 2 数据库架构和对象定义，以了解 MySQL 8.0 社区版中引入的新保留关键字的使用情况。请在升级之前执行此操作。有关更多信息，请参阅 MySQL 文档中的 MySQL 8.0 新关键字和保留关键字。

您还可以在 MySQL 参考手册的 MySQL 8.0 中的变化中找到更多特定于 MySQL 的升级注意事项和提示。例如，您可以使用命令 mysqlcheck --check-upgrade 来分析现有的 Aurora MySQL 数据库并确定潜在的升级问题。

要从 Aurora MySQL 版本 1 进行升级，请使用两步过程。首先升级到 Aurora MySQL 版本 2，然后升级到 Aurora MySQL 版本 3。有关从 Aurora MySQL 版本 1 或 2 的升级过程，请参阅 升级到 Aurora MySQL 版本 3。您可以使用就地升级或快照还原方法。

注意

在使用就地升级或快照还原技术升级到 Aurora MySQL 版本 3 时，我们建议使用更大的数据库实例类。例如，db.r5.24xlarge 和 db.r6g.16xlarge。这样，通过使用数据库实例上的绝大部分可用 CPU 容量，有助于更快地完成升级过程。在主要版本升级完成后，您可以更改为所需的数据库实例类。

完成升级后，您可以按照 Aurora MySQL 版本 3 的升级后清理 中的升级后步骤进行操作。最后，测试应用程序的功能和性能。

如果要从 MySQL 或社群 MySQL 进行 RDS 转换，请按照 将数据迁移到 Amazon Aurora MySQL 数据库集群 中所述的迁移过程进行操作。在某些情况下，作为迁移的一部分，您可以使用二进制日志复制将数据与 Aurora MySQL 版本 3 集群同步数据。如果是这样，源系统必须运行与 MySQL 5.7 兼容的版本，或者是 8.0.23 或更低的与 MySQL 8.0 兼容的版本。

使用快照还原方法从 Aurora MySQL 版本 2 升级到版本 3 的示例

以下 Amazon CLI 示例演示了将 Aurora MySQL 版本 2 集群升级到 Aurora MySQL 版本 3 的步骤。

第一步是确定要升级的集群版本。以下 Amazon CLI 命令显示如何操作。输出确认原始集群是一个与 MySQL 5.7 兼容的集群（运行 Aurora MySQL 版本 2.09.2 的集群）。

此集群至少包含一个数据库实例。为了使升级过程正常运行，此原始集群需要一个写入器实例。

$ aws rds describe-db-clusters --db-cluster-id cluster-57-upgrade-ok \
  --query '*[].EngineVersion' --output text

5.7.mysql_aurora.2.09.2

以下命令显示如何检查特定版本中可用的升级路径。在此情况下，原始集群在运行版本 5.7.mysql_aurora.2.09.2。输出显示，此版本可以升级到 Aurora MySQL 版本 3。

如果原始集群使用的版本号太低而无法升级到 Aurora MySQL 版本 3，则升级需要额外的步骤。首先，还原快照以创建可升级到 Aurora MySQL 版本 3 的新集群。然后，拍摄该中间集群的快照。最后，还原中间集群的快照以创建新的 Aurora MySQL 版本 3 集群。

$ aws rds describe-db-engine-versions --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.09.2 \
  --query 'DBEngineVersions[].ValidUpgradeTarget[].EngineVersion'
[
    "5.7.mysql_aurora.2.09.3",
    "5.7.mysql_aurora.2.10.0",
    "5.7.mysql_aurora.2.10.1",
    "5.7.mysql_aurora.2.10.2",
    "8.0.mysql_aurora.3.01.1",
    "8.0.mysql_aurora.3.02.0"
]

以下命令将创建集群的快照以升级到 Aurora MySQL 版本 3。原始集群将保持不变。稍后，您可以从快照中创建一个新的 Aurora MySQL 版本 3 集群。

aws rds create-db-cluster-snapshot --db-cluster-id cluster-57-upgrade-ok \
  --db-cluster-snapshot-id cluster-57-upgrade-ok-snapshot
{
  "DBClusterSnapshotIdentifier": "cluster-57-upgrade-ok-snapshot",
  "DBClusterIdentifier": "cluster-57-upgrade-ok",
  "SnapshotCreateTime": "2021-10-06T23:20:18.087000+00:00"
}

以下命令将快照还原到运行 Aurora MySQL 版本 3 的新集群。

$ aws rds restore-db-cluster-from-snapshot \
  --snapshot-id cluster-57-upgrade-ok-snapshot \
  --db-cluster-id cluster-80-restored --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.02.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
  "DBClusterIdentifier": "cluster-80-restored",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "Status": "creating"
}

还原快照可设置集群的存储空间并建立集群可以使用的数据库版本。集群的计算容量与存储是分开的。因此，在创建集群本身后，您可以为集群设置任何数据库实例。以下示例使用其中一个 db.r5 实例类创建一个写入器数据库实例。

提示

您可能拥有使用 db.r3、db.r4、db.t2 或 db.t3 之类较旧的实例类创建数据库实例的管理脚本。如果是这样，请修改脚本以使用 Aurora MySQL 版本 3 支持的其中一个实例类。有关可用于 Aurora MySQL 版本 3 的实例类的信息，请参阅 实例类支持。

$ aws rds create-db-instance --db-instance-identifier instance-running-version-3 \
  --db-cluster-identifier cluster-80-restored \
  --db-instance-class db.r5.xlarge --engine aurora-mysql
{
  "DBInstanceIdentifier": "instance-running-version-3",
  "DBClusterIdentifier": "cluster-80-restored",
  "DBInstanceClass": "db.r5.xlarge",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceStatus": "creating"
}

升级完成后，您可以使用 Amazon CLI 验证集群的特定于 Aurora 的版本号。

$ aws rds describe-db-clusters --db-cluster-id cluster-80-restored \
  --query '*[].EngineVersion' --output text
8.0.mysql_aurora.3.02.0

您还可以通过调用 version 函数来验证数据库引擎特定于 MySQL 的版本。

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.23    |
+-----------+

从 Aurora MySQL 版本 1 升级到版本 3 的示例

以下示例显示了如果原始快照来自无法直接还原到 Aurora MySQL 版本 3 的版本，则分两阶段的升级过程。相反，该快照将还原到运行中间版本的集群中，您可以将其升级到 Aurora MySQL 版本 3。此中间集群不需要任何关联的数据库实例。然后，从中间集群创建另一个快照。最后，还原第二个快照以创建新的 Aurora MySQL 版本 3 集群和写入器数据库实例。

我们开始使用的 Aurora MySQL 版本 1 集群被命名为 aurora-mysql-v1-to-v2。它运行的是 Aurora MySQL 版本 1.23.4。该集群至少包含一个数据库实例。

此示例检查哪些 Aurora MySQL 版本 2 版本可以升级到 8.0.mysql_aurora.3.02.0 版本，以在升级后的集群上使用。在此示例中，我们选择版本 2.10.2 作为中间版本。

$ aws rds describe-db-engine-versions --engine aurora-mysql \
  --query '*[].{EngineVersion:EngineVersion,TargetVersions:ValidUpgradeTarget[*].EngineVersion} |
    [?contains(TargetVersions, `'8.0.mysql_aurora.3.02.0'`) == `true`]|[].EngineVersion' \
  --output text
...
5.7.mysql_aurora.2.08.3
5.7.mysql_aurora.2.09.1
5.7.mysql_aurora.2.09.2
5.7.mysql_aurora.2.10.0
5.7.mysql_aurora.2.10.1
5.7.mysql_aurora.2.10.2
...

以下示例验证 Aurora MySQL 版本 1.23.4 到 2.10.2 是否为可用的升级路径。因此，我们运行的 Aurora MySQL 版本可以升级到 2.10.2。然后，该集群可以升级到 3.02.0。

aws rds describe-db-engine-versions --engine aurora \
  --query '*[].{EngineVersion:EngineVersion,TargetVersions:ValidUpgradeTarget[*].EngineVersion} |
    [?contains(TargetVersions, `'5.7.mysql_aurora.2.10.2'`) == `true`]|[].[EngineVersion]' \
  --output text
...
5.6.mysql_aurora.1.22.5
5.6.mysql_aurora.1.23.0
5.6.mysql_aurora.1.23.1
5.6.mysql_aurora.1.23.2
5.6.mysql_aurora.1.23.3
5.6.mysql_aurora.1.23.4
...

以下示例将创建一个名为 aurora-mysql-v1-to-v2-snapshot 的快照，该快照基于原始的 Aurora MySQL 版本 1 集群。

$ aws rds create-db-cluster-snapshot \
  --db-cluster-id aurora-mysql-v1-to-v2 \
  --db-cluster-snapshot-id aurora-mysql-v1-to-v2-snapshot
{
  "DBClusterSnapshotIdentifier": "aurora-mysql-v1-to-v2-snapshot",
  "DBClusterIdentifier": "aurora-mysql-v1-to-v2"
}

以下示例从版本 1 快照创建中间 Aurora MySQL 版本 2 集群。此中间集群名为 aurora-mysql-v2-to-v3。它运行的是 Aurora MySQL 版本 2.10.2。

$ aws rds restore-db-cluster-from-snapshot \
  --snapshot-id aurora-mysql-v1-to-v2-snapshot \
  --db-cluster-id aurora-mysql-v2-to-v3 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
    "DBCluster": {
        "AllocatedStorage": 1,
        "AvailabilityZones": [
            "us-east-1a",
            "us-east-1d",
            "us-east-1f"
        ],
...

以下示例从中间 Aurora MySQL 版本 2 集群创建快照。此快照名为 aurora-mysql-v2-to-v3-snapshot。它是为了创建 Aurora MySQL 版本 3 集群而要还原的快照。

$ aws rds create-db-cluster-snapshot \
  --db-cluster-id aurora-mysql-v2-to-v3 \
  --db-cluster-snapshot-id aurora-mysql-v2-to-v3-snapshot
{
  "DBClusterSnapshotIdentifier": "aurora-mysql-v2-to-v3-snapshot",
  "DBClusterIdentifier": "aurora-mysql-v2-to-v3"
}

以下命令将创建 Aurora MySQL 版本 3 集群。此集群名为 aurora-mysql-v3-fully-upgraded。

$ aws rds restore-db-cluster-from-snapshot \
  --snapshot-id aurora-mysql-v2-to-v3-snapshot \
  --db-cluster-id aurora-mysql-v3-fully-upgraded \
  --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.02.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
    "DBCluster": {
        "AllocatedStorage": 1,
        "AvailabilityZones": [
            "us-east-1b",
            "us-east-1c",
            "us-east-1d"
        ],
...

现在已创建了 Aurora MySQL 版本 3 集群，下面的示例为其创建了一个写入器数据库实例。当集群和写入器实例变为可用时，您可以连接到集群并开始使用它。来自原始集群的所有数据都会在每个快照阶段保留。

$ aws rds create-db-instance \
  --db-instance-identifier instance-also-running-v3 \
  --db-cluster-identifier aurora-mysql-v3-fully-upgraded \
  --db-instance-class db.r5.xlarge --engine aurora-mysql
{
  "DBInstanceIdentifier": "instance-also-running-v3",
  "DBClusterIdentifier": "aurora-mysql-v3-fully-upgraded",
  "DBInstanceClass": "db.r5.xlarge",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceStatus": "creating"
}

排查 Aurora MySQL 版本 3 升级问题

如果升级到 Aurora MySQL 版本 3 未成功完成，您可以诊断问题的原因。然后，您可以对原始数据库架构或表数据进行任何必要的更改，然后再次运行升级过程。

如果在升级到 Aurora MySQL 版本 3 期间失败，则会在为还原的快照创建并升级写入器实例时检测到问题。Aurora 会遗留与 5.7 兼容的原始写入器实例。这样，您可以在执行升级之前从 Aurora 运行的初步检查中检查日志。以下示例从与 5.7 兼容的数据库开始，该数据库需要进行一些更改才能升级到 Aurora MySQL 版本 3。这些示例演示了首次尝试升级失败的方式以及如何检查日志文件。它们还展示了如何修复问题并运行成功的升级。

首先创建一个与 MySQL 5.7 兼容的新集群，名为 problematic-57-80-upgrade。顾名思义，此集群至少包含一个在升级到 MySQL 8.0 兼容版本期间会产生问题的架构对象。

$ aws rds create-db-cluster --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.10.0 \
  --db-cluster-identifier problematic-57-80-upgrade \
  --master-username my_username \
  --master-user-password my_password
{
  "DBClusterIdentifier": "problematic-57-80-upgrade",
  "Status": "creating"
}

$ aws rds create-db-instance \
  --db-instance-identifier instance-preupgrade \
  --db-cluster-identifier problematic-57-80-upgrade \
  --db-instance-class db.t2.small --engine aurora-mysql
{
  "DBInstanceIdentifier": "instance-preupgrade",
  "DBClusterIdentifier": "problematic-57-80-upgrade",
  "DBInstanceClass": "db.t2.small",
  "DBInstanceStatus": "creating"
}

$ aws rds wait db-instance-available \
  --db-instance-identifier instance-preupgrade

在打算升级的集群中引入一个有问题的表。创建 FULLTEXT 索引再删除索引，会遗留一些在升级期间导致问题的元数据。

$ mysql -u my_username -p \
  -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com

mysql> create database problematic_upgrade;
Query OK, 1 row affected (0.02 sec)

mysql> use problematic_upgrade;
Database changed
mysql> CREATE TABLE dangling_fulltext_index
    ->   (id INT AUTO_INCREMENT PRIMARY KEY, txtcol TEXT NOT NULL)
    ->   ENGINE=InnoDB;
Query OK, 0 rows affected (0.05 sec)

mysql> ALTER TABLE dangling_fulltext_index ADD FULLTEXT(txtcol);
Query OK, 0 rows affected, 1 warning (0.14 sec)

mysql> ALTER TABLE dangling_fulltext_index DROP INDEX txtcol;
Query OK, 0 rows affected (0.06 sec)

此示例尝试执行升级过程。我们制作原始集群的快照，再等待快照创建完成。然后还原快照，指定与 MySQL 8.0 兼容的版本号。我们还为集群创建了写入器实例。此时会发生升级处理。然后等待写入器实例可用。无论成败与否，升级过程会在此时结束。

提示

如果使用 Amazon Web Services Management Console 还原快照，Aurora 会自动创建写入器实例，然后将其升级至请求的引擎版本。

$ aws rds create-db-cluster-snapshot --db-cluster-id problematic-57-80-upgrade \
  --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot
{
  "DBClusterSnapshotIdentifier": "problematic-57-80-upgrade-snapshot",
  "DBClusterIdentifier": "problematic-57-80-upgrade",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.0"
}

$ aws rds wait db-cluster-snapshot-available \
  --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot

$ aws rds restore-db-cluster-from-snapshot \
  --snapshot-id problematic-57-80-upgrade-snapshot \
  --db-cluster-id cluster-80-attempt-1 --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.02.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
  "DBClusterIdentifier": "cluster-80-attempt-1",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "Status": "creating"
}

$ aws rds create-db-instance --db-instance-identifier instance-attempt-1 \
  --db-cluster-identifier cluster-80-attempt-1 \
  --db-instance-class db.r5.xlarge --engine aurora-mysql
{
  "DBInstanceIdentifier": "instance-attempt-1",
  "DBClusterIdentifier": "cluster-80-attempt-1",
  "DBInstanceClass": "db.r5.xlarge",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceStatus": "creating"
}

$ aws rds wait db-instance-available \
  --db-instance-identifier instance-attempt-1

现在检查新创建的集群和关联的实例，验证升级是否成功。集群和实例仍在运行与 MySQL 5.7 兼容的版本。这意味着升级失败。如果升级失败，Aurora 仅遗留写入器实例，以便您检查任何日志文件。您无法使用新创建的集群重新启动升级过程。通过更改原始集群解决问题后，您必须再次运行升级步骤：为原始集群制作新快照，再将其还原到另一个与 MySQL 8.0 兼容的集群。

$ aws rds describe-db-clusters \
  --db-cluster-identifier cluster-80-attempt-1 \
  --query '*[].[Status]' --output text
available
$ aws rds describe-db-clusters \
  --db-cluster-identifier cluster-80-attempt-1 \
  --query '*[].[EngineVersion]' --output text
5.7.mysql_aurora.2.10.0

$ aws rds describe-db-instances \
  --db-instance-identifier instance-attempt-1 \
  --query '*[].{DBInstanceStatus:DBInstanceStatus}' --output text
available
$ aws rds describe-db-instances \
  --db-instance-identifier instance-attempt-1 \
  --query '*[].[EngineVersion]' --output text
5.7.mysql_aurora.2.10.0

为了获得升级过程中所发生情况的摘要，我们将得到新创建的写入器实例的事件列表。在此示例中，我们列出了过去 600 分钟内的事件，涵盖升级过程的整个时间间隔。列表中的事件不一定按时间顺序排列。突出显示的事件显示了确认集群无法升级的问题。

$ aws rds describe-events \
  --source-identifier instance-attempt-1 --source-type db-instance \
  --duration 600
{
    "Events": [
        {
            "SourceIdentifier": "instance-attempt-1",
            "SourceType": "db-instance",
            "Message": "Binlog position from crash recovery is mysql-bin-changelog.000001 154",
            "EventCategories": [],
            "Date": "2021-12-03T20:26:17.862000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1"
        },
        {
            "SourceIdentifier": "instance-attempt-1",
            "SourceType": "db-instance",
            "Message": "Database cluster is in a state that cannot be upgraded:
PreUpgrade checks failed: Oscar PreChecker Found 1 errors",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2021-12-03T20:26:50.436000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1"
        },
        {
            "SourceIdentifier": "instance-attempt-1",
            "SourceType": "db-instance",
            "Message": "DB instance created",
            "EventCategories": [
                "creation"
            ],
            "Date": "2021-12-03T20:26:58.830000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1"
        },
...

若要诊断问题的确切原因，请检查新创建的写入器实例的数据库日志。如果升级至与 8.0 兼容的版本失败，实例将包含一个文件名为 upgrade-prechecks.log 的日志文件。此示例说明了如何检测该日志是否存在，然后将其下载到本地文件以供检查。

$ aws rds describe-db-log-files --db-instance-identifier instance-attempt-1 \
  --query '*[].[LogFileName]' --output text
error/mysql-error-running.log
error/mysql-error-running.log.2021-12-03.20
error/mysql-error-running.log.2021-12-03.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log

$ aws rds download-db-log-file-portion --db-instance-identifier instance-attempt-1 \
  --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 升级，此日志始终包含某些信息和警告消息。如果升级失败，日志仅包含错误消息。如果升级成功，则根本不会生成日志文件。以下节选内容显示了您可以查找的条目类型。

$ cat upgrade-prechecks.log
{
    "serverAddress": "/tmp%2Fmysql.sock",
    "serverVersion": "5.7.12",
    "targetVersion": "8.0.23",
    "auroraServerVersion": "2.10.0",
    "auroraTargetVersion": "3.02.0",
    "outfilePath": "/rdsdbdata/tmp/PreChecker.log",
    "checksPerformed": [

如果 "detectedProblems" 为空，则说明升级并未遇到任何此类问题。您可以忽略这些条目。

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

检查已删除变量或已更改默认值不会自动执行。Aurora 使用参数组机制，而不是物理配置文件。无论变量更改是否对数据库产生任何影响，您始终会收到一些带有 CONFIGURATION_ERROR 状态的消息。您可以查阅 MySQL 文档，了解有关这些更改的详细信息。

{
    "id": "removedSysLogVars",
    "title": "Removed system variables for error logging to the system log configuration",
    "status": "CONFIGURATION_ERROR",
    "description": "To run this check requires full path to MySQL server
configuration file to be specified at 'configPath' key of options dictionary",
    "documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-logging"
},

如果参数组中的 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"
        }
    ]
},

如果 detectedProblems 字段包含 level 值为 Error 的条目，表示只有解决这些问题，升级才能成功。

{
    "id": "getDanglingFulltextIndex",
    "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": "problematic_upgrade.dangling_fulltext_index",
           "description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
        }
    ]
},
提示

要汇总这些错误并显示关联的对象和描述字段，您可以对 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."

对于 Aurora MySQL 版本 3 升级，defaultAuthenticationPlugin 检查始终显示此警告消息。这是因为 Aurora MySQL 版本 3 使用 mysql_native_password 插件而不是 caching_sha2_password。您无需针对此警告采取任何措施。

{
    "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
...
    "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"
}

upgrade-prechecks.log 文件末尾总结了每种类型的轻微或严重问题遇到的检查次数。非零 errorCount 表示升级失败。

    ],
    "errorCount": 1,
    "warningCount": 2,
    "noticeCount": 0,
    "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues."
}

下一组示例演示了如何修复此特定问题并再次运行升级过程。此次升级成功。

首先，我们回到原始集群。然后，我们对这些表运行 OPTIMIZE TABLE tbl_name [, tbl_name] ...，这会导致以下错误：

Table `tbl_name` contains dangling FULLTEXT index. Kindly recreate the table before upgrade.

$ mysql -u my_username -p \
  -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com
mysql> show databases;
+---------------------+
| Database            |
+---------------------+
| information_schema  |
| mysql               |
| performance_schema  |
| problematic_upgrade |
| sys                 |
+---------------------+
5 rows in set (0.00 sec)
mysql> use problematic_upgrade;
mysql> show tables;
+-------------------------------+
| Tables_in_problematic_upgrade |
+-------------------------------+
| dangling_fulltext_index       |
+-------------------------------+
1 row in set (0.00 sec)
mysql> OPTIMIZE TABLE dangling_fulltext_index;
Query OK, 0 rows affected (0.05 sec)

有关更多信息，请参阅 MySQL 文档中的优化 InnoDB 全文索引和 OPTIMIZE TABLE 语句。

作为替代解决方案，您可以创建一个新表，其结构和内容与具有错误元数据的表相同。实际上，您可能会在升级后将此表重命名为原始表名。

$ mysql -u my_username -p \
  -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com

mysql> show databases;
+---------------------+
| Database            |
+---------------------+
| information_schema  |
| mysql               |
| performance_schema  |
| problematic_upgrade |
| sys                 |
+---------------------+
5 rows in set (0.00 sec)

mysql> use problematic_upgrade;
mysql> show tables;
+-------------------------------+
| Tables_in_problematic_upgrade |
+-------------------------------+
| dangling_fulltext_index       |
+-------------------------------+
1 row in set (0.00 sec)

mysql> desc dangling_fulltext_index;
+--------+---------+------+-----+---------+----------------+
| Field  | Type    | Null | Key | Default | Extra          |
+--------+---------+------+-----+---------+----------------+
| id     | int(11) | NO   | PRI | NULL    | auto_increment |
| txtcol | text    | NO   |     | NULL    |                |
+--------+---------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

mysql> CREATE TABLE recreated_table LIKE dangling_fulltext_index;
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO recreated_table SELECT * FROM dangling_fulltext_index;
Query OK, 0 rows affected (0.00 sec)

mysql> drop table dangling_fulltext_index;
Query OK, 0 rows affected (0.05 sec)

现在我们要经历与以前相同的过程。从原始集群创建快照，并将快照还原为与 MySQL 8.0 兼容的新集群。然后，我们创建一个写入器实例来完成升级过程。

$ aws rds create-db-cluster-snapshot --db-cluster-id problematic-57-80-upgrade \
  --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot-2
{
  "DBClusterSnapshotIdentifier": "problematic-57-80-upgrade-snapshot-2",
  "DBClusterIdentifier": "problematic-57-80-upgrade",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.0"
}

$ aws rds wait db-cluster-snapshot-available \
  --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot-2

$ aws rds restore-db-cluster-from-snapshot \
  --snapshot-id problematic-57-80-upgrade-snapshot-2 \
  --db-cluster-id cluster-80-attempt-2 --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.02.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
  "DBClusterIdentifier": "cluster-80-attempt-2",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "Status": "creating"
}

$ aws rds create-db-instance --db-instance-identifier instance-attempt-2 \
  --db-cluster-identifier cluster-80-attempt-2 \
  --db-instance-class db.r5.xlarge --engine aurora-mysql
{
  "DBInstanceIdentifier": "instance-attempt-2",
  "DBClusterIdentifier": "cluster-80-attempt-2",
  "DBInstanceClass": "db.r5.xlarge",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceStatus": "creating"
}

$ aws rds wait db-instance-available \
  --db-instance-identifier instance-attempt-2

这次，在升级完成后检查版本会确认版本号已更改，可反映 Aurora MySQL 版本 3。我们可以连接到数据库，可以确认 MySQL 引擎版本是与 8.0 兼容的版本。确认升级后的集群包含导致原始升级问题的表的固定版本。

$ aws rds describe-db-clusters \
  --db-cluster-identifier cluster-80-attempt-2 \
  --query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.02.0
$ aws rds describe-db-instances \
  --db-instance-identifier instance-attempt-2 \
  --query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.02.0

$ mysql -h cluster-80-attempt-2.cluster-example123.us-east-1.rds.amazonaws.com \
  -u my_username -p

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.23    |
+-----------+
1 row in set (0.00 sec)

mysql> show databases;
+---------------------+
| Database            |
+---------------------+
| information_schema  |
| mysql               |
| performance_schema  |
| problematic_upgrade |
| sys                 |
+---------------------+
5 rows in set (0.00 sec)

mysql> use problematic_upgrade;
Database changed
mysql> show tables;
+-------------------------------+
| Tables_in_problematic_upgrade |
+-------------------------------+
| recreated_table               |
+-------------------------------+
1 row in set (0.00 sec)

Aurora MySQL 版本 3 的升级后清理

将任何 Aurora MySQL 版本 1 或 2 集群升级到 Aurora MySQL 版本 3 后，您可以执行以下其他清理操作：

  • 为任何自定义参数组创建与 MySQL 8.0 兼容的新版本。将所有必要的自定义参数值应用于新参数组。

  • 更新任何 CloudWatch 告警、设置脚本等，以便对名称受到包含性语言更改影响的任何指标使用新名称。有关此类指标的列表，请参阅 Aurora MySQL 版本 3 的包容性语言更改。

  • 更新任何 Amazon CloudFormation 模板，以对名称受到包含性语言更改影响的任何配置参数使用新名称。有关此类参数的列表，请参阅 Aurora MySQL 版本 3 的包容性语言更改。

空间索引

升级到 Aurora MySQL 版本 3 后，检查是否需要删除或重新创建与空间索引相关的对象和索引。在 MySQL 8.0 之前，Aurora 可以使用不包含空间资源标识符 (SRID) 的索引来优化空间查询。Aurora MySQL 版本 3 仅使用包含 SRID 的空间索引。在升级过程中，Aurora 会自动删除任何没有 SRID 的空间索引，并在数据库日志中打印警告消息。如果观察到此类警告消息，请在升级后使用 SRID 创建新的空间索引。有关 MySQL 8.0 中空间函数和数据类型更改的更多信息，请参阅 MySQL 参考手册中的 MySQL 8.0 中的变化。