本文包含对术语“从属”的引用,这是 Microsoft 不再使用的术语。 从软件中删除该术语后,我们会将其从本文中删除。
本文介绍如何就地升级 Azure Database for MySQL - 灵活服务器中的 MySQL 主版本。
利用此功能,客户可以将 MySQL 5.7 服务器就地升级到 MySQL 8.0,无需移动任何数据,也无需更改应用程序连接字符串。
Azure Database for MySQL - 灵活服务器的主版本升级目前以公共预览版提供。
目前无法对基于可突发 SKU 的 5.7 版服务器进行主版本升级。
停机持续时间根据数据库实例的大小及其包含的表数而不同。
升级 MySQL 主版本是不可逆的操作。 如果验证过程确定服务器上配置了任何
已删除
或
已弃用
的功能,则部署可能会失败。 可以在服务器上进行所需的配置更改,然后再次尝试升级。
应该先升级 MySQL 版本 5.7 中的只读副本,然后再升级主服务器,使不同 MySQL 版本之间的复制保持兼容,请阅读有关
MySQL 版本之间的复制兼容性
的详细信息。
在升级生产服务器之前,
强烈建议
使用官方的 Oracle
MySQL 升级检查器工具
来测试数据库架构兼容性,并执行必要的回归测试,以验证应用程序与新 MySQL 版本中已
移除
/
弃用
的功能的兼容性。
在生产服务器上执行主版本升级之前触发
按需备份
,这样就可以从创建的完整按需备份
回滚到版本 5.7
。
若要使用 Azure 门户执行 Azure Database for MySQL 5.7 服务器的主版本升级,请执行以下步骤。
在
Azure 门户
中,选择你的现有 Azure Database for MySQL 5.7 服务器。
建议首先在还原后的服务器副本上执行升级,而不是直接升级生产服务器。 请参阅
如何执行时间点还原
。
在“概述”页上的工具栏中,选择“升级”。
在升级之前,请访问 MySQL 8.0 中
已删除的功能
列表的链接。
使用 Azure 门户上的“服务器参数”边栏选项卡验证已弃用的
sql_mode
值并从当前的灵活服务器 5.7 中删除/取消选择这些值,以避免部署失败。
MySQL 8.0 不再支持值为 NO_AUTO_CREATE_USER、NO_FIELD_OPTIONS、NO_KEY_OPTIONS 和 NO_TABLE_OPTIONS 的
sql_mode
。
若要使用 Azure CLI 执行 Azure Database for MySQL 5.7 服务器的主版本升级,请执行以下步骤。
安装适用于 Windows 的
Azure CLI
,或在 Azure Cloud Shell 中使用
Azure CLI
运行升级命令。
此升级需要 2.40.0 或更高版本的 Azure CLI。 如果你使用的是 Azure Cloud Shell,则表示已安装最新版本。 运行 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 8
在确认提示下,键入“y”以确认或键入“n”以停止升级过程,然后按 Enter。
若要使用 Azure 门户在只读副本上执行从 Azure Database for MySQL 5.7 服务器到 MySQL 8.0 的主版本升级,请执行以下步骤。
在 Azure 门户中,选择你的现有 Azure Database for MySQL 5.7 只读副本服务器。
在“概述”页上的工具栏中,选择“升级”。
在升级之前,请访问 MySQL 8.0 中已删除的功能列表的链接。
使用 Azure 门户上的“服务器参数”边栏选项卡验证已弃用的 sql_mode 值并从当前的灵活服务器 5.7 中删除/取消选择这些值,以避免部署失败。
在“升级”部分,选择“升级”可将 Azure Database for MySQL 5.7 只读副本服务器升级到 MySQL 8.0。
此时会显示一条通知,确认升级成功。
在“概述”页中,确认 Azure Database for MySQL 只读副本服务器版本为 8.0。
现在转到你的主服务器,并在其上执行主版本升级。
若要使用只读副本服务器执行从 Azure Database for MySQL 5.7 服务器到 MySQL 8.0 的停机时间最短的主版本升级,请执行以下步骤。
在 Azure 门户中,选择你的现有 Azure Database for MySQL 5.7。
从主服务器创建只读副本。
将只读副本升级到版本 8.0。
确认副本服务器在运行版本 8.0 运行后,断开应用程序与主服务器之间的连接。
检查复制状态,确保副本服务器与主服务器完全同步,从而让所有数据都处于同步状态,并确保主服务器中没有执行任何新的操作。
在副本服务器上使用 show slave status 命令查看复制状态,以进行确认。
SHOW SLAVE STATUS\G
如果 Slave_IO_Running 和 Slave_SQL_Running 的状态为“yes”,Seconds_Behind_Master 的值为“0”,则表示复制工作正常。 Seconds_Behind_Master 指示副本的滞后程度。 如果值不是 0,则表示副本仍在处理更新。 确认 Seconds_Behind_Master 的值为 **** 后,可以放心停止复制。
通过停止复制,可将只读副本提升为主服务器。
将服务器参数 read_only 设置为 0(关闭),以开始在提升的主服务器上进行写入。
将应用程序指向运行服务器 8.0 的新主服务器(以前为副本服务器)。 每个服务器都有唯一的连接字符串。 更新应用程序,使之指向(以前的)副本而不是源。
此方案只会在执行步骤 4 到 7 期间导致停机。
这是否会导致服务器停机?如果会,会停机多长时间?
若要在升级期间最大程度地减少停机时间,请按照使用只读副本执行从 MySQL 5.7 到 MySQL 8.0 的停机时间最短的主版本升级中所述的步骤操作。
服务器在升级过程中将不可用,因此,我们建议你在计划内维护时段执行此操作。 估计的停机时间取决于数据库大小、预配的存储大小(预配的 IOPS)以及数据库中的表的数量。 升级时间与服务器上的表数量直接成正比。 为了估计服务器环境的停机时间,建议你首先在还原后的服务器副本上执行升级。
升级后我的备份会发生什么情况?
在主版本升级之前创建的用于还原的所有备份(自动/按需备份)将始终还原到使用旧版本 (5.7) 的服务器。
在主版本升级之后创建的所有备份(自动/按需备份)将还原到使用升级后版本 (8.0) 的服务器。 强烈建议在执行主版本升级之前创建按需备份,以便于回滚。
我当前使用的是可突发 SKU,Microsoft 是否计划将来支持此 SKU 的主版本升级?
由于可突发 SKU 的性能限制,它无法支持主版本升级。Microsoft 仍在研究使此 SKU 可用于主版本升级的方法
如果需要在 Azure MySQL 灵活服务器上执行主版本升级,并且当前使用的是可突发 SKU,一种临时解决方案是升级到常规用途或业务关键 SKU,执行升级,然后切换回可突发 SKU。
请注意,升级到更高的 SKU 可能涉及定价更改,并可能导致部署成本增加。 但是,由于升级过程预计不会花费很长时间,因此额外的成本应该不会很高。
详细了解如何为 Azure Database for MySQL - 灵活服务器配置计划性维护。
了解 MySQL 版本 8.0 中的新增功能。