将 Aurora MySQL 数据库集群的主要版本从 1.x 升级到 2.x - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

将 Aurora MySQL 数据库集群的主要版本从 1.x 升级到 2.x

在 2.08.1 之类的 Aurora MySQL 版本号中,2 表示主要版本。Aurora MySQL 版本 1 与 MySQL 5.6 兼容,Aurora MySQL 版本 2 与 MySQL 5.7 兼容。

与次要版本相比,在主要版本之间升级需要更广泛的计划和测试。这个过程可能需要大量时间。 升级完成后,您可能还有后续工作要执行。例如,出现这种情况可能是由于 SQL 兼容性、某些 MySQL 相关功能的工作方式或旧版本与新版本之间的参数设置不同。升级主要版本会将集群的 engine 属性从 aurora 更改为 aurora-mysql。确保更新与此集群一起使用的任何 Amazon CLI 或 API 自动化,以解释更改的 engine 值。

如果您有一个兼容 MySQL 5.6 的集群,并希望将其升级到兼容 MySQL 5.7 的集群,可以通过在集群本身上运行升级过程来实现。这种升级是就地升级,与您通过创建新集群进行的升级形成鲜明对比。此技术会保留集群的相同终端节点和其他特征。升级速度相对较快,因为它不需要将所有数据复制到新的集群卷。此稳定性有助于最大限度地减少应用程序中的任何配置更改。它还有助于减少升级后的集群的测试量,因为数据库实例的数量及其实例类的数量都保持不变。

就地升级机制包括在操作进行时关闭数据库集群。Aurora 会执行正常关机并完成未完成的操作,例如事务回滚和撤消清除。

提示

就地升级非常方便,因为它执行简单,并且可以最大限度地减少对关联应用程序的配置更改。例如,就地升级会为集群保留终端节点和数据库实例集。但是,就地升级所需的时间可能会有所不同,具体取决于架构的属性和集群的繁忙程度。因此,根据集群的需求,您可以在就地升级、从数据库集群快照还原 中所述的快照还原或其他升级技术(如 备选的蓝绿升级技术 中所述的升级)中选择。

为 Aurora MySQL 集群计划主要版本升级

为了确保在将集群升级到 Aurora MySQL 版本 2.x 后,您的应用程序和管理程序能够顺利运行,您可以进行一些预先计划和准备。要查看可为您的 Amazon CLI 脚本或基于 RDS API– 的应用程序更新哪种管理代码,请参阅就地升级如何影响集群的参数组Aurora MySQL 版本 1 与 2 之间的集群属性更改

提示

如果您的集群运行的版本低于 1.22.3,则升级可能需要更长时间,因为 Aurora MySQL 会将自动执行到 1.22.3 的升级作为第一步。为了最大限度地减少主要版本升级期间的停机时间,您可以提前进行到 Aurora MySQL 1.22.3 的初始次要版本升级。

您可以通过阅读 Aurora MySQL 就地升级的故障排除 了解升级期间可能会遇到的问题种类。对于可能导致升级需要很长时间的问题,您可以提前测试这些条件并进行更正。

要验证升级的集群的应用程序兼容性、性能、维护过程以及类似注意事项,您可以在进行真正的升级之前进行升级模拟。此技术对生产集群尤其有用。在这里,重要的是要尽量减少停机时间,并在升级完成后立即让升级后的集群准备就绪。

使用以下步骤:

  1. 创建原始集群的克隆。按照克隆 Aurora 数据库集群卷中过程操作。

  2. 设置与原始集群中类似的写入器和读取器数据库实例集。

  3. 对克隆的集群执行就地升级。按照如何执行就地升级中过程操作。创建克隆后立即开始升级。这样,集群卷仍然与原始集群的状态相同。如果克隆在升级之前处于空闲状态,则 Aurora 会在后台执行数据库清理过程。在这种情况下,克隆的升级并不是原始集群升级的准确模拟。

  4. 使用克隆的集群测试应用程序兼容性、性能、管理过程等。

  5. 如果遇到任何问题,请调整升级计划以解决这些问题。例如,调整任何应用程序代码以与 MySQL 5.7 功能集兼容。根据集群中的数据量估计升级可能需要多长时间。您也可以选择将升级安排在集群不忙的时候。

  6. 在您对应用程序和工作负载在 Aurora MySQL 版本 2.x 测试集群中正常运行感到满意后,您可以为生产集群执行就地升级。

  7. 为了最大限度地减少主要版本升级期间集群的总停机时间,请确保升级时集群上的工作负载较低或为零。特别是确保在启动升级时没有长期运行的事务在进行。

Aurora MySQL 主要版本升级路径

并非所有类型或版本的 Aurora MySQL 集群都可以使用就地升级机制。通过查阅下表,您可以了解每个 Aurora MySQL 集群的适当升级路径。

Aurora MySQL 数据集集群类型 它可以使用就地升级吗? 操作

Aurora MySQL 预置集群,1.22.3 或更高版本

这是最快的升级路径。Aurora 不需要先执行中间升级。

Aurora MySQL 预置集群,1.22.3 之前的版本

升级可能比集群已在运行 Aurora MySQL 1.22.3 或更高版本的情况下需要更长的时间。在主要版本升级期间,Aurora MySQL 会使用 Aurora MySQL 的最低版本 1.22.3 执行一些数据库清理操作。Aurora MySQL 会在进行该清理操作前,首先自动执行对 1.22.3 的升级。

Aurora MySQL 预置集群,2.0 或更高版本

就地升级仅适用于与 5.6 兼容的 Aurora MySQL 集群,以实现与 MySQL 5.7 的兼容性。Aurora MySQL版本 2 已与 5.7 兼容。使用升级次要版本或补丁程序级别的过程从一个兼容 5.7 的版本更改为另一个版本。

Aurora Serverless 集群

为兼容 5.6 的 Aurora Serverless 集群拍摄快照。将快照还原为兼容 5.7 的集群。您可以选择创建新集群 Aurora Serverless 或其他类型的兼容 5.7 的集群。

Aurora 全局数据库中的集群

按照对 Aurora 全局数据库中的集群进行就地升级的过程操作。在全局数据库中的主集群上执行升级。Aurora 可同时升级主群集和全局数据库中的所有辅助集群。如果您使用 Amazon CLI 或 RDS API,请调用 modify-global-cluster 命令或 ModifyGlobalCluster 操作,而不是 modify-db-clusterModifyDBCluster

多主集群

目前,多主复制不适用于与 Aurora MySQL 5.7 兼容的集群。

并行查询集群

也许

如果您有使用旧 Aurora MySQL 版本的现有并行查询集群,请先将该集群升级到 Aurora MySQL 1.23。按照并行查询的升级注意事项中过程操作。在此初始升级后,您可以对配置参数进行一些更改以重新启用并行查询。然后你可以执行就地升级。在此情况下,为 Aurora MySQL 版本选择 2.09.1 或更高版本。

二进制日志复制的目标集群

也许

如果二进制日志复制来自兼容 5.6 的 Aurora MySQL 集群,您可以执行就地升级。如果二进制日志复制来自 RDS 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 将回滚所有更改,并且集群具有与以前相同的引擎版本、元数据等。

升级过程包括三个阶段:

  1. Aurora 在开始升级过程之前执行一系列检查。在 Aurora 进行这些检查的同时,您的集群会保持运行。例如,集群不能有任何处于准备状态的 XA 事务,也不能处理任何数据定义语言 (DDL) 语句。例如,您可能需要关闭提交某些类型的 SQL 语句的应用程序。或者,您只需等待某些长期运行的语句完成。然后再次尝试升级。有些检查会测试不会阻止升级但可能使升级花费很长时间的条件。

    如果 Aurora 检测到任何必需条件未满足,请修改事件详细信息中识别的条件。按照Aurora MySQL 就地升级的故障排除中的指导进行操作。如果 Aurora 检测到可能导致升级缓慢的情况,请计划在一段较长的时间内监控升级。

  2. Aurora 使您的集群离线。然后,Aurora 执行与上一阶段类似的一组测试,以确认关机过程中没有产生新问题。如果此时 Aurora 检测到任何会阻止升级的情况,Aurora 会取消升级并使集群恢复联机。在这种情况下,请确认条件何时不再适用,然后再次开始升级。

  3. Aurora 创建集群卷的快照。假设您在升级完成后兼容性或其他类型的问题。或者假设您想同时使用原始集群和升级后的集群执行测试。在这种情况下,您可以从此快照中还原,以使用原始引擎版本和原始数据创建新集群。

    提示

    此快照是手动快照。但是,即使您已经达到手动快照的配额,Aurora 也可以创建手动快照并继续升级过程。此快照将保持永久性,直到您删除它。完成所有升级后测试后,您可以删除此快照以最大限度地减少存储费用。

  4. Aurora 克隆集群卷。克隆是一项快速的操作,不涉及复制实际的表数据。如果 Aurora 在升级过程中遇到问题,它将从克隆的集群卷恢复为原始数据,然后使集群重新联机。升级期间的临时克隆卷不受单个集群卷的克隆数量的通常限制。

  5. Aurora 对写入器数据库实例执行清理关机。在清理关机期间,以下操作的进度事件每 15 分钟记录一次。您可以在 RDS 控制台的 Events(事件)页面上检查事件发生的事件。

    • Aurora 清除旧版本行的撤销记录。

    • Aurora 回滚任何未提交的事务。

  6. Aurora 升级写入器数据库实例上的引擎版本:

    • Aurora 在写入器数据库实例上安装新引擎版本的二进制文件。

    • Aurora 使用写入器数据库实例将数据升级为兼容 MySQL 5.7 的格式。在此阶段,Aurora 修改系统表并执行影响集群卷中的数据的其他转换。特别是,Aurora 升级系统表中的分区元数据以与 MySQL 5.7 分区格式兼容。如果集群中的表有大量分区,则此阶段可能需要花费很长时间。

      如果在此阶段发生任何错误,您可以在 MySQL 错误日志中找到详细信息。此阶段开始后,如果升级过程因任何原因失败,Aurora 将从克隆的集群卷中恢复原始数据。

  7. Aurora 升级读取器数据库实例上的引擎版本。

  8. 升级过程已完成。Aurora 记录最后一个事件以表示升级过程已成功完成。现在,您的数据库集群正在运行新的主要版本。

如何执行就地升级

要升级 Aurora MySQL 数据库集群的主要版本

  1. (可选)查看 Aurora MySQL 主要版本就地升级的工作原理 中的背景材料。按 为 Aurora MySQL 集群计划主要版本升级 中所述执行任何升级前的计划和测试。

  2. 登录 Amazon Web Services Management Console 并通过以下网址打开 Amazon RDS 控制台:https://console.amazonaws.cn/rds/

  3. 如果您将自定义参数组与原始 1.x 集群一起使用,请创建相应的兼容 MySQL 5.7 的参数组。对这个新参数组中的配置参数进行任何必要的调整。有关更多信息,请参阅 就地升级如何影响集群的参数组

  4. 在导航窗格中,选择数据库

  5. 在列表中,选择您要修改的数据库集群。

  6. 选择修改

  7. 对于 Version(版本),选择 Aurora MySQL 2.x 版本。

  8. 选择继续

  9. 在下一页上,指定何时执行升级。选择 During the next scheduled maintenance window(在下一个计划的维护时段内)或 Immediately(立即)。

  10. (可选)在升级过程中定期检查 RDS 控制台中的 Events(事件)页面。这样做可以帮助您监控升级进度并识别问题。如果升级遇到任何问题,请参阅Aurora MySQL 就地升级的故障排除以了解要采取的步骤。

  11. 如果您在此过程开始时创建了一个新的兼容 MySQL 5.7 的参数组,请将自定义参数组与升级的集群关联起来。有关更多信息,请参阅 就地升级如何影响集群的参数组

    注意

    执行此步骤需要您再次重新启动集群以应用新的参数组。

  12. (可选)完成任何升级后测试后,请删除升级开始时 Aurora 创建的手动快照。

要升级 Aurora MySQL 数据库集群的主要版本,请结合使用 Amazon CLI modify-db-cluster 命令与以下所需的参数:

  • --db-cluster-identifier

  • --engine aurora-mysql

  • --engine-version

  • --allow-major-version-upgrade

  • --apply-immediately 或者 --no-apply-immediately

如果您的集群使用任何自定义参数组,则还要包含以下一个或两个选项:

  • --db-cluster-parameter-group-name,如果集群使用自定义集群参数组

  • --db-instance-parameter-group-name,如果集群中的任何实例使用自定义数据库参数组

以下示例将 sample-cluster 数据库集群升级到 Aurora MySQL 版本 2.09.0。升级会立即进行,而不是等待下一个维护时段。

对于 Linux、macOS 或 Unix:

aws rds modify-db-cluster \ --db-cluster-identifier sample-cluster \ --engine aurora-mysql \ --engine-version 5.7.mysql_aurora.2.09.0 \ --allow-major-version-upgrade \ --apply-immediately

对于 Windows:

aws rds modify-db-cluster ^ --db-cluster-identifier sample-cluster ^ --engine aurora-mysql ^ --engine-version 5.7.mysql_aurora.2.09.0 ^ --allow-major-version-upgrade ^ --apply-immediately

您可以将其他 CLI 命令与 modify-db-cluster 结合使用,以创建执行和验证升级的自动端到端流程。有关更多信息以及示例,请参阅 Aurora MySQL 就地升级教程

注意

如果您的集群属于 Aurora 全局数据库的一部分,则就地升级程序会略有不同。您可以调用 modify-global-cluster 命令操作而不是 modify-db-cluster。有关更多信息,请参阅全局数据库的就地升级

要升级 Aurora MySQL 数据库集群的主要版本,请结合使用 RDS API ModifyDBCluster 操作与以下所需的参数:

  • DBClusterIdentifier

  • Engine

  • EngineVersion

  • AllowMajorVersionUpgrade

  • ApplyImmediately(设置为 truefalse

注意

如果您的集群属于 Aurora 全局数据库的一部分,则就地升级程序会略有不同。您将调用 ModifyGlobalCluster 操作而不是 ModifyDBCluster。有关更多信息,请参阅全局数据库的就地升级

就地升级如何影响集群的参数组

对于与 MySQL 5.6 或 5.7 兼容的集群,Aurora 参数组具有不同的配置设置集。执行就地升级时,升级后的集群及其所有实例必须使用相应的兼容 5.7 的集群和实例参数组。如果您的集群和实例使用默认的兼容 5.6 的参数组,则升级的集群和实例将从默认的兼容 5.7 的参数组开始。如果您的集群和实例使用任何自定义参数组,则必须创建相应的兼容 5.7 的参数组,并在升级过程中指定这些参数组。

如果您的原始集群使用自定义的兼容 5.6 的集群参数组,请创建相应的兼容 5.7 的集群参数组。作为升级过程的一部分,您可以将该参数组与集群关联。

同样,创建任何相应的兼容 5.7 的数据库参数组。作为升级过程的一部分,您可以将该参数组与集群中的所有数据库实例关联。

Aurora MySQL 版本 1 与 2 之间的集群属性更改

对于兼容 MySQL 5.6 的集群,您用于 Amazon CLI 命令或 RDS API 操作中的 engine 参数的值为 aurora。对于兼容 MySQL 5.7 的集群,相应的值为 aurora-mysql。从 Aurora MySQL 版本 1 升级到版本 2 时,请确保更改用于设置或管理 Aurora MySQL 集群和数据库实例的任何应用程序或脚本。

此外,请更改操作参数组的代码,以考虑到兼容 MySQL 5.6 和 5.7 的集群的默认参数组名称不同。Aurora MySQL 版本 1 集群的默认参数组名称为 default.aurora5.6。Aurora MySQL 版本 2 集群的相应参数组名称为 default.aurora-mysql5.7

例如,升级之前,您可能有适用于您的集群的类似以下内容的代码。

# Add a new DB instance to a MySQL 5.6-compatible cluster. create-db-instance --db-instance-identifier instance-2020-04-28-6889 --db-cluster-identifier cluster-2020-04-28-2690 \ --db-instance-class db.t2.small --engine aurora --region us-east-1 # Find the Aurora MySQL v1.x versions available for minor version upgrades and patching. aws rds describe-orderable-db-instance-options --engine aurora --region us-east-1 \ --query 'OrderableDBInstanceOptions[].{EngineVersion:EngineVersion}' --output text # Check the default parameter values for MySQL 5.6-compatible clusters. aws rds describe-db-parameters --db-parameter-group-name default.aurora5.6 --region us-east-1

升级集群的主要版本后,请按如下方式修改该代码。

# Add a new DB instance to a MySQL 5.7-compatible cluster. create-db-instance --db-instance-identifier instance-2020-04-28-3333 --db-cluster-identifier cluster-2020-04-28-2690 \ --db-instance-class db.t2.small --engine aurora-mysql --region us-east-1 # Find the Aurora MySQL v2.x versions available for minor version upgrades and patching. aws rds describe-orderable-db-instance-options --engine aurora-mysql --region us-east-1 \ --query 'OrderableDBInstanceOptions[].{EngineVersion:EngineVersion}' --output text # Check the default parameter values for MySQL 5.7-compatible clusters. aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1

全局数据库的就地升级

对于 Aurora 全局数据库,您可以按照Aurora MySQL 主要版本就地升级的工作原理中的说明升级主集群。在全局数据库中的主集群上执行升级。Aurora 会同时自动升级所有的辅助集群。所有的主集群和辅助集群必须运行相同的 Aurora MySQL 主要版本。此要求是因为对系统表、数据文件格式等所做的任何更改都会自动复制到所有辅助集群。

如果您使用 Amazon CLI 或 RDS API,请通过调用 modify-global-cluster 命令或 ModifyGlobalCluster 操作(而不是 modify-db-clusterModifyDBCluster)来启动升级过程。

升级后

如果您升级的集群启用了回溯功能,您无法将升级的集群回溯到升级之前的时间。

Aurora MySQL 就地升级的故障排除

Aurora MySQL 就地升级的故障排除
就地升级被取消或减慢的原因 允许在维护时段内完成就地升级的解决方案
集群具有处于准备状态的 XA 事务 Aurora 取消升级。 提交或回滚所有准备好的 XA 事务。
集群正在处理数据定义语言 (DDL) 语句 Aurora 取消升级。 考虑等待并在所有 DDL 语句完成后执行升级。
集群有很多行未提交的更改 升级可能需要较长时间。 升级过程将回滚未提交的更改。这种情况的指示器为 INFORMATION_SCHEMA.INNODB_TRX 表中的 TRX_ROWS_MODIFIED 值。考虑仅在提交或回退所有大型事务后才执行升级。
集群有大量的撤消记录 升级可能需要较长时间。 即使未提交的事务不会影响大量行,也可能涉及大量数据。例如,您可能在插入大型 BLOB。Aurora 不会自动检测或生成此类事务活动的事件。这种情况的指示器为历史记录列表长度。升级过程将回滚未提交的更改。考虑仅在历史记录列表长度较小之后才执行升级。
集群正在提交大型二进制日志事务 升级可能需要较长时间。 升级过程将等到应用二进制日志更改时。在此期间,可能会启动更多事务或 DDL 语句,从而进一步减慢升级过程。在集群不忙于生成二进制日志复制更改时,安排升级过程。Aurora 不会自动检测或生成此情况的事件。

您可以使用以下步骤对上表中的某些条件执行自己的检查。这样,您可以在知道数据库处于可以成功快速地完成升级的状态时安排升级。

  • 您可以通过执行 XA RECOVER 语句来检查未完成的 XA 事务。然后,您可以在开始升级之前提交或回滚 XA 事务。

  • 您可以通过执行 SHOW PROCESSLIST 语句并在输出中查找 CREATEDROPALTERRENAMETRUNCATE 语句来检查 DDL 语句。在开始升级之前,允许所有 DDL 完成。

  • 您可以通过查询 INFORMATION_SCHEMA.INNODB_TRX 表来检查未提交的行总数。该表为每个事务包含一行。TRX_ROWS_MODIFIED 列包含事务修改或插入的行数。

  • 您可以通过执行 SHOW ENGINE INNODB STATUS SQL 语句并在输出中查找 History list length 来检查 InnoDB 历史记录列表的长度。您还可以通过运行以下查询直接检查值:

    SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

    历史记录列表的长度对应于数据库为实施多版本并发控制 (MVCC) 而存储的撤消信息量。

Aurora MySQL 就地升级教程

以下 Linux 示例展示了如何使用 Amazon CLI 执行就地升级过程的一般步骤。

第一个示例创建了运行 Aurora MySQL 1.x 版本的 Aurora 数据库集群。该集群包括写入器数据库实例和读取器数据库实例。wait db-instance-available 命令会暂停,直到写入器数据库实例可用。此时,集群做好升级准备。

$ aws rds create-db-cluster --db-cluster-identifier cluster-56-2020-11-17-3824 --engine aurora \ --db-cluster-version 5.6.mysql_aurora.1.22.3 ... $ aws rds create-db-instance --db-instance-identifier instance-2020-11-17-7832 \ --db-cluster-identifier cluster-56-2020-11-17-3824 --db-instance-class db.t2.medium --engine aurora ... $ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-7832 --region us-east-1

您可以将集群升级到的 Aurora MySQL 2.x 版本取决于集群当前正在运行的 1.x 版本和集群所位于的 Amazon 区域。第一个命令(带 --output text)只显示可用的目标版本。第二个命令显示响应的完整 JSON 输出。在该详细响应中,您可以看到详细信息,例如用于 engine 参数的 aurora-mysql 值,以及升级到 2.07.3 表示主要版本升级的情况。

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 \ --query '*[].{EngineVersion:EngineVersion}' --output text 5.6.mysql_aurora.1.22.3 $ aws rds describe-db-engine-versions --engine aurora --engine-version 5.6.mysql_aurora.1.22.3 \ --query '*[].[ValidUpgradeTarget]' [ [ [ { "Engine": "aurora-mysql", "EngineVersion": "5.7.mysql_aurora.2.07.3", "Description": "Aurora (MySQL 5.7) 2.07.3", "AutoUpgrade": false, "IsMajorVersionUpgrade": true } ] ] ]

此示例表示,如果您输入的目标版本号不是集群的有效升级目标,Aurora 不会执行升级。Aurora 也不会执行主要版本升级,除非您包含 --allow-major-version-upgrade 参数。这样一来,您就不能意外执行有可能需要大量测试和更改应用程序代码的升级。

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \ --engine-version 5.7.mysql_aurora.2.04.9 --region us-east-1 --apply-immediately An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.6.mysql_aurora.1.22.3 with requested version 5.7.mysql_aurora.2.04.9. $ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \ --engine-version 5.7.mysql_aurora.2.09.0 --region us-east-1 --apply-immediately An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version. $ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \ --engine-version 5.7.mysql_aurora.2.09.0 --region us-east-1 --apply-immediately --allow-major-version-upgrade { "DBClusterIdentifier": "cluster-56-2020-11-17-9355", "Status": "available", "Engine": "aurora", "EngineVersion": "5.6.mysql_aurora.1.22.3" }

集群和关联数据库实例的状态需要一段时间才能更改为 upgrading。集群和数据库实例的版本号仅在升级完成后才会更改。同样,您可以使用 wait db-instance-available 命令让写入器数据库实例等到升级完成后再继续。

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 \ --query '*[].[Status,EngineVersion]' --output text upgrading 5.6.mysql_aurora.1.22.3 $ aws rds describe-db-instances --db-instance-identifier instance-2020-11-17-5158 \ --query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]' { "DBInstanceIdentifier": "instance-2020-11-17-5158", "DBInstanceStatus": "upgrading" } $ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-5158

此时,集群的版本号与为升级指定的版本号匹配。

$ aws rds describe-db-clusters --region us-east-1 --db-cluster-identifier cluster-56-2020-11-17-9355 \ --query '*[].[EngineVersion]' --output text 5.7.mysql_aurora.2.09.0

前面的示例通过指定 --apply-immediately 参数进行了立即升级。为了让升级在集群预计不繁忙的方便之时进行,您可以指定 --no-apply-immediately 参数。这样做可以在集群的下一个维护时段内启动升级。维护时段定义了可以启动维护操作的时间段。在维护时段内,长时间运行的操作可能无法完成。因此,即使您预计升级可能需要很长时间,也不需要定义更大的维护时段。

以下示例升级最初运行 Aurora MySQL 版本 1.22.2 的集群。在 describe-db-engine-versions 输出中,FalseTrue 值表示 IsMajorVersionUpgrade 属性。您可以从版本 1.22.2 升级到一些其他 1.* 版本。这些升级不被视为主要版本升级,因此不需要就地升级。就地升级仅适用于升级到列表中显示的版本 2.07 和版本 2.09。

$ aws rds describe-db-clusters --region us-east-1 --db-cluster-identifier cluster-56-2020-11-17-3824 \ --query '*[].{EngineVersion:EngineVersion}' --output text 5.6.mysql_aurora.1.22.2 $ aws rds describe-db-engine-versions --engine aurora --engine-version 5.6.mysql_aurora.1.22.2 \ --query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text 5.6.mysql_aurora.1.22.3 False 5.6.mysql_aurora.1.23.0 False 5.6.mysql_aurora.1.23.1 False 5.7.mysql_aurora.2.07.1 True 5.7.mysql_aurora.2.07.1 True 5.7.mysql_aurora.2.07.2 True 5.7.mysql_aurora.2.07.3 True 5.7.mysql_aurora.2.09.1 True $ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \ --engine-version 5.7.mysql_aurora.2.09.0 --region us-east-1 --no-apply-immediately --allow-major-version-upgrade ...

如果在没有指定的维护时段的情况下创建集群,Aurora 会随机选择一周中的一天。在这种情况下,modify-db-cluster 命令将在星期一提交。因此,我们将维护时段更改为星期二早上。所有时间都以 UTC 时区表示。tue:10:00-tue:10:30 时段对应于太平洋时间凌晨 2:00-2:30。维护时段的更改会立即生效。

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 --region us-east-1 --query '*[].[PreferredMaintenanceWindow]' [ [ "sat:08:20-sat:08:50" ] ] $ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-3824 --preferred-maintenance-window tue:10:00-tue:10:30" $ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-3824 --region us-east-1 --query '*[].[PreferredMaintenanceWindow]' [ [ "tue:10:00-tue:10:30" ] ]
$ aws rds create-db-cluster --engine aurora --db-cluster-identifier cluster-56-2020-11-17-9355 \ --region us-east-1 --master-username my_username --master-user-password my_password { "DBClusterIdentifier": "cluster-56-2020-11-17-9355", "DBClusterArn": "arn:aws-cn:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-9355", "Engine": "aurora", "EngineVersion": "5.6.mysql_aurora.1.22.2", "Status": "creating", "Endpoint": "cluster-56-2020-11-17-9355.cluster-ccfbt21ixr91.us-east-1-integ.rds.amazonaws.com", "ReaderEndpoint": "cluster-56-2020-11-17-9355.cluster-ro-ccfbt21ixr91.us-east-1-integ.rds.amazonaws.com" } $ aws rds create-db-instance --db-instance-identifier instance-2020-11-17-5158 \ --db-cluster-identifier cluster-56-2020-11-17-9355 --db-instance-class db.r5.large --region us-east-1 --engine aurora { "DBInstanceIdentifier": "instance-2020-11-17-5158", "DBClusterIdentifier": "cluster-56-2020-11-17-9355", "DBInstanceClass": "db.r5.large", "DBInstanceStatus": "creating" } $ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-5158 --region us-east-1

以下示例说明如何获取升级所生成的事件的报告。--duration 参数表示检索事件信息的分钟数。系统需要此参数,因为默认情况下,describe-events 仅返回最后一个小时的事件。

$ aws rds describe-events --source-type db-cluster --source-identifier cluster-56-2020-11-17-3824 --duration 20160 { "Events": [ { "SourceIdentifier": "cluster-56-2020-11-17-3824", "SourceType": "db-cluster", "Message": "DB cluster created", "EventCategories": [ "creation" ], "Date": "2020-11-17T01:24:11.093000+00:00", "SourceArn": "arn:aws-cn:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824" }, { "SourceIdentifier": "cluster-56-2020-11-17-3824", "SourceType": "db-cluster", "Message": "Upgrade in progress: Performing online pre-upgrade checks.", "EventCategories": [ "maintenance" ], "Date": "2020-11-18T22:57:08.450000+00:00", "SourceArn": "arn:aws-cn:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824" }, { "SourceIdentifier": "cluster-56-2020-11-17-3824", "SourceType": "db-cluster", "Message": "Upgrade in progress: Performing offline pre-upgrade checks.", "EventCategories": [ "maintenance" ], "Date": "2020-11-18T22:57:59.519000+00:00", "SourceArn": "arn:aws-cn:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824" }, { "SourceIdentifier": "cluster-56-2020-11-17-3824", "SourceType": "db-cluster", "Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-cluster-56-2020-11-17-3824-5-6-mysql-aurora-1-22-2-to-5-7-mysql-aurora-2-09-0-2020-11-18-22-55].", "EventCategories": [ "maintenance" ], "Date": "2020-11-18T23:00:22.318000+00:00", "SourceArn": "arn:aws-cn:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824" }, { "SourceIdentifier": "cluster-56-2020-11-17-3824", "SourceType": "db-cluster", "Message": "Upgrade in progress: Cloning volume.", "EventCategories": [ "maintenance" ], "Date": "2020-11-18T23:01:45.428000+00:00", "SourceArn": "arn:aws-cn:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824" }, { "SourceIdentifier": "cluster-56-2020-11-17-3824", "SourceType": "db-cluster", "Message": "Upgrade in progress: Purging undo records for old row versions.Records remaining: 164", "EventCategories": [ "maintenance" ], "Date": "2020-11-18T23:02:25.141000+00:00", "SourceArn": "arn:aws-cn:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824" }, { "SourceIdentifier": "cluster-56-2020-11-17-3824", "SourceType": "db-cluster", "Message": "Upgrade in progress: Purging undo records for old row versions.Records remaining: 164", "EventCategories": [ "maintenance" ], "Date": "2020-11-18T23:06:23.036000+00:00", "SourceArn": "arn:aws-cn:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824" }, { "SourceIdentifier": "cluster-56-2020-11-17-3824", "SourceType": "db-cluster", "Message": "Upgrade in progress: Upgrading database objects.", "EventCategories": [ "maintenance" ], "Date": "2020-11-18T23:06:48.208000+00:00", "SourceArn": "arn:aws-cn:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824" }, { "SourceIdentifier": "cluster-56-2020-11-17-3824", "SourceType": "db-cluster", "Message": "Database cluster major version has been upgraded", "EventCategories": [ "maintenance" ], "Date": "2020-11-18T23:10:28.999000+00:00", "SourceArn": "arn:aws-cn:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824" } ] }

备选的蓝绿升级技术

对于首要任务是立即从旧集群切换到升级后的集群的情况,您可以使用并排运行新旧集群的多步过程。在这种情况下,您可以将数据从旧集群复制到新集群,直到您准备好接管新集群。有关详细信息,请参阅本博客文章:在最少停机时间下执行 Amazon Aurora MySQL 的主要版本升级