升级 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 Global Database 执行次要升级,请先升级所有辅助集群,然后再升级主集群。

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

  • 通过使用控制台 – 修改集群的属性。在 Modify DB cluster (修改数据库集群) 窗口中,更改 DB engine version (数据库引擎版本) 框中的 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. 选择 Modify (修改)

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

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

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

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

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

  • 通过使用 RDS API – 调用 ModifyDBInstance API 操作,并为 DBInstanceIdentifier 参数指定数据库集群的名称,为 true 参数指定 AutoMinorVersionUpgrade。(可选)将 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 版本 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 Resource Name (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 版本以及 2.10.0 和更高版本中提供,与 MySQL 5.7 以及 3.01.0 和更高的版本兼容,并与 MySQL 8.0 兼容。

在 Aurora MySQL 版本 2 中,ZDP 仅适用于使用 db.t2db.t3 实例类的 Aurora MySQL 数据库实例。在 Aurora MySQL 版本 3 中,ZDP 适用于所有实例类。

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

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

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

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

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

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

  • 正在使用临时表或表锁定,例如,在执行数据定义语言 (DDL) 语句期间。如果 Aurora 在此情况下可以执行 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.07 版本、2.10.*

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

2.07.4 和更高的 2.07 版本

2.10.*

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

备选的蓝绿升级技术

博客文章:Performing major version upgrades for Aurora MySQL with minimum downtime