升级和修补 Amazon Aurora MySQL 数据库集群 - Amazon Aurora
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

升级和修补 Amazon Aurora MySQL 数据库集群

可以使用以下方法升级数据库集群的次要版本或修补数据库集群:

有关零停机时间修补如何减少升级过程中的中断的信息,请参阅零停机时间修补

通过修改引擎版本来升级 Aurora MySQL

升级 Aurora MySQL 集群的次要版本会将其他修复和新功能应用于现有集群。您可以对运行 Amazon Aurora MySQL 版本 1.19.0 及更高版本或 2.03.2 及更高版本的集群执行这种类型的升级。

这种升级适用于原始版本和升级版本均在 Aurora MySQL 1.x 系列中或均在 Aurora MySQL 2.x 系列中的 Aurora MySQL 集群。这个过程快速而直接,因为它不涉及 Aurora MySQL 元数据的任何转换或表数据的重组。

您可以通过使用 AWS 管理控制台、AWS CLI 或 RDS API 修改数据库集群的引擎版本来执行这种升级。如果您的集群正在运行 Aurora MySQL 1.x,请选择更高的 1.x 版本。如果您的集群正在运行 Aurora MySQL 2.x,请选择更高的 2.x 版本。

修改数据库集群的引擎版本

  • 通过使用 Amazon RDS 控制台 – 修改集群的属性。在修改数据库集群窗口中,更改数据库引擎版本框中的 Aurora MySQL 引擎版本。如果您不熟悉修改集群的一般过程,请按照使用控制台、CLI 和 API 修改数据库集群中的说明操作。

  • 通过使用 AWS CLI – 调用 modify-db-cluster AWS CLI 命令,为 --db-cluster-identifier 选项指定数据库集群的名称,并为 --engine-version 选项指定引擎版本。

    例如,要升级到 Aurora MySQL 版本 2.03.2,请将 --engine-version 选项设置为 5.7.mysql_aurora.2.03.2。指定 --apply-immediately 选项可立即更新数据库集群的引擎版本。

  • 通过使用 RDS API – 调用 ModifyDBCluster API 操作,为 DBClusterIdentifier 参数指定数据库集群的名称,并为 EngineVersion 参数指定引擎版本。将 ApplyImmediately 参数设置为 true 可立即更新数据库集群的引擎版本。

启用 Aurora MySQL 次要版本之间的自动升级

对于运行 Aurora MySQL 版本 2 的 Amazon Aurora MySQL 数据库集群,您可以指定在新的次要版本发布时 Aurora 自动将该数据库集群升级到这些版本。为此,您可以使用 AWS 管理控制台、AWS CLI 或 RDS API 启用数据库集群的自动次要版本升级属性。

自动升级会在数据库的维护时段进行。

重要

在 2020 年 8 月之前,您可以为属于 Aurora MySQL 数据库集群的数据库实例指定该设置,但该设置无效。现在,该设置确实应用于 Aurora MySQL。如果您在 2020 年 8 月之前创建了集群,请检查集群中的数据库实例是否已启用了启用自动次要版本升级设置。如果已启用,请确认该设置仍然适用,否则请进行更改。Aurora 仅在集群中的所有数据库实例均启用了该设置时才执行自动升级。

目前,自动次要版本升级会将 Aurora MySQL 1.x 集群的引擎版本更改为 1.22.2,将 Aurora MySQL 2.x 集群的引擎版本更改为 2.07.2。

自动次要版本升级不适用于运行 Aurora MySQL 1.x 或 2.x 的 LTS 版本的集群。Aurora 不会自动升级运行 2.04.9、1.19.6 或这些次要版本的其他补丁级别的集群。

自动次要版本升级不适用于以下类型的 Aurora MySQL 集群:

  • 多主集群。

  • 属于 Aurora 全局数据库的集群。

  • 具有跨区域副本的集群。

如果一个集群中的任何数据库实例未启用自动次要版本升级设置,则 Aurora 就不会自动升级该集群中的任何实例。确保集群中的所有数据库实例的该设置保持一致。

中断持续时间因工作负载、集群大小、二进制日志数据量以及 Aurora 是否可以使用零停机时间修补 (ZDP) 功能而异。Aurora 会重新启动数据库集群,因此在恢复使用集群之前,您可能会经历短暂的不可用期。特别是,二进制日志数据量会影响恢复时间。数据库实例在恢复期间处理二进制日志数据。因此,大量的二进制日志数据会增加恢复时间。

为 Aurora MySQL 数据库集群启用自动次要版本升级

  • 按照一般过程修改集群中的数据库实例,如修改数据库集群中的数据库实例中所述。对集群中的每个数据库实例重复此过程。

  • 通过使用 Amazon RDS 控制台 – 完成以下步骤:

    1. 登录 Amazon RDS 控制台,然后选择 Databases (数据库)

    2. 找到要启用或禁用自动次要版本升级的数据库集群。

    3. 选择要修改的数据库集群中的每个数据库实例。按顺序对每个数据库实例应用以下更改。

      • 选择修改

      • 选择启用自动次要版本升级设置。此设置是维护部分的一部分。

      • 选择继续,查看修改摘要。

      • (可选)选择立即应用以立即应用更改。

      • 在确认页面上,选择修改数据库实例

  • 通过使用 AWS CLI – 调用 modify-db-instance AWS CLI 命令。为 --db-instance-identifier 选项指定数据库实例的名称,为 --auto-minor-version-upgrade 选项指定 true。(可选)指定 --apply-immediately 选项,立即为数据库实例启用此设置。为集群中的每个数据库实例运行单独的 modify-db-instance 命令。

  • 通过使用 RDS API – 调用 ModifyDBInstance API 操作,并为 DBInstanceIdentifier 参数指定数据库集群的名称,为 AutoMinorVersionUpgrade 参数指定 true。(可选)将 ApplyImmediately 参数设置为 true,立即为数据库实例启用此设置。为集群中的每个数据库实例调用单独的 ModifyDBInstance 操作。

您可以使用如下 AWS CLI 命令来检查 Aurora MySQL 集群中所有数据库实例的启用自动次要版本升级状态。

aws rds describe-db-instances \ --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

该命令产生的输出类似于以下内容。

[ { "DBInstanceIdentifier": "db-t2-medium-instance", "DBClusterIdentifier": "cluster-57-2020-06-03-6411", "AutoMinorVersionUpgrade": true }, { "DBInstanceIdentifier": "db-t2-small-original-size", "DBClusterIdentifier": "cluster-57-2020-06-03-6411", "AutoMinorVersionUpgrade": false }, { "DBInstanceIdentifier": "instance-2020-04-11-5110", "DBClusterIdentifier": "tpch100g", "AutoMinorVersionUpgrade": false }, { "DBInstanceIdentifier": "instance-2020-05-01-2332", "DBClusterIdentifier": "cluster-57-2020-05-01-4615", "AutoMinorVersionUpgrade": true }, ... output omitted ...

通过向 Aurora MySQL 数据库集群应用待执行的维护来升级 Aurora MySQL

在升级到 Aurora MySQL 版本 1.x 版本时,新数据库引擎次要版本和修补程序显示为数据库集群的可用维护升级。可以通过应用可用的维护操作来升级或修补数据库集群的数据库版本。我们建议先对非生产数据库集群应用更新,以便了解新版本的变化如何影响实例和应用程序。

应用待执行的维护操作

  • 通过使用 Amazon RDS 控制台 – 完成以下步骤:

    1. 登录 Amazon RDS 控制台,然后选择 Databases (数据库)

    2. 选择显示 available 维护升级的数据库集群。

    3. 对于 Actions (操作),选择 Upgrade now (立即升级) 以立即更新数据库集群的数据库版本,或选择 Upgrade at next window (在下一个窗口升级) 以在下一个数据库集群维护时段内更新数据库集群的数据库版本。

  • 使用 AWS CLI – 调用 apply-pending-maintenance-action AWS CLI 命令,为 --resource-id 选项指定数据库集群的 Amazon 资源名称 (ARN) 并为 --apply-action 选项指定 system-update。将 --opt-in-type 选项设置为 immediate 可立即更新数据库集群的数据库版本,或设置为 next-maintenance 可在下一个集群维护时段内更新数据库集群的数据库版本。

  • 通过使用 RDS API – 调用 ApplyPendingMaintenanceAction API 操作,并为 ResourceId 参数指定数据库集群的 ARN,为 ApplyAction 参数指定 system-update。将 OptInType 参数设置为 immediate 可立即更新数据库集群的数据库版本,或设置为 next-maintenance 可在下一个集群维护时段内更新实例的数据库版本。

有关 Amazon RDS 如何管理数据库和操作系统更新的更多信息,请参阅维护 Amazon Aurora 数据库集群

注意

如果您的当前 Aurora MySQL 版本为 1.14.x,但低于 1.14.4,则只能升级到 1.14.4(支持 db.r4 实例类)。此外,要从 1.14.x 升级到更高的次要 Aurora MySQL 版本(例如 1.17),则 1.14.x 版本必须为 1.14.4。

零停机时间修补

零停机时间修补 (ZDP) 功能尝试在引擎修补期间尽力保留客户端连接。如果 ZDP 成功完成,则应用程序会话将保留,并且数据库引擎将在修补时重新启动。数据库引擎重新启动会导致吞吐量瞬时下降约 5 秒。Aurora MySQL 1.13 及更高版本(与 MySQL 5.6 兼容)提供了 ZDP。Aurora MySQL 2.07 及更高版本(与 MySQL 5.7 兼容)也提供了 ZDP。

在以下条件下,ZDP 可能无法成功完成:

  • 正在执行长时间运行的查询或事务。如果 Aurora 在此情况下可以执行 ZDP,将取消所有开放事务。

  • 启用了二进制日志记录或正在进行二进制日志复制。

  • 存在打开的 SSL 连接。

  • 正在使用临时表或表锁定,例如,在执行 DDL 语句期间。如果 Aurora 在此情况下可以执行 ZDP,将取消所有开放事务。

  • 存在待处理的参数更改。

自 Aurora MySQL 1.19 和 2.07 起,ZDP 机制得到了改进。当存在长时间运行的事务、二进制日志记录、表锁定或临时表时,这些改进使 ZDP 更有可能成功。

如果因以下一个或多个条件导致没有适合执行 ZDP 的时间范围,则修补将恢复为标准行为。

注意
  • ZDP 仅适用于数据库集群的主实例。ZDP 不适用于 Aurora 副本。

  • 预编译语句不会阻止 ZDP,但它们在 ZDP 完成后将不保留。