# 升级 Aurora MySQL 数据库集群的次要版本或补丁程序级别
可以使用以下方法升级数据库集群的次要版本或修补数据库集群：
+ [通过修改引擎版本升级 Aurora MySQL](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md)（适用于 Aurora MySQL 版本 2 和 3）
+ [启用 Aurora MySQL 次要版本之间的自动升级](AuroraMySQL.Updates.AMVU.md)
有关零停机时间修补如何减少升级过程中的中断的信息，请参阅[使用零停机时间修补](AuroraMySQL.Updates.ZDP.md)。
有关对 Aurora MySQL 数据库集群执行次要版本升级的信息，请参阅以下主题。
**Topics**
+ [在执行次要版本升级之前](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [Aurora MySQL 的次要版本升级预检查](#AuroraMySQL.minor-upgrade-prechecks)
+ [通过修改引擎版本升级 Aurora MySQL](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md)
+ [启用 Aurora MySQL 次要版本之间的自动升级](AuroraMySQL.Updates.AMVU.md)
+ [使用零停机时间修补](AuroraMySQL.Updates.ZDP.md)
+ [备选的蓝绿升级技术](#AuroraMySQL.UpgradingMinor.BlueGreen)
## 在执行次要版本升级之前
建议您执行以下操作以缩短次要版本升级期间的停机时间：
+ 应在流量较低的时段执行 Aurora 数据库集群维护。使用 Performance Insights 来识别这些时间段，以便正确配置维护时段。有关 Performance Insights 的更多信息，请参阅[在 Amazon RDS 上使用 Performance Insights 监控数据库负载](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)。有关数据库集群维护时段的更多信息，请参阅[调整首选数据库集群维护时段](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora)。
+ 使用支持指数回退和抖动的 AWS SDK 作为最佳实践。有关更多信息，请参阅 [Exponential Backoff And Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)。
## Aurora MySQL 的次要版本升级预检查
当您启动次要版本升级时，Amazon Aurora 会自动运行预检查。
这些预检查是必需的。您不能选择跳过它们。预检查提供以下好处：
+ 它们让您可以在升级期间避免出现计划外停机。
+ 如果存在不一致项，Amazon Aurora 将阻止升级并提供日志以供您参阅。然后，您可以使用日志来减少不兼容的情况，以准备数据库进行升级。有关消除不兼容情况的详细信息，请参阅 MySQL 文档中的 [Preparing your installation for upgrade](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html)。
在为了升级而停止数据库实例之前先运行预检查，这意味着它们在运行时不会造成任何停机。如果预检查发现不兼容问题，Aurora 会在停止数据库实例之前自动取消升级。Aurora 还会针对不兼容问题生成事件。有关 Amazon Aurora 事件的更多信息，请参阅[使用 Amazon RDS 事件通知](USER_Events.md)。
Aurora 在日志文件 `PrePatchCompatibility.log` 中记录有关每项不兼容性的详细信息。在大部分情况下，日志条目包括用于纠正不兼容性的 MySQL 文档的链接。有关查看日志文件的更多信息，请参阅 [查看和列出数据库日志文件](USER_LogAccess.Procedural.Viewing.md)。
由于预检查的性质，它们会分析数据库中的对象。此分析会导致资源消耗并增加完成升级的时间。
# 通过修改引擎版本升级 Aurora MySQL
升级 Aurora MySQL 数据库集群的次要版本会将其它修复和新功能应用于现有集群。
这种升级适用于原始版本和升级的版本都具有相同的 Aurora MySQL 主要版本（无论是 2 还是 3）的 Aurora MySQL 集群。这个过程快速而直接，因为它不涉及 Aurora MySQL 元数据的任何转换或表数据的重组。
您可以通过使用 AWS 管理控制台、AWS CLI 或 RDS API 修改数据库集群的引擎版本来执行这种升级。例如，如果您的集群正在运行 Aurora MySQL 3.x，请选择更高的 3.x 版本。
如果要对 Aurora Global Database 执行次要升级，请先升级所有辅助集群，然后再升级主集群。
**注意**
要执行升级到 Aurora MySQL 版本 3.04.\$1 或更高版本或版本 2.12.\$1 的次要版本升级，请按照以下过程：
从全局集群中删除所有辅助区域。按照[从 Amazon Aurora Global Database 删除集群](aurora-global-database-detaching.md)中的步骤操作。
将主区域的引擎版本升级到 3.04.\$1 或更高版本或版本 2.12.\$1（如果适用）。按照[To modify the engine version of a DB cluster](#modify-db-cluster-engine-version)中的步骤操作。
向全局集群添加辅助区域。按照[将 AWS 区域 添加到 Amazon Aurora Global Database](aurora-global-database-attaching.md)中的步骤操作。
**修改数据库集群的引擎版本**
+ **通过使用控制台** – 修改集群的属性。在 **Modify DB cluster (修改数据库集群)** 窗口中，更改 **DB engine version (数据库引擎版本)** 框中的 Aurora MySQL 引擎版本。如果您不熟悉修改集群的一般过程，请按照[使用控制台、CLI 和 API 修改数据库集群](Aurora.Modifying.md#Aurora.Modifying.Cluster)中的说明操作。
+ **通过使用 AWS CLI** – 调用 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI 命令，为 `--db-cluster-identifier` 选项指定数据库集群的名称，并为 `--engine-version` 选项指定引擎版本。
例如，要升级到 Aurora MySQL 版本 3.04.1，请将 `--engine-version` 选项设置为 `8.0.mysql_aurora.3.04.1`。指定 `--apply-immediately` 选项可立即更新数据库集群的引擎版本。
+ **通过使用 RDS API** – 调用 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API 操作，为 `DBClusterIdentifier` 参数指定数据库集群的名称，并为 `EngineVersion` 参数指定引擎版本。将 `ApplyImmediately` 参数设置为 `true` 可立即更新数据库集群的引擎版本。
# 启用 Aurora MySQL 次要版本之间的自动升级
对于 Amazon Aurora MySQL 数据库集群，您可以指定 Aurora 自动将数据库集群升级到新的次要版本。您可以通过设置数据库集群的 `AutoMinorVersionUpgrade` 属性（在AWS 管理控制台中启用**自动次要版本升级**）来实现此目的。
自动升级在维护时段发生。如果数据库集群中的各个数据库实例的维护时段与集群维护时段不同，则集群维护时段优先。
自动次要版本升级不适用于以下类型的 Aurora MySQL 集群：
+ 属于 Aurora 全局数据库的集群
+ 具有跨区域副本的集群
中断持续时间取决于工作负载、集群大小、二进制日志数据量以及 Aurora 是否可以使用零停机时间修补（ZDP）功能。Aurora 会重新启动数据库集群，因此您可能会在恢复使用集群之前经历短暂的不可用时间。特别是，二进制日志数据量会影响恢复时间。数据库实例在恢复期间处理二进制日志数据。因此，大量的二进制日志数据会增加恢复时间。
**注意**
只有在数据库集群中的所有数据库实例中启用 `AutoMinorVersionUpgrade` 设置，Aurora 才会执行自动升级。有关如何设置该设置及其在集群和实例级别应用时的工作原理，请参阅 [Aurora 数据库集群的自动次要版本升级](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU)。
然后，如果数据库集群的实例存在到 `AutoUpgrade` 已设置为 true 的次要数据库引擎版本的升级路径，则会进行升级。`AutoUpgrade` 设置是动态的，由 RDS 进行设置。
系统会对默认次要版本执行自动次要版本升级。
您可以使用如下 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 不适用于以下情况：
+ 操作系统（OS）补丁和升级
+ 主要版本升级
ZDP 适用于所有支持的 Aurora MySQL 版本和数据库实例类。
Aurora Serverless v1 或 Aurora 全球数据库不支持 ZDP。
**注意**
建议仅将 T 数据库实例类用于开发和测试服务器，或其他非生产服务器。有关 T 实例类的更多详细信息，请参阅[使用 T 实例类进行开发和测试](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium)。
您可以在 MySQL 错误日志中查看 ZDP 期间重要属性的指标。您还可以在 AWS 管理控制台中的 **Events**（事件）页面上查看有关 Aurora MySQL 何时使用 ZDP、何时选择不使用 ZDP 的信息。
在 Aurora MySQL 中，Aurora 可以不停机执行修补，不管是否启用二进制日志复制。如果启用二进制日志复制，则在 ZDP 操作期间，Aurora MySQL 将自动断开与二进制日志目标的连接。Aurora MySQL 会自动重新连接到二进制日志目标，并在重启完成后恢复复制。
ZDP 还可与 Aurora MySQL 中的重启增强功能结合使用。修补写入器数据库实例会同时自动修补读取器。执行修补后，Aurora 将恢复写入器和读取器数据库实例上的连接。
在以下条件下，ZDP 可能无法成功完成：
+ 正在执行长时间运行的查询或事务。如果 Aurora 在此情况下可以执行 ZDP，则将取消所有开放事务，但会保留其连接。
+ 临时表、用户锁定或表锁定正在使用中，例如，在数据定义语言（DDL）语句运行期间。Aurora 会断开这些连接。
+ 存在待处理的参数更改。
如果因以下一个或多个条件导致没有适合执行 ZDP 的时间范围，则修补将恢复为标准行为。
尽管成功执行 ZDP 操作后连接保持不变，但一些变量和功能会重新初始化。零停机修补重启后，以下类型的信息将不会保留：
+ 全局变量。Aurora 将恢复会话变量，但重启后不会恢复全局变量。
+ 状态变量。特别是，引擎状态报告的正常运行时间值会在使用 ZDR 或 ZDP 机制重启后重置。
+ `LAST_INSERT_ID`.
+ 表的内存中 `auto_increment` 状态。重新初始化内存中的自动增量状态。有关自动增量值的更多信息，请参阅 [MySQL 参考手册](https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization)。
+ 来自 `INFORMATION_SCHEMA` 和 `PERFORMANCE_SCHEMA` 表的诊断信息。这些诊断信息也会显示在 `SHOW PROFILE` 和 `SHOW PROFILES` 等命令的输出中。
**Events (事件)** 页面上报告了以下与零停机时间重启相关的活动：
+ 尝试在零停机的情况下升级数据库。
+ 尝试在零停机的情况下升级数据库已完成。事件会报告该过程花费的时间。事件还会报告在重启期间保留的连接数量以及断开的连接数量。您可以查看数据库错误日志，了解有关重启期间所发生情况的更多详细信息。
## 备选的蓝绿升级技术
在某些情况下，您的首要任务是立即从旧集群切换到升级后的集群。在此类情况下，您可以使用多步骤流程，并排运行新旧集群。此处，您可以将数据从旧集群复制到新集群，直到您准备好接管新集群。有关详细信息，请参阅[使用 Amazon Aurora 蓝绿部署进行数据库更新](blue-green-deployments.md)。