Azure Database for MySQL 中的重大版本升级

2025-09-12

注意

本文包含对术语“从属”的引用，这是 Microsoft 不再使用的术语。在从软件中删除该术语后，我们会将其从本文中删除。

本文介绍如何在 Azure Database for MySQL 灵活服务器中升级 MySQL 主版本。此功能使客户能够执行主要版本升级（例如，从 MySQL 5.7 升级到 8.0 或 8.0 到 8.4），而无需移动数据或更改应用程序连接字符串。

重要

停机持续时间根据数据库实例的大小及其包含的表数而不同。
通过 Rest API 或 SDK 为 Azure Database for MySQL 灵活服务器启动主版本升级时，请避免在同一请求中修改其他服务属性。不允许同时进行的更改，可能会导致意外的结果或请求失败。完成升级后，在单独的作中执行属性修改。
某些工作负荷在主版本升级后可能不会表现出增强的性能。建议先创建副本服务器（作为测试服务器），然后将其提升到独立服务器，然后在测试服务器上运行工作负荷，然后再在生产环境中实现升级，从而评估工作负荷的性能。
升级 MySQL 主版本是不可逆的操作。如果验证确定服务器配置了目标版本中已删除或弃用的任何功能，则部署可能会失败。可以在服务器上进行必要的配置更改，然后重试升级。

先决条件

在主服务器进行复制之前，应升级具有较旧 MySQL 版本的只读副本，以便在不同的 MySQL 版本之间兼容。详细了解 MySQL 版本之间的复制兼容性。
在升级生产服务器之前，在 Azure 门户中使用内置验证功能现在更加简单高效。此工具会预检查数据库架构与目标 MySQL 版本的兼容性，并突出显示潜在问题。虽然我们提供了这个方便的选项，但我们 强烈建议 使用官方 Oracle MySQL 升级检查器工具来测试数据库架构兼容性，并执行必要的回归测试，以验证应用程序与新 MySQL 版本中弃/用的功能的兼容性。
在生产服务器上执行主版本升级之前触发按需备份。在升级之前进行的备份可用于从完整按需备份回滚到以前的版本。
在继续升级主要版本之前，请确保数据库中没有活动或挂起的 XA 事务，因为正在进行的 XA 事务可能会导致升级过程失败。首先，若要避免此问题，请通过运行 XA RECOVER;来检查处于“已准备”状态的任何 XA 事务。对于标识的任何事务，请使用 XA ROLLBACK '{xid}';回滚每个事务，将 {xid} 替换为事务 ID。在启动升级之前，请确保提交或回滚所有 XA 事务，以保持事务一致性并降低升级失败的风险。

注意

使用 Oracle 的官方工具检查架构兼容性时，可能会遇到一些警告，指出存储过程中的意外令牌，例如：

mysql.az_replication_change_master - at line 3,4255: unexpected token 'REPLICATION'

mysql.az_add_action_history - PROCEDURE uses obsolete NO_AUTO_CREATE_USER sql_mode

可以安全地忽略这些警告。它们引用了前缀为 mysql.前缀的内置存储过程，这些存储过程用于支持 Azure MySQL 功能。这些警告不会影响数据库的功能。

使用 Azure 门户对可突发 SKU 服务器执行计划的主版本升级

为 Azure Database for MySQL 的可突发 SKU 计算层执行主要版本升级需要一个专门的工作流程。主要版本升级是资源密集型的，需要大量的 CPU 和内存。可突发 SKU 实例（基于信用）可能会在这些要求下苦苦挣扎，这可能会导致升级过程失败。因此，升级可突发 SKU 时，系统首先将计算层升级到 General-Purpose SKU，以确保有足够的资源可用于升级。

若要使用 Azure 门户为 Azure Database for MySQL 可突发型 SKU 计算层执行主要版本升级，请执行以下步骤：

在 Azure 门户中，选择现有的 Azure Database for MySQL 灵活服务器实例。

重要

建议先在还原的服务器副本上执行升级，而不是直接升级生产。请参阅如何执行时间点还原。
在“概述”页上的工具栏中，选择“升级”。

重要

在升级之前，请访问链接，获取目标 MySQL 版本中删除的功能列表。使用 Azure 门户上的“服务器参数”边栏选项卡验证弃用 sql_mode 值，并从当前 Azure Database for MySQL 灵活服务器中删除/取消选择这些值，以避免部署失败。 MySQL 8.0 及更高版本中不再支持具有值NO_AUTO_CREATE_USER、NO_FIELD_OPTIONS、NO_KEY_OPTIONS和NO_TABLE_OPTIONS的sql_mode。
架构兼容性验证

在继续升级之前，请运行 Oracle 的官方 MySQL 升级检查器工具，以验证当前数据库架构是否与目标 MySQL 版本兼容。此步骤对于确保顺利升级过程至关重要。
升级前决策

在升级之前，必须选择要升级的计算层以执行主版本升级。默认情况下，系统从可突发 SKU 升级到最基本的常规用途 SKU，但如果需要，可以升级到更高的计算层。请注意，在升级期间，服务器在“常规用途”层中运行时，只会为此期间使用的实际“常规用途”资源付费。
升级后决策

升级后，决定是保留常规用途 SKU 还是还原到可突发 SKU。在初始升级步骤中会提示此选项。

系统会自动将计算层从可突发 SKU 升级到所选的常规用途 SKU 以支持主版本升级。
主要版本升级

升级计算层后，系统会启动主版本升级过程。通过 Azure 门户监视升级进度。升级过程可能需要一些时间，具体取决于数据库的大小和活动。请注意，如果主版本升级失败，计算层不会自动还原到以前的可突发 SKU。这样，客户就可以继续主版本升级，而无需再次执行计算层升级。
自动还原

根据预升级决策，系统会保留常规用途 SKU，或者在升级后自动还原为可突发 SKU。如果自动还原为可突发 SKU，则系统默认还原为 B2S SKU。

使用 Azure 门户对常规用途和业务关键型 SKU 服务器执行计划的主版本升级

若要使用 Azure 门户执行 Azure Database for MySQL 灵活服务器的主版本升级，请执行以下步骤。

在 Azure 门户中，选择现有的 Azure Database for MySQL 灵活服务器实例。

重要

建议先在还原的服务器副本上执行升级，而不是直接升级生产。请参阅如何执行时间点还原。
在“概述”页上的工具栏中，选择“升级”。

重要

在升级之前，请访问链接，获取目标 MySQL 版本中删除的功能列表。使用 Azure 门户上的“服务器参数”边栏选项卡验证弃用 sql_mode 值，并从当前 Azure Database for MySQL 灵活服务器中删除/取消选择这些值，以避免部署失败。 MySQL 8.0 及更高版本中不再支持具有值NO_AUTO_CREATE_USER、NO_FIELD_OPTIONS、NO_KEY_OPTIONS和NO_TABLE_OPTIONS的sql_mode。
执行升级前验证

在继续升级之前，请选择“ 验证 ”按钮，检查服务器与目标 MySQL 版本的兼容性。
注意

使用“验证”功能评估数据库架构是否与目标 MySQL 版本兼容时，请注意以下注意事项：
- 验证期间表锁定：验证过程涉及锁定表来准确检查整个架构。如果数据库负载过大，这可能会导致查询超时。
建议：避免在高峰时段或数据库处理高流量时运行验证。相反，在低活动期间计划验证，以减少对作的影响。
- 由于结果集较大而可能挂起：在某些实例中，尤其是包含许多对象的复杂数据库，验证结果可能变得太大，无法处理或显示在联机工作流中。这可能会导致“验证”操作看起来像是挂起或无限期地进行。
建议：如果遇到此问题，我们建议使用 Oracle 的官方客户端升级检查器工具（例如 MySQL Shell 中包含的工具）在本地执行验证。此方法可避免平台端结果大小限制，并提供更详细的可靠验证输出。
- 联机验证的建议用例：联机“验证”功能专为简单或中等复杂的架构而设计。对于大规模生产环境（例如具有数千个表、视图、例程或其他架构对象的环境），我们强烈建议使用 Oracle 的客户端升级检查器工具来执行兼容性检查。这可确保全面分析完整的架构，并避免与结果大小或验证超时相关的潜在问题。
在 “升级 ”边栏的 “MySQL 版本以升级 ”文本框中，验证要升级到的主要 MySQL 版本（例如 8.0 或 8.4）。

必须先升级任何关联的只读副本服务器，然后才能升级主服务器。在完成此作之前，将禁用升级。
在主服务器上，选择确认消息以确认是否已升级所有副本服务器，然后选择“升级”。

默认情况下，在只读副本和独立服务器上启用升级。

使用 Azure CLI 执行计划的主版本升级

若要使用 Azure CLI 执行 Azure Database for MySQL 灵活服务器的主版本升级，请执行以下步骤。

安装适用于 Windows 的 Azure CLI 以运行升级命令。

此升级需要 Azure CLI 2.40.0 或更高版本。运行 az version 以查找安装的版本和依赖库。若要升级到最新版本，请运行 az upgrade。

登录后，运行 az MySQL server upgrade 命令。

az mysql flexible-server upgrade --name {your mysql server name} --resource-group {your resource group} --subscription {your subscription id} --version {target major version}

替换为 {target major version} 要升级到的版本（例如 8 或 8.4）。

在确认提示下，键入“y”以确认或键入“n”以停止升级过程，然后按 Enter。

使用 Azure 门户在只读副本服务器上执行主版本升级

若要使用 Azure 门户执行 Azure Database for MySQL 灵活服务器只读副本服务器的主版本升级，请执行以下步骤。

选择现有的 Azure Database for MySQL 灵活服务器，并在 Azure 门户中读取副本服务器。
在“概述”页上的工具栏中，选择“升级”。

重要

在升级之前，请访问链接，获取目标 MySQL 版本中删除的功能列表。使用 Azure 门户上的“服务器参数”边栏选项卡验证弃用 sql_mode 值，并从当前 Azure Database for MySQL 灵活服务器中删除/取消选择这些值，以避免部署失败。
在“ 升级 ”部分中，选择“ 升级 ”将 Azure Database for MySQL 灵活服务器只读副本服务器升级到目标主版本。此时会显示一条通知，确认升级成功。
在 “概述 ”页上，确认 Azure Database for MySQL 灵活服务器只读副本服务器正在运行目标版本。
转到主服务器并执行主版本升级。

使用只读副本执行最短停机时间主版本升级

若要使用只读副本服务器执行 Azure Database for MySQL 灵活服务器的主版本升级，请执行以下步骤。

在 Azure 门户中选择现有的 Azure Database for MySQL 灵活服务器实例。
从主服务器创建只读副本。
将只读副本升级到目标主版本。
确认副本服务器正在运行目标版本后，请停止应用程序连接到主服务器。
检查复制状态以确保副本已赶上主副本，因此所有数据处于同步状态，并且不会对主数据库执行任何新作。
在副本服务器上使用 show replica status 命令查看复制状态，以进行确认。
```
SHOW SLAVE STATUS\G
```
如果Slave_IO_Running状态和Slave_SQL_Running是，并且Seconds_Behind_Master的值为 0，则复制效果良好。 Seconds_Behind_Master 指示副本的滞后程度。如果值不是 0，则表示副本仍在处理更新。确认Seconds_Behind_Master值为 0 后，可以安全地停止复制。
通过停止复制，将只读副本提升为主服务器。
将服务器参数read_only设置为 0 （OFF），开始在升级的主服务器上写入。
将应用程序指向运行目标版本的新主副本（前副本）。每个服务器都有唯一的连接字符串。更新应用程序，使之指向（以前的）副本而不是源。

注意

此方案只会在执行步骤 4 到 7 期间导致停机。