Azure Database for MySQL 灵活服务器中的主版本升级

适用于： Azure Database for MySQL - 灵活服务器

本文介绍如何就地升级 Azure Database for MySQL 灵活服务器中的 MySQL 主版本。 利用此功能，客户可以将 MySQL 5.7 服务器就地升级到 MySQL 8.0，无需移动任何数据，也无需更改应用程序连接字符串。

先决条件

• 应该先升级 MySQL 版本 5.7 中的只读副本，然后再升级主服务器，使不同 MySQL 版本之间的复制保持兼容，请阅读有关 MySQL 版本之间的复制兼容性的详细信息。
• 在升级生产服务器之前，在 Azure 门户中使用内置验证功能现在更加简单高效。 此工具预先检查数据库架构与 MySQL 8.0 的兼容性，突出显示了潜在问题。 虽然我们提供了此便捷选项，但我们也强烈建议使用官方的 Oracle MySQL 升级检查器工具来测试数据库架构兼容性，并执行必要的回归测试，以验证应用程序与新 MySQL 版本中已移除/弃用的功能的兼容性。

  注意

  使用 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 功能。 这些警告不会影响数据库的功能。

• 在生产服务器上执行主版本升级之前，触发按需备份，该版本可用于从执行的完整按需备份回滚到版本 5.7。
• 在继续升级主要版本之前，请确保数据库中没有活动或挂起的 XA 事务，因为正在进行的 XA 事务可能会导致升级过程失败。 若要避免此问题，请首先通过运行 XA RECOVER; 来检查“准备”状态的任何 XA 事务。 对于标识的任何事务，请使用 XA ROLLBACK '{xid}' 回滚每个事务，将 {xid} 替换为事务 ID。 在启动升级之前，请确保提交或回滚所有 XA 事务，以保持事务一致性并降低升级失败的风险。

使用适用于可突发 SKU 服务器的 Azure 门户执行从 MySQL 5.7 到 MySQL 8.0 的计划主要版本升级

为 Azure Database for MySQL 可突发 SKU 计算层执行主版本升级需要专用工作流。 这是因为主要版本升级需要大量资源，需要大量的 CPU 和内存。 基于信用的突发 SKU 实例可能会难以满足这些要求，从而可能导致升级过程失败。 因此，升级可突发 SKU 时，系统首先将计算层升级到常规用途 SKU，以确保有足够的资源可用于升级。

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

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

   重要

   建议首先在还原后的服务器副本上执行升级，而不是直接升级生产服务器。 请参阅如何执行时间点还原。

2. 在“概述”页上的工具栏中，选择“升级”。

   重要

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

   

3. 架构兼容性验证

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

4. 升级前决策

   在继续升级之前，需要选择要升级到的计算层来执行主要版本升级。 默认情况下，系统将从可突发 SKU 升级到最基本的常规用途 SKU，但可以按需选择升级到更高的计算层。

   注意

   在升级期间，服务器在“常规用途”层中运行时，仅需为在此期间实际使用的“常规用途”资源付费。

5. 升级后决策

   确定是保留常规用途 SKU 还是在升级后还原为可突发 SKU。 系统会在初始升级步骤中提示此选择。

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

6. 主版本升级

   升级计算层后，系统将启动主要版本升级过程。 通过 Azure 门户监视升级进度。 升级过程可能需要一些时间，具体取决于数据库的大小和活动。

   注意

   如果主要版本升级失败，计算层将不会自动还原到以前的可突发 SKU。 这是为了让客户能够继续执行主要版本升级，而无需再次执行计算层升级。

7. 自动还原

   根据升级前的决定，系统将保留常规用途 SKU 或在升级完成后自动还原为突发 SKU。

   注意

   如果选择自动还原为可突发 SKU，则系统默认将还原为 B2S SKU。

使用适用于常规用途和业务关键 SKU 服务器的 Azure 门户执行从 MySQL 5.7 到 MySQL 8.0 的计划主要版本升级

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

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

   重要

   建议首先在还原后的服务器副本上执行升级，而不是直接升级生产服务器。 请参阅如何执行时间点还原。

2. 在“概述”页上的工具栏中，选择“升级”。

   重要

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

   

3. 执行升级前验证

   在继续升级之前，请点击“验证”按钮，检查服务器与 MySQL 8.0 的兼容性。

   

   重要

   使用“验证”功能检查数据库架构与 MySQL 8.0 的兼容性时，请注意，它涉及锁定表以准确评估整个架构。 此过程可能会导致查询超时。 因此，建议不要在高峰营业时间或数据库遇到高流量时执行验证。 为验证选择低活动期有助于最大程度地减少对操作的影响。

4. 在“升级”边栏中的“要升级的 MySQL 版本”文本框中，确认要升级到的 MySQL 主版本，即 8.0。

   

   在升级主服务器之前，首先需要升级所有关联的只读副本服务器。 在完成此操作之前，将禁用“升级”。

5. 在主服务器上，选择确认消息以确认是否已升级所有副本服务器，然后选择“升级”。

   

   在只读副本和独立服务器上，默认已启用“升级”。

使用 Azure CLI 执行从 MySQL 5.7 到 MySQL 8.0 的主版本升级计划

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

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

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

2. 登录后，运行 az mysql server upgrade 命令。

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

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

使用 Azure 门户在只读副本服务器上执行从 MySQL 5.7 到 MySQL 8.0 的主版本升级

若要通过 Azure 门户在只读副本上执行从 Azure Database for MySQL 灵活服务器 5.7 服务器到 MySQL 8.0 的主版本升级，请执行以下步骤。

1. 在 Azure 门户中，选择现有的 Azure Database for MySQL 灵活服务器 5.7 只读副本服务器。

2. 在“概述”页上的工具栏中，选择“升级”。

3. 在“升级”部分，选择“升级”以将 Azure Database for MySQL 灵活服务器 5.7 只读副本服务器升级到 MySQL 8.0。

   此时会显示一条通知，确认升级成功。

4. 在“概述”页上，确认 Azure Database for MySQL 灵活服务器只读副本服务器是否正在运行版本 8.0。

5. 现在转到你的主服务器，并在其上执行主版本升级。

使用只读副本执行从 MySQL 5.7 到 MySQL 8.0 的停机时间最短的主版本升级

若要使用只读副本服务器执行从 Azure Database for MySQL 灵活服务器 5.7 服务器到 MySQL 8.0 的停机时间最短的主版本升级，请执行以下步骤。

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

2. 从主服务器创建只读副本。

3. 将只读副本升级到版本 8.0。

4. 确认副本服务器在运行版本 8.0 运行后，断开应用程序与主服务器之间的连接。

5. 检查复制状态，确保副本服务器与主服务器完全同步，从而让所有数据都处于同步状态，并确保主服务器中没有执行任何新的操作。

6. 在副本服务器上使用 show replica status 命令查看复制状态，以进行确认。

    SHOW SLAVE STATUS\G
   

   如果 Slave_IO_Running 和 Slave_SQL_Running 的状态为“yes”，Seconds_Behind_Master 的值为“0”，则表示复制工作正常。 Seconds_Behind_Master 指示副本的滞后程度。 如果值不是 0，则表示副本仍在处理更新。 确认 Seconds_Behind_Master 的值为 **** 后，可以放心停止复制。

7. 通过停止复制，可将只读副本提升为主服务器。

8. 将服务器参数 read_only 设置为 0（关闭），以开始在提升的主服务器上进行写入。

9. 将应用程序指向运行服务器 8.0 的新主服务器（以前为副本服务器）。 每个服务器都有唯一的连接字符串。 更新应用程序，使之指向（以前的）副本而不是源。

常见问题

• 这是否会导致服务器停机？如果会，会停机多长时间？

  若要在升级期间缩短停机时间，请按照《使用只读副本执行从 MySQL 5.7 到 MySQL 8.0 的最短停机时间的主版本升级》中提及的步骤操作。 服务器在升级过程中将不可用，因此，我们建议你在计划内维护时段执行此操作。 估计的停机时间取决于数据库大小、预配的存储大小（预配的 IOPS）以及数据库中的表的数量。 升级时间与服务器上的表数量直接成正比。 为了估计服务器环境的停机时间，建议你首先在还原后的服务器副本上执行升级。

• 升级后我的备份会发生什么情况？

  在主版本升级之前创建的用于还原的所有备份（自动/按需备份）将始终还原到使用旧版本 (5.7) 的服务器。 在主版本升级之后创建的所有备份（自动/按需备份）将还原到使用升级后版本 (8.0) 的服务器。 强烈建议在执行主版本升级之前创建按需备份，以便于回滚。

• 我当前使用的是可突发 SKU，Azure 是否计划将来支持此 SKU 的主版本升级？

  由于此 SKU 的性能限制，可突发 SKU 无法支持主版本升级。

  如果需要在 Azure Database for MySQL 灵活服务器实例上执行主版本升级，并且当前正在使用可突发 SKU，一个临时解决方案是升级到常规用途或业务关键 SKU，执行升级，然后切换回可突发 SKU。

  请注意，升级到更高的 SKU 可能涉及定价更改，并可能导致部署成本增加。 但是，由于升级过程预计不需要很长时间，因此增加的成本应该不大。

后续步骤

• 详细了解如何为 Azure Database for MySQL 灵活服务器实例配置计划性维护。
• 了解 MySQL 版本 8.0 中的新增功能。