如何执行就地升级
建议您查看 Aurora MySQL 主要版本就地升级的工作原理中的背景材料。
按为 Aurora MySQL 集群计划主要版本升级中所述执行任何升级前的计划和测试。
以下示例将 mydbcluster-cluster 数据库集群升级到 Aurora MySQL 版本 3.04.1。
要升级 Aurora MySQL 数据库集群的主要版本
-
登录 AWS 管理控制台 并通过以下网址打开 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 数据库集群的主要版本,请结合使用 AWS CLI modify-db-cluster 命令与以下所需的参数:
-
--db-cluster-identifier -
--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 版本 3.04.1。升级会立即进行,而不是等待下一个维护时段。
例
对于 Linux、macOS 或 Unix:
aws rds modify-db-cluster \ --db-cluster-identifier sample-cluster \ --engine-version 8.0.mysql_aurora.3.04.1 \ --allow-major-version-upgrade \ --apply-immediately
对于:Windows
aws rds modify-db-cluster ^ --db-cluster-identifier sample-cluster ^ --engine-version 8.0.mysql_aurora.3.04.1 ^ --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 版本兼容的集群,Aurora 参数组具有不同的配置设置集。执行就地升级时,升级后的集群及其所有实例,必须使用与新主要版本兼容的对应集群参数组和实例参数组:
如果您的集群和实例使用源版本的默认参数组,则升级后的集群和实例在启动时,将自动使用目标版本的默认参数组。如果您的集群和实例使用任何自定义参数组,请确保创建与目标版本兼容的对应参数组。此外,请确保在升级过程中指定这些参数组。
下表显示每个升级路径的默认参数组映射:
| 升级途径 | 源默认参数组 | 目标默认参数组 |
|---|---|---|
| Aurora MySQL 版本 2 到版本 3 | default.aurora-mysql5.7 |
default.aurora-mysql8.0 |
| Aurora MySQL 版本 3 到版本 8.4 | default.aurora-mysql8.0 |
default.aurora-mysql8.4 |
注意
对于大多数参数设置,您可以在两个点选择自定义参数组。也即,在您创建集群或稍后将参数组与集群关联时。
但是,如果您将非默认设置用于 lower_case_table_names 参数,则必须提前使用此设置来设置自定义参数组。然后,在执行快照还原操作以创建集群时指定参数组。创建集群后,lower_case_table_names 参数的任何更改不会产生任何影响。
在执行主要版本升级时,建议您为 lower_case_table_names 使用相同的设置。
使用基于 Aurora MySQL 的 Aurora Global Database 时,只有当您将 lower_case_table_names 参数设置为默认值并且重启全球数据库之后,才能执行主要版本的就地升级。有关可以使用的方法的更多信息,请参阅主要版本升级。。
Aurora MySQL 版本之间的集群属性更改
执行主要版本升级时,请确保检查用于设置或管理 Aurora MySQL 集群和数据库实例的任何应用程序或脚本。
此外,请更改操作参数组的代码,以便应对各主要版本的默认参数组名称各不相同这一实际情况。
Aurora MySQL 版本 2 到版本 3
例如,升级之前,您可能有适用于您的集群的类似以下内容的代码。
# 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
升级集群的主要版本后,请按如下方式修改该代码。
# Check the default parameter values for MySQL 8.0–compatible clusters. aws rds describe-db-parameters--db-parameter-group-name default.aurora-mysql8.0--region us-east-1
Aurora MySQL 版本 3 到版本 8.4
同样,如果您有代码引用了版本 3 默认参数组,请在升级后进行更新。
# Before upgrade: Check the default parameter values for MySQL 8.0–compatible clusters. aws rds describe-db-parameters--db-parameter-group-name default.aurora-mysql8.0--region us-east-1
# After upgrade: Check the default parameter values for MySQL 8.4–compatible clusters. aws rds describe-db-parameters--db-parameter-group-name default.aurora-mysql8.4--region us-east-1
全局数据库的就地主要版本升级
对于 Aurora Global Database,您可升级全局数据库集群。Aurora 会同时自动升级所有集群,并确保所有集群运行相同的引擎版本。此要求是因为对系统表、数据文件格式等所做的任何更改都会自动复制到所有辅助集群。
按照Aurora MySQL 主要版本就地升级的工作原理中的说明进行操作。指定要升级的内容时,请确保选择全局数据库集群,而不是其包含的集群之一。
如果您使用 AWS 管理控制台,请选择具有角色 Global database(全局数据库)的项目。
如果您使用 AWS CLI 或 RDS API,请通过调用 modify-global-cluster 命令或 ModifyGlobalCluster 操作来启动升级过程。您可以使用其中一个操作来代替 modify-db-cluster 或 ModifyDBCluster。
注意
在对该 Aurora Global Database 执行主要版本升级时,无法为全局数据库集群指定自定义参数组。在全局集群的每个区域中创建自定义参数组。然后,在升级后手动将它们应用于区域集群。
要使用 AWS CLI 升级 Aurora MySQL 全局数据库集群的主要版本,请结合使用 modify-global-cluster 命令与以下所需的参数:
-
--global-cluster-identifier -
--engine aurora-mysql -
--engine-version -
--allow-major-version-upgrade
以下示例将全局数据库集群升级到 Aurora MySQL 版本 3.04.2。
例
对于 Linux、macOS 或 Unix:
aws rds modify-global-cluster \ --global-cluster-identifierglobal_cluster_identifier\ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.04.2 \ --allow-major-version-upgrade
对于:Windows
aws rds modify-global-cluster ^ --global-cluster-identifierglobal_cluster_identifier^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.04.2 ^ --allow-major-version-upgrade
就地升级包含跨区域只读副本的数据库集群
您可以使用就地升级过程升级包含跨区域只读副本的 Aurora 数据库集群,但需要注意一些事项:
-
必须先升级只读副本数据库集群。如果先升级主集群,则会收到如下的错误消息:
无法升级数据库集群 test-xr-primary-cluster,因为关联的 Aurora 跨区域副本 test-xr-replica-cluster 尚未修补。升级 Aurora 跨区域副本并重试。这意味着主数据库集群的数据库引擎版本不能高于副本集群。
-
在升级主数据库集群之前,需停止写入工作负载并禁用对主集群的写入器数据库实例的任何新连接请求。
-
升级主集群时,选择自定义数据库集群参数组,将
binlog_format参数设置为支持二进制日志复制的值,例如MIXED。有关对 Aurora MySQL 使用二进制日志记录的更多信息,请参阅 Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制(二进制日志复制)。有关修改 Aurora MySQL 配置参数的更多信息,请参阅 Aurora MySQL 配置参数 和 Amazon Aurora 的参数组。
-
升级副本集群后,不要拖太久才升级主数据库集群。我们建议不要拖到超过下一个维护时段。
-
升级主数据库集群后,重启其写入器数据库实例。启用二进制日志复制的自定义数据库集群参数组要等到写入器数据库实例重启后才会生效。
-
在确认跨区域复制已重新启动且辅助 AWS 区域的副本延迟为 0 之前,请勿恢复写入工作负载或启用与写入器数据库实例的连接。