升级 Aurora MySQL 数据库集群的次要版本或补丁程序级别 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

升级 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 元数据的任何转换或表数据的重组。

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

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

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

  • 通过使用 Amazon CLI – 调用 modify-db-cluster Amazon 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 次要版本之间的自动升级

对于 Amazon Aurora MySQL 数据库集群,您可以指定在新的次要版本发布时 Aurora 自动将该数据库集群升级到这些版本。为此,您可以使用 Amazon Web Services Management Console、Amazon CLI 或 RDS API 启用数据库集群的自动次要版本升级属性。

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

重要

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

自动次要版本升级也适用于运行Aurora MySQL 1.x 或 2.x LTS 版本的集群。要防止这些集群自动升级,请务必关闭启用次要版本自动升级设置选项。

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

  • 多主集群。

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

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

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

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

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

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

  2. 执行以下操作为集群启用自动次要版本升级:

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

    1. 登录 Amazon RDS 控制台,选择 Databases(数据库),查找您希望打开或关闭自动次要版本升级的数据库集群。

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

      1. 选择修改

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

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

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

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

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

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

您可以使用如下 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-05-01-2332", "DBClusterIdentifier": "cluster-57-2020-05-01-4615", "AutoMinorVersionUpgrade": true }, ... output omitted ...

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

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

应用待执行的维护操作

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

    1. 登录 Amazon RDS 控制台,选择 Databases(数据库),然后选择显示可用 维护升级的数据库集群。

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

  • 通过使用 Amazon CLI – 调用 apply-pending-maintenance-action Amazon 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。

使用零停机时间修补

对 Aurora MySQL 数据库集群执行升级时可能会在数据库关闭和升级期间发生中断。默认情况下,如果在数据库运行时开始升级,则会丢失数据库集群正在处理的所有连接和事务。如果等到数据库处于空闲状态再执行升级,则可能需要等待很长时间。

零停机时间修补 (ZDP) 功能尝试在 Aurora MySQL 升级期间尽力保留客户端连接。如果 ZDP 成功完成,则应用程序会话将保留,并且数据库引擎将在升级过程中重新启动。数据库引擎重新启动可能会导致吞吐量下降,持续时间从几秒钟到大约一分钟不等。

ZDP 在Aurora MySQL 2.07.2 至 2.07.4 版本和 2.10.0 及更高版本中提供,与 MySQL 5.7 兼容。

ZDP 仅适用于使用 db.t2db.t3 实例类的 Aurora MySQL 数据库实例。

您可以在 MySQL 错误日志中查看 ZDP 期间重要属性的指标。您还可以在 Amazon Web Services Management Console 中的 Events(事件)页面上查看有关何时 Aurora MySQL 使用 ZDP,何时选择不使用 ZDP 的信息。

在 Aurora MySQL 2.10 及更高版本中,当启用二进制日志复制时,Aurora 可以执行零停机修补。Aurora MySQL 在 ZDP 操作期间自动断开与二进制日志目标的连接。Aurora MySQL 自动重新连接到二进制日志目标,并在完成重新启动后恢复复制。

ZDP 还与 Aurora MySQL 2.10 及更高版本中的重启增强功能结合使用。修补写入器数据库实例同时自动修补读取器。执行修补后,Aurora 将恢复写入器和读取器数据库实例上的连接。低于 Aurora MySQL 2.10 的版本,ZDP 仅适用于集群的写入器数据库实例。

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

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

  • 存在开放式安全套接字层 (SSL) 连接。

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

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

提示

要充分利用 ZDP,请将 Aurora MySQL 集群升级到至少 2.10 或 1.19 版本。这些版本对 ZDP 机制进行了改进。当存在长时间运行的事务、二进制日志记录、表锁定或临时表时,这些改进使 ZDP 更有可能成功。

您可以在 Aurora MySQL 数据库引擎更新 2021-05-25(版本 2.10.0)Aurora MySQL 数据库引擎更新 2019-11-25(版本 2.07.0)Aurora MySQL 数据库引擎更新 2019-02-07(版本 1.19.0) 中查看适用于特定版本的 ZDP 增强功能的详细信息

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

尽管成功执行 ZDP 操作后连接保持不变,但一些变量和功能会重新初始化。零停机修补重启后,以下类型的信息将不会保留:

  • 全局变量。Aurora 将恢复会话变量,但重启后不会恢复全局变量。

  • 状态变量。特别是,引擎状态报告的正常运行时间值会在使用 ZDR 或 ZDP 机制重启后重置。

  • LAST_INSERT_ID.

  • 表的内存中 auto_increment 状态。重新初始化内存中的自动增量状态。有关自动增量值的更多信息,请参阅 MySQL 参考手册

  • 来自 INFORMATION_SCHEMAPERFORMANCE_SCHEMA 表的诊断信息。此诊断信息也会出现在 SHOW PROFILESHOW PROFILES 和等命令的输出中

Events(事件)页面上报告了以下与零停机时间重启相关的活动:

  • 尝试在零停机时间的情况下升级数据库。

  • 尝试在零停机的情况下升级数据库已完成。“事件”会报告该过程花费的时间。“事件”还会报告在重启期间保留的连接数量以及断开的连接数量。您可以查看数据库错误日志,以查看有关重启期间发生的情况的更多详细信息。

下表总结了 ZDP 如何从特定 Aurora MySQL 版本升级以及如何升级到特定版本。数据库实例的实例类还会影响 Aurora 是否使用 ZDP 机制。

原始版本 升级的版本 ZDP 适用吗?

Aurora MySQL 1。*

任何

Aurora MySQL 2.*,低于 2.07.2 版本

任何

Aurora MySQL 2.07.2、2.07.3

2.07.4、2.10。*

是的,仅在 T2 和 T3 实例类的写入器实例上。如果在超时前发现安静点,Aurora 仅执行 ZDP。超时后,Aurora 将执行定期重启。

2.07.4

2.10。*

是的,仅在 T2 和 T3 实例的写入器实例上。Aurora 回滚活动和空闲事务的事务。使用 SSL、临时表、表锁或用户锁的连接将断开连接。如果在 ZDP 完成后引擎需要太长时间才能启动,Aurora 可能会重新启动引擎并断开所有连接。

备选的蓝绿升级技术

博客文章:在最少停机时间下执行 Aurora MySQL 的主要版本升级