Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

升级 Aurora MySQL 数据库集群的次要版本或补丁程序级别

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

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

在执行次要版本升级之前

建议您执行以下操作以缩短次要版本升级期间的停机时间：

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

升级 Aurora MySQL 数据库集群的次要版本会将其它修复和新特征应用于现有集群。

这种升级适用于原始版本和升级的版本都具有相同的 Aurora MySQL 主要版本（无论是 2 还是 3）的 Aurora MySQL 集群。这个过程快速而直接，因为它不涉及 Aurora MySQL 元数据的任何转换或表数据的重组。

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

如果要对 Aurora Global Database 执行次要升级，请先升级所有辅助集群，然后再升级主集群。

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

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

对于 Amazon Aurora MySQL 数据库集群，您可以指定 Aurora 自动将数据库集群升级到新的次要版本。为此，您可以通过 Amazon Web Services Management Console、Amazon CLI 或 RDS API 使用数据库集群的自动次要版本升级属性。

自动升级在维护时段发生。如果数据库集群中的各个数据库实例的维护时段与集群维护时段不同，则集群维护时段优先。

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

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

您可以使用如下 CLI 命令来检查 Aurora MySQL 集群中所有数据库实例的 AutoMinorVersionUpgrade 设置的状态。

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 ...

在此示例中，数据库集群 cluster-57-2020-06-03-6411 的允许自动次要版本升级处于关闭状态，因为对于集群中的其中一个数据库实例关闭了此功能。

使用零停机时间修补

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

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

ZDP 不适用于以下情况：

Aurora Serverless v1 或 Aurora 全球数据库不支持 ZDP。

下表显示提供了 ZDP 的 Aurora MySQL 版本和数据库实例类。

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

在 Aurora MySQL 2.10 和更高版本以及版本 3 中，Aurora 可以执行零停机时间补丁，而无论是否启用二进制日志复制。如果启用二进制日志复制，则在 ZDP 操作期间，Aurora MySQL 将自动断开与二进制日志目标的连接。Aurora MySQL 会自动重新连接到二进制日志目标，并在重启完成后恢复复制。

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

在以下条件下，ZDP 可能无法成功完成：

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

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

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

备选的蓝绿升级技术

在某些情况下，您的首要任务是立即从旧集群切换到升级后的集群。在此类情况下，您可以使用多步骤流程，并排运行新旧集群。此处，您可以将数据从旧集群复制到新集群，直到您准备好接管新集群。有关详细信息，请参阅使用 Amazon RDS 蓝绿部署进行数据库更新。