# 升级 Amazon Aurora MySQL 数据库集群的主要版本
在诸如 3.04.1 的 Aurora MySQL 版本号中，3 表示主要版本。Aurora MySQL 版本 2 与 MySQL 5.7 兼容。Aurora MySQL 版本 3 与 MySQL 8.0 兼容。
与次要版本相比，在主要版本之间升级需要更广泛的计划和测试。这个过程可能需要大量时间。升级完成后，您可能还有后续工作要执行。例如，出现这种情况可能是由于 SQL 兼容性或某些 MySQL 相关功能的工作方式不同。或者可能是由于旧版本和新版本之间的参数设置不同而导致的。
**Contents**
+ [从 Aurora MySQL 版本 2 升级到版本 3](#AuroraMySQL.Updates.MajorVersionUpgrade.2to3)
+ [Aurora MySQL 主要版本升级路径](#AuroraMySQL.Upgrading.Compatibility)
+ [Aurora MySQL 主要版本就地升级的工作原理](#AuroraMySQL.Upgrading.Sequence)
+ [为 Aurora MySQL 集群计划主要版本升级](#AuroraMySQL.Upgrading.Planning)
+ [通过克隆数据库集群来模拟升级](#AuroraMySQL.Upgrading.Planning.clone)
+ [蓝绿部署](#AuroraMySQL.UpgradingMajor.BlueGreen)
+ [Aurora MySQL 的主要版本升级预检查](AuroraMySQL.upgrade-prechecks.md)
+ [Aurora MySQL 的预检查过程](AuroraMySQL.upgrade-prechecks.md#AuroraMySQL.upgrade-prechecks.process)
+ [Aurora MySQL 的预检查日志格式](AuroraMySQL.upgrade-prechecks.md#AuroraMySQL.upgrade-prechecks.log-format)
+ [Aurora MySQL 的预检查日志输出示例](AuroraMySQL.upgrade-prechecks.md#AuroraMySQL.upgrade-prechecks.log-examples)
+ [预检查 Aurora MySQL 的性能](AuroraMySQL.upgrade-prechecks.md#AuroraMySQL.upgrade-prechecks.performance)
+ [社区 MySQL 升级预检查摘要](AuroraMySQL.upgrade-prechecks.md#AuroraMySQL.upgrade-prechecks.community)
+ [Aurora MySQL 升级预检查摘要](AuroraMySQL.upgrade-prechecks.md#AuroraMySQL.upgrade-prechecks.ams)
+ [Aurora MySQL 的预检查描述参考](AuroraMySQL.upgrade-prechecks.descriptions.md)
+ [错误](AuroraMySQL.upgrade-prechecks.descriptions.md#precheck-descriptions-errors)
+ [报告错误的 MySQL 预检查](AuroraMySQL.upgrade-prechecks.descriptions.md#precheck-descriptions-errors.mysql)
+ [报告错误的 Aurora MySQL 预检查](AuroraMySQL.upgrade-prechecks.descriptions.md#precheck-descriptions-errors.aurora)
+ [警告](AuroraMySQL.upgrade-prechecks.descriptions.md#precheck-descriptions-warnings)
+ [报告警告的 MySQL 预检查](AuroraMySQL.upgrade-prechecks.descriptions.md#precheck-descriptions-warnings.mysql)
+ [报告警告的 Aurora MySQL 预检查](AuroraMySQL.upgrade-prechecks.descriptions.md#precheck-descriptions-warnings.aurora)
+ [版权声明](AuroraMySQL.upgrade-prechecks.descriptions.md#precheck-descriptions-notices)
+ [错误、警告或通知](AuroraMySQL.upgrade-prechecks.descriptions.md#precheck-descriptions-all)
+ [如何执行就地升级](AuroraMySQL.Upgrading.Procedure.md)
+ [就地升级如何影响集群的参数组](AuroraMySQL.Upgrading.Procedure.md#AuroraMySQL.Upgrading.ParamGroups)
+ [Aurora MySQL 版本之间的集群属性更改](AuroraMySQL.Upgrading.Procedure.md#AuroraMySQL.Upgrading.Attrs)
+ [全局数据库的就地主要版本升级](AuroraMySQL.Upgrading.Procedure.md#AuroraMySQL.Upgrading.GlobalDB)
+ [回溯注意事项](AuroraMySQL.Upgrading.Procedure.md#AuroraMySQL.Upgrading.Backtrack)
+ [Aurora MySQL 就地升级教程](AuroraMySQL.Upgrading.Tutorial.md)
+ [查找 Aurora MySQL 主要版本升级失败的原因](AuroraMySQL.Upgrading.failure-events.md)
+ [Aurora MySQL 就地升级的故障排除](AuroraMySQL.Upgrading.Troubleshooting.md)
+ [Aurora MySQL 版本 3 的升级后清理](AuroraMySQL.mysql80-post-upgrade.md)
+ [空间索引](AuroraMySQL.mysql80-post-upgrade.md#AuroraMySQL.mysql80-spatial)
## 从 Aurora MySQL 版本 2 升级到版本 3
如果您有一个与 MySQL 5.7 兼容的集群，并希望将其升级到与 MySQL 8.0 兼容的集群，可以通过在集群本身上运行升级过程来实现。这种升级是*就地升级*，与您通过创建新集群进行的升级形成鲜明对比。此技术会保留集群的相同终端节点和其他特征。升级速度相对较快，因为它不需要将所有数据复制到新的集群卷。此稳定性有助于显著减少应用程序中的任何配置更改。它还有助于减少升级后集群的测试量。这是因为数据库实例的数量及其实例类都保持不变。
就地升级机制会在进行操作的过程中关闭您的数据库集群。Aurora 将执行正常关机，并完成进行中的操作（例如事务回滚和撤消清除）。有关更多信息，请参阅 [Aurora MySQL 主要版本就地升级的工作原理](#AuroraMySQL.Upgrading.Sequence)。
就地升级方法非常方便，因为它执行过程简单，并且可以显著减少对关联应用程序的配置更改。例如，就地升级会为集群保留终端节点和数据库实例集。但是，就地升级所需的时间可能会有所不同，具体取决于架构的属性和集群的繁忙程度。这样，根据集群的需求，您可以在多种升级技术间进行选择：
+ [就地升级](AuroraMySQL.Upgrading.Procedure.md)
+ [蓝绿部署](#AuroraMySQL.UpgradingMajor.BlueGreen)
+ [快照还原](aurora-restore-snapshot.md)
**注意**
如果您使用 Amazon CLI 或 RDS API 作为快照还原升级方法，则必须运行后续操作才能在还原的数据库集群中创建写入器数据库实例。
有关 Aurora MySQL 版本 3 及其新功能的一般信息，请参阅 [与 MySQL 8.0 兼容的 Aurora MySQL 版本 3](AuroraMySQL.MySQL80.md)。
有关计划升级的详细信息，请参阅 [为 Aurora MySQL 集群计划主要版本升级](#AuroraMySQL.Upgrading.Planning) 和 [如何执行就地升级](AuroraMySQL.Upgrading.Procedure.md)。
## Aurora MySQL 主要版本升级路径
并非所有类型或版本的 Aurora MySQL 集群都可以使用就地升级机制。通过查阅下表，您可以了解每个 Aurora MySQL 集群的适当升级路径。
| Aurora MySQL 数据库集群类型 | 它可以使用就地升级吗？ | Action |
| --- | --- | --- |
| Aurora MySQL 预置集群，版本 2 | 是 | 与 MySQL 5.7 兼容的 Aurora MySQL 集群支持就地升级。
有关升级到 Aurora MySQL 版本 3 的信息，请参阅 [为 Aurora MySQL 集群计划主要版本升级](#AuroraMySQL.Upgrading.Planning) 和 [如何执行就地升级](AuroraMySQL.Upgrading.Procedure.md)。 |
| Aurora MySQL 预置集群，版本 3 | 不适用 | 使用次要版本升级过程在 Aurora MySQL 版本 3 的各版本之间进行升级。 |
| Aurora Serverless v1 集群 | 不适用 | 只有 Aurora MySQL 版本 2 才支持 Aurora Serverless v1。 |
| Aurora Serverless v2 集群 | 不适用 | 只有 Aurora MySQL 版本 3 才支持 Aurora Serverless v2。 |
| Aurora Global Database 中的集群 | 是 | 要将 Aurora MySQL 从版本 2 升级到版本 3，请按照对 Aurora Global Database 中的集群[进行就地升级的过程](AuroraMySQL.Upgrading.Procedure.md)操作。在全局集群上执行升级。Aurora 会同时升级全局数据库中的主集群以及所有辅助集群。
如果您使用 Amazon CLI 或 RDS API，请调用 `modify-global-cluster` 命令或 `ModifyGlobalCluster` 操作，而不是 `modify-db-cluster` 或 `ModifyDBCluster`。
只有当您将 `lower_case_table_names` 参数设置为默认值并且重启全球数据库之后，才能执行从 Aurora MySQL 版本 2 到版本 3 的就地升级。有关更多信息，请参阅 [主要版本升级。](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major)。 |
| 并行查询集群 | 是 | 您可以执行就地升级。 |
| 二进制日志复制的目标集群 | 也许 | 如果二进制日志复制来自 Aurora MySQL 集群，您可以执行就地升级。如果二进制日志复制来自 RDS for MySQL 或本地 MySQL 数据库实例，则无法执行升级。在这种情况下，您可以使用快照还原机制进行升级。 |
| 具有零数据库实例的集群 | 否 | 使用 Amazon CLI 或 RDS API，您可以在没有任何附加的数据库实例的情况下创建 Aurora MySQL 集群。同样，您还可以从 Aurora MySQL 集群中删除所有数据库实例，同时保持集群卷中的数据不变。虽然集群的数据库实例为零，但您无法执行就地升级。
升级机制要求集群中的写入器实例对系统表、数据文件等执行转换。在这种情况下，请使用 Amazon CLI 或 RDS API 为集群创建写入器实例。然后你可以执行就地升级。 |
| 启用了回溯的集群 | 是 | 可以对使用回溯功能的 Aurora MySQL 集群执行就地升级。但是，升级后，您无法将集群回溯到升级之前的时间。 |
## Aurora MySQL 主要版本就地升级的工作原理
Aurora MySQL 将主要版本升级作为多节点过程执行。您可以查看升级的当前状态。有些升级步骤还提供进度信息。每个阶段开始时，Aurora MySQL 会记录一个事件。您可以在 RDS 控制台的 **Events**（事件）页面上检查事件发生的事件。有关使用事件的更多信息，请参阅[使用 Amazon RDS 事件通知](USER_Events.md)。
**重要**
一旦该过程开始，它就会运行，直到升级成功或失败。您不能在升级进行中取消升级。如果升级失败，Aurora 将回滚所有更改，并且集群具有与以前相同的引擎版本、元数据等。
升级过程包括三个阶段：
1. Aurora 在开始升级过程之前执行一系列[预检查](AuroraMySQL.upgrade-prechecks.md)。在 Aurora 进行这些检查的同时，您的集群会保持运行。例如，集群不能有任何处于准备状态的 XA 事务，也不能处理任何数据定义语言 (DDL) 语句。例如，您可能需要关闭提交某些类型的 SQL 语句的应用程序。或者，您只需等待某些长期运行的语句完成。然后再次尝试升级。有些检查会测试不会阻止升级但可能使升级花费很长时间的条件。
如果 Aurora 检测到任何必需条件未满足，请修改事件详细信息中识别的条件。按照[Aurora MySQL 就地升级的故障排除](AuroraMySQL.Upgrading.Troubleshooting.md)中的指导进行操作。如果 Aurora 检测到可能导致升级缓慢的情况，请计划在一段较长的时间内监控升级。
1. Aurora 使您的集群离线。然后，Aurora 执行与上一阶段类似的一组测试，以确认关机过程中没有产生新问题。如果此时 Aurora 检测到任何会阻止升级的情况，Aurora 会取消升级并使集群恢复联机。在这种情况下，请确认条件何时不再适用，然后再次开始升级。
1. Aurora 创建集群卷的快照。假设您在升级完成后兼容性或其他类型的问题。或者假设您想同时使用原始集群和升级后的集群执行测试。在这种情况下，您可以从此快照中还原，以使用原始引擎版本和原始数据创建新集群。
**提示**
此快照是手动快照。但是，即使您已经达到手动快照的配额，Aurora 也可以创建手动快照并继续升级过程。此快照将永久保留（如果需要），直到您将其删除。完成所有升级后测试后，您可以删除此快照以显著减少存储费用。
1. Aurora 克隆集群卷。克隆是一项快速的操作，不涉及复制实际的表数据。如果 Aurora 在升级过程中遇到问题，它将从克隆的集群卷恢复为原始数据，然后使集群重新联机。升级期间的临时克隆卷不受单个集群卷的克隆数量的通常限制。
1. Aurora 对写入器数据库实例执行清理关机。在清理关机期间，以下操作的进度事件每 15 分钟记录一次。您可以在 RDS 控制台的 **Events**（事件）页面上检查事件发生的事件。
+ Aurora 清除旧版本行的撤销记录。
+ Aurora 回滚任何未提交的事务。
1. Aurora 升级写入器数据库实例上的引擎版本：
+ Aurora 在写入器数据库实例上安装新引擎版本的二进制文件。
+ Aurora 使用写入器数据库实例将数据升级为兼容 MySQL 5.7 的格式。在此阶段，Aurora 修改系统表并执行影响集群卷中的数据的其他转换。特别是，Aurora 升级系统表中的分区元数据以与 MySQL 5.7 分区格式兼容。如果集群中的表有大量分区，则此阶段可能需要花费很长时间。
如果在此阶段发生任何错误，您可以在 MySQL 错误日志中找到详细信息。此阶段开始后，如果升级过程因任何原因失败，Aurora 将从克隆的集群卷中恢复原始数据。
1. Aurora 升级读取器数据库实例上的引擎版本。
1. 升级过程已完成。Aurora 记录最后一个事件以表示升级过程已成功完成。现在，您的数据库集群正在运行新的主要版本。
## 为 Aurora MySQL 集群计划主要版本升级
为了帮助您决定正确的升级时间和方法，您可以了解 Aurora MySQL 版本 3 与当前环境之间的区别：
+ 如果您要从 RDS for MySQL 8.0 或 MySQL 8.0 社区版进行转换，请参阅[比较 Aurora MySQL 版本 3 和 MySQL 8.0 社群版](AuroraMySQL.Compare-80-v3.md)。
+ 如果您要从 Aurora MySQL 版本 2、RDS for MySQL 5.7 或社区 MySQL 5.7 升级，请参阅[比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3](AuroraMySQL.Compare-v2-v3.md)。
+ 为任何自定义参数组创建新的 MySQL 8.0 兼容版本。将所有必要的自定义参数值应用于新参数组。咨询 [Aurora MySQL 版本 3 的参数更改](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.mysql80-parameter-changes) 以了解参数更改。
+ 请查看您的 Aurora MySQL 版本 2 数据库架构和对象定义，以了解 MySQL 8.0 社区版中引入的新保留关键字的使用情况。请在升级之前执行此操作。有关更多信息，请参阅 MySQL 文档中的 [MySQL 8.0 新关键字和保留关键字](https://dev.mysql.com/doc/mysqld-version-reference/en/keywords-8-0.html#keywords-new-in-8-0)。
您还可以在 *MySQL 参考手册*的 [MySQL 8.0 中的变化](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html)中找到更多特定于 MySQL 的升级注意事项和提示。例如，您可以使用命令 `mysqlcheck --check-upgrade` 来分析现有的 Aurora MySQL 数据库并确定潜在的升级问题。
**注意**
在使用就地升级或快照还原技术升级到 Aurora MySQL 版本 3 时，我们建议使用更大的数据库实例类。例如，db.r5.24xlarge 和 db.r6g.16xlarge。这样，通过使用数据库实例上的绝大部分可用 CPU 容量，有助于更快地完成升级过程。在主要版本升级完成后，您可以更改为所需的数据库实例类。
完成升级后，您可以按照 [Aurora MySQL 版本 3 的升级后清理](AuroraMySQL.mysql80-post-upgrade.md) 中的升级后步骤进行操作。最后，测试应用程序的功能和性能。
如果您要从 MySQL 或社区 MySQL 进行 RDS 转换，请按照[将数据迁移到 Amazon Aurora MySQL 数据库集群](AuroraMySQL.Migrating.md)中所述的迁移过程进行操作。在某些情况下，作为迁移的一部分，您可以使用二进制日志复制将数据与 Aurora MySQL 版本 3 集群同步数据。如果是这样，源系统必须运行与目标数据库集群兼容的版本。
为了确保在主要版本之间升级集群后，您的应用程序和管理过程能够顺利运行，应进行一些预先计划和准备。要查看可为您的 Amazon CLI 脚本或基于 RDS API 的应用程序更新哪些类型的管理代码，请参阅 [就地升级如何影响集群的参数组](AuroraMySQL.Upgrading.Procedure.md#AuroraMySQL.Upgrading.ParamGroups)。另请参阅 [Aurora MySQL 版本之间的集群属性更改](AuroraMySQL.Upgrading.Procedure.md#AuroraMySQL.Upgrading.Attrs)
要了解在升级期间可能遇到的问题，请参阅[Aurora MySQL 就地升级的故障排除](AuroraMySQL.Upgrading.Troubleshooting.md)。对于可能导致升级需要很长时间的问题，您可以提前测试这些条件并进行更正。
**注意**
就地升级会在进行操作的过程中关闭您的数据库集群。Aurora MySQL 将执行正常关机，并完成进行中的操作（例如撤消清除）。如果要清除的撤消记录很多，则升级可能需要很长时间。我们建议仅在历史记录列表长度（HLL）较小之后才执行升级。HLL 的一般可接受值为 100000 或更小。有关更多信息，请参阅此[博客文章](https://www.amazonaws.cn/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2)。
### 通过克隆数据库集群来模拟升级
您可以检查升级后集群的应用程序兼容性、性能、维护过程以及类似注意事项。为此，您可以在真正进行升级之前执行升级模拟。此技术对生产集群尤其有用。在这里，重要的是要尽量减少停机时间，并在升级完成后立即让升级后的集群准备就绪。
使用以下步骤：
1. 创建原始集群的克隆。按照[克隆 Amazon Aurora 数据库集群卷](Aurora.Managing.Clone.md)中过程操作。
1. 设置与原始集群中类似的写入器和读取器数据库实例集。
1. 对克隆的集群执行就地升级。按照[如何执行就地升级](AuroraMySQL.Upgrading.Procedure.md)中过程操作。
创建克隆后立即开始升级。这样，集群卷仍然与原始集群的状态相同。如果克隆在升级之前处于空闲状态，则 Aurora 会在后台执行数据库清理过程。在这种情况下，克隆的升级并不是原始集群升级的准确模拟。
1. 使用克隆的集群测试应用程序兼容性、性能、管理过程等。
1. 如果遇到任何问题，请调整升级计划以解决这些问题。例如，调整任何应用程序代码以与更高版本的功能集兼容。根据集群中的数据量估计升级可能需要多长时间。您也可以选择将升级安排在集群不忙的时候。
1. 在您对应用程序和工作负载在测试集群中正常运行感到满意后，您可以为生产集群执行就地升级。
1. 努力显著减少集群在主要版本升级期间的总停机时间。为此，请确保升级时集群上的工作负载较低或为零。特别是确保在启动升级时没有长期运行的事务在进行。
### 蓝绿部署
在某些情况下，您的首要任务是立即从旧集群切换到升级后的集群。在此类情况下，您可以使用多步骤流程，并排运行新旧集群。此处，您可以将数据从旧集群复制到新集群，直到您准备好接管新集群。有关详细信息，请参阅[使用 Amazon Aurora 蓝绿部署进行数据库更新](blue-green-deployments.md)。