升级 Aurora MySQL 数据库集群的次要版本或补丁程序级别
可以使用以下方法升级数据库集群的次要版本或修补数据库集群:
-
通过修改引擎版本升级 Aurora MySQL(适用于 Aurora MySQL 版本 2 和 3)
有关零停机时间修补如何减少升级过程中的中断的信息,请参阅使用零停机时间修补。
通过修改引擎版本升级 Aurora MySQL
升级 Aurora MySQL 集群的次要版本会将其他修复和新功能应用于现有集群。
这种升级适用于原始版本和升级的版本均在 Aurora MySQL 2.x 系列中的 Aurora MySQL 集群。这个过程快速而直接,因为它不涉及 Aurora MySQL 元数据的任何转换或表数据的重组。
您可以通过使用 Amazon Web Services Management Console、Amazon CLI 或 RDS API 修改数据库集群的引擎版本来执行这种升级。如果您的集群正在运行 Aurora MySQL 2.x,请选择更高的 2.x 版本。
如果要对 Aurora Global Database 执行次要升级,请先升级所有辅助集群,然后再升级主集群。
注意
要执行到 Aurora MySQL 3.03.* 版本的次要版本升级,请使用以下过程:
从全局集群中删除所有辅助区域。按 从 Amazon Aurora Global Database 删除集群 中的步骤操作。
将主区域的引擎版本升级到 3.03.*。按 To modify the engine version of a DB cluster 中的步骤操作。
向全局集群添加辅助区域。按 将 Amazon Web Services 区域 添加到 Amazon Aurora Global Database 中的步骤操作。
-
通过使用控制台 – 修改集群的属性。在 Modify DB cluster (修改数据库集群) 窗口中,更改 DB engine version (数据库引擎版本) 框中的 Aurora MySQL 引擎版本。如果您不熟悉修改集群的一般过程,请按照使用控制台、CLI 和 API 修改数据库集群中的说明操作。
-
通过使用 Amazon CLI – 调用 modify-db-cluster Amazon CLI 命令,为
--db-cluster-identifier
选项指定数据库集群的名称,并为--engine-version
选项指定引擎版本。例如,要升级到 Aurora MySQL 版本 2.11.1,请将
--engine-version
选项设置为5.7.mysql_aurora.2.11.1
。指定--apply-immediately
选项可立即更新数据库集群的引擎版本。 -
通过使用 RDS API – 调用 ModifyDBCluster API 操作,为
DBClusterIdentifier
参数指定数据库集群的名称,并为EngineVersion
参数指定引擎版本。将ApplyImmediately
参数设置为true
可立即更新数据库集群的引擎版本。
启用 Aurora MySQL 次要版本之间的自动升级
对于 Amazon Aurora MySQL 数据库集群,您可以指定 Aurora 自动将数据库集群升级到新的次要版本。为此,您可以通过 Amazon Web Services Management Console、Amazon CLI 或 RDS API 使用数据库集群的自动次要版本升级属性。
自动升级会在数据库的维护时段进行。
自动次要版本升级不适用于以下类型的 Aurora MySQL 集群:
-
多主集群。
-
属于 Aurora 全局数据库的集群。
-
具有跨区域副本的集群。
中断持续时间取决于工作负载、集群大小、二进制日志数据量以及 Aurora 是否可以使用零停机时间修补(ZDP)功能。Aurora 会重新启动数据库集群,因此您可能会在恢复使用集群之前经历短暂的不可用时间。特别是,二进制日志数据量会影响恢复时间。数据库实例在恢复期间处理二进制日志数据。因此,大量的二进制日志数据会增加恢复时间。
为 Aurora MySQL 数据库集群启用自动次要版本升级
-
按照一般过程修改集群中的数据库实例,如修改数据库集群中的数据库实例中所述。对集群中的每个数据库实例重复此过程。
-
执行以下操作为集群启用自动次要版本升级:
-
通过使用控制台 – 完成以下步骤:
-
登录 Amazon RDS 控制台,选择 Databases(数据库),查找您希望打开或关闭自动次要版本升级的数据库集群。
-
选择要修改的数据库集群中的每个数据库实例。按顺序对每个数据库实例应用以下更改:
-
选择 Modify (修改)。
-
选择启用自动次要版本升级设置。此设置是维护部分的一部分。
-
选择继续,查看修改摘要。
-
(可选)选择立即应用以立即应用更改。
-
在确认页面上,选择修改数据库实例。
-
-
-
通过使用 Amazon CLI – 调用 modify-db-instance Amazon CLI 命令。为
--db-instance-identifier
选项指定数据库实例的名称,为true
选项指定--auto-minor-version-upgrade
。(可选)指定--apply-immediately
选项,立即为数据库实例启用此设置。为集群中的每个数据库实例运行单独的modify-db-instance
命令。 -
通过使用 RDS API – 调用 ModifyDBInstance API 操作,并为
DBInstanceIdentifier
参数指定数据库集群的名称,为true
参数指定AutoMinorVersionUpgrade
。(可选)将ApplyImmediately
参数设置为true
,立即为数据库实例启用此设置。为集群中的每个数据库实例调用单独的ModifyDBInstance
操作。
您可以使用如下 CLI 命令来检查 Aurora MySQL 集群中所有数据库实例的启用自动次要版本升级状态。
aws rds describe-db-instances \ --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
该命令产生的输出类似于以下内容:
[ { "DBInstanceIdentifier": "db-t2-medium-instance", "DBClusterIdentifier": "cluster-57-2020-06-03-6411", "AutoMinorVersionUpgrade": true }, { "DBInstanceIdentifier": "db-t2-small-original-size", "DBClusterIdentifier": "cluster-57-2020-06-03-6411", "AutoMinorVersionUpgrade": false }, { "DBInstanceIdentifier": "instance-2020-05-01-2332", "DBClusterIdentifier": "cluster-57-2020-05-01-4615", "AutoMinorVersionUpgrade": true }, ... output omitted ...
使用零停机时间修补
对 Aurora MySQL 数据库集群执行升级时可能会在数据库关闭和升级期间发生中断。默认情况下,如果在数据库运行时开始升级,则会丢失数据库集群正在处理的所有连接和事务。如果等到数据库处于空闲状态再执行升级,则可能需要等待很长时间。
零停机时间修补 (ZDP) 功能尝试在 Aurora MySQL 升级期间尽力保留客户端连接。如果 ZDP 成功完成,则应用程序会话将保留,并且数据库引擎将在升级过程中重新启动。数据库引擎重新启动可能会导致吞吐量下降,持续时间从几秒钟到大约一分钟不等。
下表显示提供了 ZDP 的 Aurora MySQL 版本和数据库实例类。
版本 | db.r* 实例类 | db.t* 实例类 | db.serverless 实例类 |
---|---|---|---|
2.07.2 和更高的 2.07 版本 | 否 | 是 | 不适用 |
2.10.0 和更高的 2.10 版本 | 是 | 是 | 不适用 |
2.11.0 和更高的 2.11 版本 | 是 | 是 | 不适用 |
3.01.0 和 3.01.1 | 是 | 是 | 不适用 |
3.02.0 和更高的 3.x 版本 | 是 | 是 | 是 |
注意
建议仅将 T 数据库实例类用于开发和测试服务器,或其他非生产服务器。有关 T 实例类的更多详细信息,请参阅使用 T 实例类进行开发和测试。
您可以在 MySQL 错误日志中查看 ZDP 期间重要属性的指标。您还可以在 Amazon Web Services Management Console 中的 Events(事件)页面上查看有关 Aurora MySQL 何时使用 ZDP、何时选择不使用 ZDP 的信息。
在 Aurora MySQL 2.10 和更高版本以及版本 3 中,Aurora 可以在启用二进制日志复制的情况下,执行零停机时间修补。在 ZDP 操作期间,Aurora MySQL 将自动断开与二进制日志目标的连接。Aurora MySQL 会自动重新连接到二进制日志目标,并在重启完成后恢复复制。
ZDP 还与 Aurora MySQL 2.10 及更高版本中的重启增强功能结合使用。修补写入器数据库实例会同时自动修补读取器。执行修补后,Aurora 将恢复写入器和读取器数据库实例上的连接。低于 Aurora MySQL 2.10 的版本,ZDP 仅适用于集群的写入器数据库实例。
在以下条件下,ZDP 可能无法成功完成:
-
正在执行长时间运行的查询或事务。如果 Aurora 在此情况下可以执行 ZDP,将取消所有开放事务。
-
存在开放式安全套接字层 (SSL) 连接。
-
正在使用临时表或表锁定,例如,在执行数据定义语言 (DDL) 语句期间。如果 Aurora 在此情况下可以执行 ZDP,将取消所有开放事务。
-
存在待处理的参数更改。
如果因以下一个或多个条件导致没有适合执行 ZDP 的时间范围,则修补将恢复为标准行为。
尽管成功执行 ZDP 操作后连接保持不变,但一些变量和功能会重新初始化。零停机修补重启后,以下类型的信息将不会保留:
-
全局变量。Aurora 将恢复会话变量,但重启后不会恢复全局变量。
-
状态变量。特别是,引擎状态报告的正常运行时间值会在使用 ZDR 或 ZDP 机制重启后重置。
-
LAST_INSERT_ID
. -
表的内存中
auto_increment
状态。重新初始化内存中的自动增量状态。有关自动增量值的更多信息,请参阅 MySQL 参考手册。 -
来自
INFORMATION_SCHEMA
和PERFORMANCE_SCHEMA
表的诊断信息。这些诊断信息也会显示在SHOW PROFILE
和SHOW PROFILES
等命令的输出中。
Events (事件) 页面上报告了以下与零停机时间重启相关的活动:
-
尝试在零停机的情况下升级数据库。
-
尝试在零停机的情况下升级数据库已完成。事件会报告该过程花费的时间。事件还会报告在重启期间保留的连接数量以及断开的连接数量。您可以查看数据库错误日志,了解有关重启期间所发生情况的更多详细信息。
下表总结了 ZDP 如何从特定 Aurora MySQL 1.x 和 2.x 版本升级以及如何升级到这些特定版本。数据库实例的实例类还会影响 Aurora 是否使用 ZDP 机制。
原始版本 | 升级的版本 | ZDP 适用吗? |
---|---|---|
Aurora MySQL 1。* |
任何 |
否 |
Aurora MySQL 2.*,低于 2.07.2 版本 |
任何 |
否 |
Aurora MySQL 2.07.2、2.07.3 |
2.07.4 和更高的 2.07 版本、2.10.* |
是,仅在 T2 和 T3 实例类的写入器实例上。Aurora 只会在超时发生前发现安静点的情况下执行 ZDP。超时后,Aurora 将执行定期重启。 |
Aurora MySQL 2.07.4 和更高的 2.07 版本 |
2.10.* |
是,仅在 T2 和 T3 实例的写入器实例上。Aurora 会回滚处于活动和空闲状态下的事务。使用 SSL、临时表、表锁或用户锁的连接将被断开。如果在 ZDP 完成后引擎的启动时间过长,Aurora 可能会重新启动引擎并断开所有连接。 |
Aurora MySQL 2.10。* |
2.10.* |
是,在 |
备选的蓝绿升级技术
在某些情况下,您的首要任务是立即从旧集群切换到升级后的集群。在此类情况下,您可以使用多步骤流程,并排运行新旧集群。此处,您可以将数据从旧集群复制到新集群,直到您准备好接管新集群。有关详细信息,请参阅使用 Amazon RDS 蓝绿部署进行数据库更新。