升级 Amazon Aurora MySQL 数据库集群的主要版本
在诸如 3.04.1 的 Aurora MySQL 版本号中，3 表示主要版本。Aurora MySQL 版本 2 与 MySQL 5.7 兼容。Aurora MySQL 版本 3 与 MySQL 8.0 兼容。
与次要版本相比，在主要版本之间升级需要更广泛的计划和测试。这个过程可能需要大量时间。升级完成后，您可能还有后续工作要执行。例如，出现这种情况可能是由于 SQL 兼容性或某些 MySQL 相关功能的工作方式不同。或者可能是由于旧版本和新版本之间的参数设置不同而导致的。
目录
从 Aurora MySQL 版本 2 升级到版本 3
如果您有一个与 MySQL 5.7 兼容的集群，并希望将其升级到与 MySQL 8.0 兼容的集群，可以通过在集群本身上运行升级过程来实现。这种升级是就地升级，与您通过创建新集群进行的升级形成鲜明对比。此技术会保留集群的相同终端节点和其他特征。升级速度相对较快，因为它不需要将所有数据复制到新的集群卷。此稳定性有助于显著减少应用程序中的任何配置更改。它还有助于减少升级后集群的测试量。这是因为数据库实例的数量及其实例类都保持不变。
就地升级机制会在进行操作的过程中关闭您的数据库集群。Aurora 将执行正常关机，并完成进行中的操作（例如事务回滚和撤消清除）。有关更多信息，请参阅 Aurora MySQL 主要版本就地升级的工作原理。
就地升级方法非常方便，因为它执行过程简单，并且可以显著减少对关联应用程序的配置更改。例如，就地升级会为集群保留终端节点和数据库实例集。但是，就地升级所需的时间可能会有所不同，具体取决于架构的属性和集群的繁忙程度。这样，根据集群的需求，您可以在多种升级技术间进行选择：
有关 Aurora MySQL 版本 3 及其新功能的一般信息，请参阅 与 MySQL 8.0 兼容的 Aurora MySQL 版本 3。
有关计划升级的详细信息，请参阅 为 Aurora MySQL 集群计划主要版本升级 和 如何执行就地升级。
Aurora MySQL 主要版本升级路径
并非所有类型或版本的 Aurora MySQL 集群都可以使用就地升级机制。通过查阅下表，您可以了解每个 Aurora MySQL 集群的适当升级路径。
| Aurora MySQL 数据库集群类型 | 它可以使用就地升级吗？ | 操作 |
|---|---|---|
|
Aurora MySQL 预置集群，版本 2 |
是 |
与 MySQL 5.7 兼容的 Aurora MySQL 集群支持就地升级。 有关升级到 Aurora MySQL 版本 3 的信息，请参阅 为 Aurora MySQL 集群计划主要版本升级 和 如何执行就地升级。 |
|
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 中的集群进行就地升级的过程操作。在全局集群上执行升级。Aurora 会同时升级全局数据库中的主集群以及所有辅助集群。 如果您使用 Amazon CLI 或 RDS API，请调用 只有当您将 |
|
并行查询集群 |
是 |
您可以执行就地升级。 |
|
二进制日志复制的目标集群 |
也许 |
如果二进制日志复制来自 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 事件通知。
重要
一旦该过程开始，它就会运行，直到升级成功或失败。您不能在升级进行中取消升级。如果升级失败，Aurora 将回滚所有更改，并且集群具有与以前相同的引擎版本、元数据等。
升级过程包括三个阶段：
-
Aurora 在开始升级过程之前执行一系列预检查。在 Aurora 进行这些检查的同时，您的集群会保持运行。例如，集群不能有任何处于准备状态的 XA 事务，也不能处理任何数据定义语言 (DDL) 语句。例如，您可能需要关闭提交某些类型的 SQL 语句的应用程序。或者，您只需等待某些长期运行的语句完成。然后再次尝试升级。有些检查会测试不会阻止升级但可能使升级花费很长时间的条件。
如果 Aurora 检测到任何必需条件未满足，请修改事件详细信息中识别的条件。按照Aurora MySQL 就地升级的故障排除中的指导进行操作。如果 Aurora 检测到可能导致升级缓慢的情况，请计划在一段较长的时间内监控升级。
-
Aurora 使您的集群离线。然后，Aurora 执行与上一阶段类似的一组测试，以确认关机过程中没有产生新问题。如果此时 Aurora 检测到任何会阻止升级的情况，Aurora 会取消升级并使集群恢复联机。在这种情况下，请确认条件何时不再适用，然后再次开始升级。
-
Aurora 创建集群卷的快照。假设您在升级完成后兼容性或其他类型的问题。或者假设您想同时使用原始集群和升级后的集群执行测试。在这种情况下，您可以从此快照中还原，以使用原始引擎版本和原始数据创建新集群。
提示
此快照是手动快照。但是，即使您已经达到手动快照的配额，Aurora 也可以创建手动快照并继续升级过程。此快照将永久保留（如果需要），直到您将其删除。完成所有升级后测试后，您可以删除此快照以显著减少存储费用。
-
Aurora 克隆集群卷。克隆是一项快速的操作，不涉及复制实际的表数据。如果 Aurora 在升级过程中遇到问题，它将从克隆的集群卷恢复为原始数据，然后使集群重新联机。升级期间的临时克隆卷不受单个集群卷的克隆数量的通常限制。
-
Aurora 对写入器数据库实例执行清理关机。在清理关机期间，以下操作的进度事件每 15 分钟记录一次。您可以在 RDS 控制台的 Events（事件）页面上检查事件发生的事件。
-
Aurora 清除旧版本行的撤销记录。
-
Aurora 回滚任何未提交的事务。
-
-
Aurora 升级写入器数据库实例上的引擎版本：
-
Aurora 在写入器数据库实例上安装新引擎版本的二进制文件。
-
Aurora 使用写入器数据库实例将数据升级为兼容 MySQL 5.7 的格式。在此阶段，Aurora 修改系统表并执行影响集群卷中的数据的其他转换。特别是，Aurora 升级系统表中的分区元数据以与 MySQL 5.7 分区格式兼容。如果集群中的表有大量分区，则此阶段可能需要花费很长时间。
如果在此阶段发生任何错误，您可以在 MySQL 错误日志中找到详细信息。此阶段开始后，如果升级过程因任何原因失败，Aurora 将从克隆的集群卷中恢复原始数据。
-
-
Aurora 升级读取器数据库实例上的引擎版本。
-
升级过程已完成。Aurora 记录最后一个事件以表示升级过程已成功完成。现在，您的数据库集群正在运行新的主要版本。
为 Aurora MySQL 集群计划主要版本升级
为了帮助您决定正确的升级时间和方法，您可以了解 Aurora MySQL 版本 3 与当前环境之间的区别：
-
如果您要从 RDS for MySQL 8.0 或 MySQL 8.0 社区版进行转换，请参阅比较 Aurora MySQL 版本 3 和 MySQL 8.0 社群版。
-
如果您要从 Aurora MySQL 版本 2、RDS for MySQL 5.7 或社区 MySQL 5.7 升级，请参阅比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3。
-
为任何自定义参数组创建新的 MySQL 8.0 兼容版本。将所有必要的自定义参数值应用于新参数组。咨询 Aurora MySQL 版本 3 的参数更改 以了解参数更改。
-
请查看您的 Aurora MySQL 版本 2 数据库架构和对象定义，以了解 MySQL 8.0 社区版中引入的新保留关键字的使用情况。请在升级之前执行此操作。有关更多信息，请参阅 MySQL 文档中的 MySQL 8.0 新关键字和保留关键字
。
您还可以在 MySQL 参考手册的 MySQL 8.0 中的变化mysqlcheck --check-upgrade 来分析现有的 Aurora MySQL 数据库并确定潜在的升级问题。
注意
在使用就地升级或快照还原技术升级到 Aurora MySQL 版本 3 时，我们建议使用更大的数据库实例类。例如，db.r5.24xlarge 和 db.r6g.16xlarge。这样，通过使用数据库实例上的绝大部分可用 CPU 容量，有助于更快地完成升级过程。在主要版本升级完成后，您可以更改为所需的数据库实例类。
完成升级后，您可以按照 Aurora MySQL 版本 3 的升级后清理 中的升级后步骤进行操作。最后，测试应用程序的功能和性能。
如果您要从 MySQL 或社区 MySQL 进行 RDS 转换，请按照将数据迁移到 Amazon Aurora MySQL 数据库集群中所述的迁移过程进行操作。在某些情况下，作为迁移的一部分，您可以使用二进制日志复制将数据与 Aurora MySQL 版本 3 集群同步数据。如果是这样，源系统必须运行与目标数据库集群兼容的版本。
为了确保在主要版本之间升级集群后，您的应用程序和管理过程能够顺利运行，应进行一些预先计划和准备。要查看可为您的 Amazon CLI 脚本或基于 RDS API 的应用程序更新哪些类型的管理代码，请参阅 就地升级如何影响集群的参数组。另请参阅Aurora MySQL 版本之间的集群属性更改。
要了解在升级期间可能遇到的问题，请参阅Aurora MySQL 就地升级的故障排除。对于可能导致升级需要很长时间的问题，您可以提前测试这些条件并进行更正。
注意
就地升级会在进行操作的过程中关闭您的数据库集群。Aurora MySQL 将执行正常关机，并完成进行中的操作（例如撤消清除）。如果要清除的撤消记录很多，则升级可能需要很长时间。我们建议仅在历史记录列表长度（HLL）较小之后才执行升级。HLL 的一般可接受值为 100000 或更小。有关更多信息，请参阅此博客文章
通过克隆数据库集群来模拟升级
您可以检查升级后集群的应用程序兼容性、性能、维护过程以及类似注意事项。为此，您可以在真正进行升级之前执行升级模拟。此技术对生产集群尤其有用。在这里，重要的是要尽量减少停机时间，并在升级完成后立即让升级后的集群准备就绪。
使用以下步骤：
-
创建原始集群的克隆。按照克隆 Amazon Aurora 数据库集群卷中过程操作。
-
设置与原始集群中类似的写入器和读取器数据库实例集。
-
对克隆的集群执行就地升级。按照如何执行就地升级中过程操作。
创建克隆后立即开始升级。这样，集群卷仍然与原始集群的状态相同。如果克隆在升级之前处于空闲状态，则 Aurora 会在后台执行数据库清理过程。在这种情况下，克隆的升级并不是原始集群升级的准确模拟。
-
使用克隆的集群测试应用程序兼容性、性能、管理过程等。
-
如果遇到任何问题，请调整升级计划以解决这些问题。例如，调整任何应用程序代码以与更高版本的功能集兼容。根据集群中的数据量估计升级可能需要多长时间。您也可以选择将升级安排在集群不忙的时候。
-
在您对应用程序和工作负载在测试集群中正常运行感到满意后，您可以为生产集群执行就地升级。
-
努力显著减少集群在主要版本升级期间的总停机时间。为此，请确保升级时集群上的工作负载较低或为零。特别是确保在启动升级时没有长期运行的事务在进行。
蓝绿部署
在某些情况下，您的首要任务是立即从旧集群切换到升级后的集群。在此类情况下，您可以使用多步骤流程，并排运行新旧集群。此处，您可以将数据从旧集群复制到新集群，直到您准备好接管新集群。有关详细信息，请参阅使用 Amazon Aurora 蓝绿部署进行数据库更新。