升级 Amazon Aurora MySQL 数据库集群的主要版本
在类似于 2.08.1 的 Aurora MySQL 版本号中,2 表示主要版本。Aurora MySQL 版本 1 与 MySQL 5.6 兼容。Aurora MySQL 版本 2 与 MySQL 5.7 兼容。Aurora MySQL 版本 3 与 MySQL 8.0 兼容。
与次要版本相比,在主要版本之间升级需要更广泛的计划和测试。这个过程可能需要大量时间。升级完成后,您可能还有后续工作要执行。例如,出现这种情况可能是由于 SQL 兼容性或某些 MySQL 相关功能的工作方式不同。或者可能是由于旧版本和新版本之间的参数设置不同而导致的。
主题
从 Aurora MySQL 2.x 升级到 3.x
如果您有一个与 MySQL 5.7 兼容的集群,并希望将其升级到与 MySQL 8.0 兼容的集群,可以通过在集群本身上运行升级过程来实现。这种升级是就地升级,与您通过创建新集群进行的升级形成鲜明对比。此技术会保留集群的相同终端节点和其他特征。升级速度相对较快,因为它不需要将所有数据复制到新的集群卷。此稳定性有助于最大限度地减少应用程序中的任何配置更改。它还有助于减少升级后集群的测试量。这是因为数据库实例的数量及其实例类都保持不变。
就地升级机制会在进行操作的过程中关闭您的数据库集群。Aurora 将执行正常关机,并完成进行中的操作(例如事务回滚和撤消清除)。有关更多信息,请参阅Aurora MySQL 主要版本就地升级的工作原理。
就地升级非常方便,因为它执行简单,并且可以最大限度地减少对关联应用程序的配置更改。例如,就地升级会为集群保留终端节点和数据库实例集。但是,就地升级所需的时间可能会有所不同,具体取决于架构的属性和集群的繁忙程度。因此,根据集群的需求,您可能需要在多种升级技术间进行选择。其中包括就地升级和快照还原,如 从数据库集群快照还原 中所述。它们还包括其他升级技术,例如 备选的蓝绿升级技术 中所述的技术。
有关 Aurora MySQL 版本 3 及其新功能的一般信息,请参阅 与 MySQL 8.0 兼容的 Aurora MySQL 版本 3。有关计划升级的详细信息,请参阅 Aurora MySQL 版本 3 的升级计划 和 升级到 Aurora MySQL 版本 3。
当您将集群的主要版本从 2.x 升级到 3.x 时,原始集群和升级后的集群都对 engine
属性使用相同的 aurora-mysql
值。
从 Aurora MySQL 1.x 升级到 2.x
将主要版本从 1.x 升级到 2.x 会将集群的 engine
属性从 aurora
更改为 aurora-mysql
。确保更新与此集群一起使用的任何 Amazon CLI 或 API 自动化,以解释更改的 engine
值。
如果您有一个与 MySQL 5.6 兼容的集群,并希望将其升级到与 MySQL 5.7 兼容的集群,可以通过在集群本身上运行升级过程来实现。这种升级是就地升级,与您通过创建新集群进行的升级形成鲜明对比。此技术会保留集群的相同终端节点和其他特征。升级速度相对较快,因为它不需要将所有数据复制到新的集群卷。此稳定性有助于最大限度地减少应用程序中的任何配置更改。它还有助于减少升级后集群的测试量。这是因为数据库实例的数量及其实例类都保持不变。
就地升级机制会在进行操作的过程中关闭您的数据库集群。Aurora 将执行正常关机,并完成进行中的操作(例如事务回滚和撤消清除)。
就地升级非常方便,因为它执行简单,并且可以最大限度地减少对关联应用程序的配置更改。例如,就地升级会为集群保留终端节点和数据库实例集。但是,就地升级所需的时间可能会有所不同,具体取决于架构的属性和集群的繁忙程度。因此,根据集群的需求,您可以在就地升级、从数据库集群快照还原 中所述的快照还原或其他升级技术(如 备选的蓝绿升级技术 中所述的升级)中选择。
如果您的集群运行的版本低于 1.22.3,则升级可能需要更长时间。这是因为 Aurora MySQL 首先会自动升级至 1.22.3。为了最大限度地减少主要版本升级期间的停机时间,您可以提前进行到 Aurora MySQL 1.22.3 的初始次要版本升级。
为 Aurora MySQL 集群计划主要版本升级
为了确保在主要版本之间升级集群后,您的应用程序和管理过程能够顺利运行,应进行一些预先计划和准备。要查看可为您的 Amazon CLI 脚本或基于 RDS API 的应用程序更新哪些类型的管理代码,请参阅 就地升级如何影响集群的参数组。另请参阅Aurora MySQL 版本之间的集群属性更改。
要了解升级期间可能会遇到的问题种类,请参阅 Aurora MySQL 就地升级的故障排除。对于可能导致升级需要很长时间的问题,您可以提前测试这些条件并进行更正。
您可以检查升级后集群的应用程序兼容性、性能、维护过程以及类似注意事项。为此,您可以在真正进行升级之前执行升级模拟。此技术对生产集群尤其有用。在这里,重要的是要尽量减少停机时间,并在升级完成后立即让升级后的集群准备就绪。
使用以下步骤:
-
创建原始集群的克隆。按照克隆 Amazon Aurora 数据库集群卷中过程操作。
-
设置与原始集群中类似的写入器和读取器数据库实例集。
-
对克隆的集群执行就地升级。按照如何执行就地升级中过程操作。
创建克隆后立即开始升级。这样,集群卷仍然与原始集群的状态相同。如果克隆在升级之前处于空闲状态,则 Aurora 会在后台执行数据库清理过程。在这种情况下,克隆的升级并不是原始集群升级的准确模拟。
-
使用克隆的集群测试应用程序兼容性、性能、管理过程等。
-
如果遇到任何问题,请调整升级计划以解决这些问题。例如,调整任何应用程序代码以与更高版本的功能集兼容。根据集群中的数据量估计升级可能需要多长时间。您也可以选择将升级安排在集群不忙的时候。
-
在您对应用程序和工作负载在测试集群中正常运行感到满意后,您可以为生产集群执行就地升级。
-
努力最大限度地减少集群在主要版本升级期间的总停机时间。为此,请确保升级时集群上的工作负载较低或为零。特别是确保在启动升级时没有长期运行的事务在进行。
有关升级到 Aurora MySQL 版本 3 的特定信息,请参阅 Aurora MySQL 版本 3 的升级计划。
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 首先会自动升级至 1.22.3。为了最大限度地减少主要版本升级期间的停机时间,您可以提前进行到 Aurora MySQL 1.22.3 的初始次要版本升级。 |
Aurora MySQL 预置集群,2.0 或更高版本 |
是 |
与 5.7 兼容的 Aurora MySQL 集群支持就地升级。 有关升级到 Aurora MySQL 版本 3 的信息,请参阅 Aurora MySQL 版本 3 的升级计划 和 升级到 Aurora MySQL 版本 3。 |
Aurora MySQL 预调配集群,3.01.0 或更高版本 |
不适用 |
使用次要版本升级过程在 Aurora MySQL 版本 3 的各版本之间进行升级。 |
Aurora Serverless v1 集群 |
是 |
您可以通过执行就地升级,从 MySQL 5.6 兼容 Aurora Serverless v1 版本升级到 MySQL 5.7 兼容版本。有关更多信息,请参阅修改 Aurora Serverless v1 数据库集群。 |
Aurora Serverless v2 集群 |
不适用 |
目前,只有 Aurora MySQL 版本 3 支持 Aurora Serverless v2。 |
Aurora 全局数据库中的集群 |
也许 |
要将 Aurora MySQL 版本 1 升级到版本 2,请按照对 Aurora 全局数据库中的集群进行就地升级的过程操作。在全局数据库中的主集群上执行升级。Aurora 会同时升级全局数据库中的主集群以及所有辅助集群。如果您使用 Amazon CLI 或 RDS API,请调用 要将全局数据库从 Aurora MySQL 版本 2 升级到版本 3,请使用快照还原方法。有关更多信息,请参阅从数据库集群快照还原。 |
多主集群 |
否 |
目前,多主复制不适用于与 Aurora MySQL 5.7 兼容的集群。您也无法通过执行快照还原来升级多主集群。 要将数据从多主集群移动到与 Aurora MySQL 5.7 或 8.0 兼容的集群,请使用逻辑转储。可以使用 Amazon Database Migration Service(Amazon DMS)之类的工具或 mysqldump 命令生成逻辑转储。 |
并行查询集群 |
是 |
如果您有使用旧 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 将回滚所有更改,并且集群具有与以前相同的引擎版本、元数据等。
升级过程包括三个阶段:
-
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 数据库集群的主要版本
-
登录 Amazon Web Services Management Console 并通过以下网址打开 Amazon RDS 控制台:https://console.aws.amazon.com/rds/
。 -
如果您将自定义参数组用于原始数据库集群,请创建与新的主要版本兼容的相应参数组。对这个新参数组中的配置参数进行任何必要的调整。有关更多信息,请参阅“就地升级如何影响集群的参数组”。
-
在导航窗格中,选择 Databases (数据库)。
-
在列表中,选择您要修改的数据库集群。
-
选择 Modify (修改)。
-
对于 Version(版本),选择新的 Aurora MySQL 主要版本。我们通常建议使用主要版本的最新次要版本。
-
选择 Continue (继续)。
-
在下一页上,指定何时执行升级。选择 During the next scheduled maintenance window(在下一个计划的维护时段内)或 Immediately(立即)。
-
(可选)在升级过程中定期检查 RDS 控制台中的 Events(事件)页面。这样做可以帮助您监控升级进度并识别问题。如果升级遇到任何问题,请参阅Aurora MySQL 就地升级的故障排除以了解要采取的步骤。
-
如果您在此过程开始时创建了一个新的参数组,请将自定义参数组与升级的集群关联起来。有关更多信息,请参阅就地升级如何影响集群的参数组。
注意 执行此步骤需要您再次重新启动集群以应用新的参数组。
-
(可选)完成任何升级后测试后,请删除升级开始时 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.10.2。升级会立即进行,而不是等待下一个维护时段。
例
对于 Linux、macOS 或 Unix:
aws rds modify-db-cluster \ --db-cluster-identifier sample-cluster \ --engine aurora-mysql \ --engine-version 5.7.mysql_aurora.2.10.2 \ --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.10.2 ^ --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
(设置为true
或false
)
如果您的集群属于 Aurora 全局数据库的一部分,则就地升级程序会略有不同。您将调用 ModifyGlobalCluster 操作而不是 ModifyDBCluster
。有关更多信息,请参阅“全局数据库的就地主要版本升级”。
就地升级如何影响集群的参数组
对于与 MySQL 5.6、5.7 或 8.0 兼容的集群,Aurora 参数组具有不同的配置设置集。执行就地升级时,升级后的集群及其所有实例必须使用相应的集群和实例参数组:
-
您的集群和实例可能使用与 5.6 兼容的原定设置参数组。如果是这样,则升级后的集群和实例将以与 5.7 兼容的原定设置参数组开始。如果您的集群和实例使用任何自定义参数组,则确保创建相应的与 5.7 兼容的参数组。此外,请确保在升级过程中指定这些参数组。
-
您的集群和实例可能使用与 5.7 兼容的原定设置参数组。如果是这样,则升级后的集群和实例将以与 8.0 兼容的原定设置参数组开始。如果您的集群和实例使用任何自定义参数组,则确保创建相应的与 8.0 兼容的参数组。此外,请确保在升级过程中指定这些参数组。
如果在升级过程中指定了任何自定义参数组,请确保在升级完成后手动重启集群。这样做会使集群开始使用您的自定义参数设置。
Aurora MySQL 版本之间的集群属性更改
对于兼容 MySQL 5.6 的集群,您用于 engine
命令或 RDS API 操作中的 Amazon CLI 参数的值为 aurora
。对于与 MySQL 5.7 或 MySQL 8.0 兼容的集群,相应的值为 aurora-mysql
。当从 Aurora MySQL 版本 1 升级到版本 2 或版本 3 时,请确保更改用于设置或管理 Aurora MySQL 集群和数据库实例的任何应用程序或脚本。
此外,请更改操作参数组的代码,以考虑到原定设置参数组名称对于 5.6、5.7 和 8.0 兼容的集群各不相同这一事实。Aurora MySQL 版本 1 集群的默认参数组名称为 default.aurora5.6
。Aurora MySQL 版本 2 和 3 集群的相应参数组名称为 default.aurora-mysql5.7
和 default.aurora-mysql8.0
。
例如,升级之前,您可能有适用于您的集群的类似以下内容的代码。
# Add a new DB instance to a MySQL 5.6–compatible cluster. aws rds 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. aws rds 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 Global Database,您可升级全局数据库集群。Aurora 会同时自动升级所有集群,并确保所有集群运行相同的引擎版本。此要求是因为对系统表、数据文件格式等所做的任何更改都会自动复制到所有辅助集群。
按照中的说明进行操作Aurora MySQL 主要版本就地升级的工作原理 指定要升级的内容时,请确保选择全局数据库集群,而不是其包含的集群之一。
您不能使用就地升级方法将 Aurora MySQL 数据库引擎从版本 2 升级到版本 3。改用快照还原方法。有关更多信息,请参阅从数据库集群快照还原。
如果您使用 Amazon Web Services Management Console,请选择具有角色 Global database(全局数据库)的项目。

如果您使用 Amazon CLI 或 RDS API,请通过调用 modify-global-cluster 命令或 ModifyGlobalCluster 操作来启动升级过程。您可以使用其中一个操作来代替 modify-db-cluster
或 ModifyDBCluster
。
在对该 Aurora 全局数据库执行主要版本升级时,无法为全局数据库集群指定自定义参数组。在全局集群的每个区域中创建自定义参数组。然后,在升级后手动将它们应用于区域集群。
升级后
如果您升级的集群启用了回溯功能,您无法将升级的集群回溯到升级之前的时间。
Aurora MySQL 就地升级的故障排除
可以使用以下提示帮助排查 Aurora MySQL 就地升级问题。这些提示不适用于 Aurora Serverless 数据库集群。
就地升级被取消或减慢的原因 | 效果 | 允许在维护时段内完成就地升级的解决方案 |
---|---|---|
集群具有处于准备状态的 XA 事务 | Aurora 取消升级。 | 提交或回滚所有准备好的 XA 事务。 |
集群正在处理数据定义语言 (DDL) 语句 | Aurora 取消升级。 | 考虑等待并在所有 DDL 语句完成后执行升级。 |
集群有很多行未提交的更改 | 升级可能需要较长时间。 |
升级过程将回滚未提交的更改。这种情况的指示器为 考虑仅在提交或回退所有大型事务后才执行升级。 |
集群有大量的撤消记录 | 升级可能需要较长时间。 |
即使未提交的事务不会影响大量行,也可能涉及大量数据。例如,您可能正在插入大型 BLOB。Aurora 不会自动检测或生成此类事务活动的事件。这种情况的指示器为历史记录列表长度。升级过程将回滚未提交的更改。 考虑仅在历史记录列表长度较小之后才执行升级。 |
集群正在提交大型二进制日志事务 | 升级可能需要较长时间。 |
升级过程将等到应用二进制日志更改时。在此期间,可能会启动更多事务或 DDL 语句,从而进一步减慢升级过程。 将升级过程安排在集群不忙于生成二进制日志复制更改的时间段。Aurora 不会自动检测或生成此情况的事件。 |
您可以使用以下步骤对上表中的某些条件执行自己的检查。这样,您可以在知道数据库处于可以成功快速地完成升级的状态时安排升级。
-
您可以通过执行
XA RECOVER
语句来检查未完成的 XA 事务。然后,您可以在开始升级之前提交或回滚 XA 事务。 -
您可以通过执行
SHOW PROCESSLIST
语句并在输出中查找CREATE
、DROP
、ALTER
、RENAME
和TRUNCATE
语句来检查 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
输出中,False
和 True
值表示 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-passwordmy_password
{ "DBClusterIdentifier": "cluster-56-2020-11-17-9355", "DBClusterArn": "arn:aws: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: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: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: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: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: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: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: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: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:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824" } ] }
备选的蓝绿升级技术
在某些情况下,您的首要任务是立即从旧集群切换到升级后的集群。在此类情况下,您可以使用多步骤流程,并排运行新旧集群。此处,您可以将数据从旧集群复制到新集群,直到您准备好接管新集群。有关详细信息,请参阅使用 Amazon RDS 蓝绿部署进行数据库更新。