适用于:
Azure Database for MySQL - 灵活服务器
MySQL 是一种常用的数据库引擎,用于运行 Internet 规模的 Web 和移动应用程序。 许多客户将其用于在线教育服务、视频流式处理服务、数字支付解决方案、电子商务平台、游戏服务、新闻门户、政府和医疗保健网站。 这些服务需要随着 Web 或移动应用程序流量的增加而服务和扩展。
在应用程序端,应用程序通常是用 Java 或 PHP 开发的,并迁移到在 Azure 虚拟机规模集或 Azure 应用服务上运行,或者进行容器化以在 Azure Kubernetes 服务 (AKS) 上运行。 使用虚拟机规模集、应用服务或 AKS 作为底层基础结构,可以通过即时预配新的 VM 并复制应用程序的无状态组件来满足请求,以简化应用程序的缩放,但是数据库通常会成为集中式有状态组件的瓶颈。
使用只读副本功能可将数据从 Azure Database for MySQL 灵活服务器复制到只读服务器。 可将源服务器中的数据复制到最多 10 个副本。 使用 MySQL 引擎的基于本机二进制日志 (binlog) 文件位置的复制技术以异步方式更新副本。 若要了解有关 binlog 复制的详细信息,请参阅
MySQL binlog 复制概述
。
副本是新的服务器,可像管理源 Azure Database for MySQL 灵活服务器一样对其进行管理。 每个只读副本按照预配计算资源的 vCore 数量以及每月 GB 存储量计费。 有关详细信息,请参阅
定价
。
只读副本功能仅适用于“常规用途”或“业务关键”定价层中的 Azure Database for MySQL 灵活服务器。 请确保源服务器位于其中一个定价层中。
如需了解有关 MySQL 复制功能和问题的详细信息,请参阅
MySQL 复制文档
。
本文包含对术语“从属”的引用,这是 Microsoft 不再使用的术语。 在从软件中删除该术语后,我们会将其从本文中删除。
只读副本的常见用例
只读副本功能可帮助改善读取密集型工作负荷的性能与规模。 读取工作负载可与副本隔离,而写入工作负载可定向到源。
常见方案是:
使用轻量级连接代理(例如
ProxySQL
)或基于微服务的模式扩展来自应用程序的读取工作负载,从而将来自应用程序的读取查询横向扩展到只读副本
BI 或分析报告工作负载可使用只读副本用作数据源来进行报告
对于 IoT 或制造方案,其中遥测信息被引入到 MySQL 数据库引擎,而多个只读副本用于报告数据
副本是只读的,因此不能直接缓解源上的写入容量负担。 此功能并非面向写入密集型工作负荷。
只读副本功能使用 MySQL 本机异步复制。 该功能不适用于同步复制方案。 源与副本之间将会存在明显的延迟。 副本上的数据最终将与源上的数据保持一致。 对于能够适应这种延迟的工作负荷,可以使用此功能。
在异地配对区域中跨区域复制
可以在与源服务器不同的区域中创建只读副本。 跨区域复制对于灾难恢复规划或使数据更接近用户等方案非常有用。 Azure Database for MySQL 灵活服务器允许将 Azure 支持的 [异地配对区域] (
https://learn.microsoft.com/azure/reliability/cross-region-replication-azure
) 中的只读副本预配到源服务器。
如果源服务器没有现有的副本服务器,该源服务器会先重启,以便为复制做好自身准备。
启动“创建副本”工作流时,将创建空白的 Azure Database for MySQL 服务器。 新服务器中会填充源服务器上的数据。 创建时间取决于源服务器上的数据量,以及自上次每周完整备份以来所经历的时间。 具体所需时间从几分钟到几小时不等。
只读副本是使用与源服务器相同的服务器配置创建的。 副本服务器配置在创建后可以更改。 始终会在与源服务器相同的资源组、位置和订阅中创建副本服务器。 如果要将副本服务器创建到不同的资源组或不同的订阅,可以在创建后
移动副本服务器
。 建议副本服务器的配置应始终采用与源服务器相同或更大的值,以确保副本能够与源服务器保持一致。
了解如何
在 Azure 门户中创建只读副本
。
连接到副本
创建时,副本会继承源服务器的连接方法。 不能更改副本的连接方法。 例如,如果源服务器具有
专用访问权限(VNet 集成)
,副本不能处于
公共访问权限(允许的 IP 地址)
。
副本会从源服务器继承管理员帐户。 源服务器上的所有用户帐户都会复制到只读副本。 只能通过使用源服务器上可用的用户帐户来连接到只读副本。
可使用主机名和有效的用户帐户连接到副本,就像在常规的 Azure Database for MySQL 灵活服务器上连接一样。 对于名称为
myreplica
、管理员用户名为
myadmin
的服务器,可以使用 mysql CLI 连接到副本:
mysql -h myreplica.mysql.database.azure.com -u myadmin -p
在提示符下,输入用户帐户的密码。
Azure Database for MySQL 灵活服务器在 Azure Monitor 中提供“复制滞后时间(秒)”指标。 此指标仅适用于副本。 此指标是使用 MySQL 的 SHOW SLAVE STATUS
命令中提供的 seconds_behind_master
指标计算的。 请设置警报,以便在复制滞后时间达到工作负荷不可接受的值时收到通知。
如果发现复制滞后时间增加,请参阅排查复制延迟问题,以便排除故障并了解可能的原因。
只读副本使用基于存储的复制技术,该技术不再使用 MySQL 的“SHOW SLAVE STATUS”/“SHOW REPLICA STATUS”命令中提供的“SLAVE_IO_RUNNING”/“REPLICA_IO_RUNNING”指标。 该命令的值始终显示为“No”,不指示复制状态。 若要了解复制的正确状态,请查看监视边栏选项卡下的复制指标 -“副本 IO 状态”和“副本 SQL 状态”。
可以停止源与副本之间的复制。 在源服务器与只读副本之间停止复制后,该副本会成为独立服务器。 独立服务器中的数据是启动“停止复制”命令时副本上可用的数据。 独立服务器不会与源服务器保持同步。
选择停止复制到副本时,它会丢失指向其以前的源和其他副本的所有链接。 在源与其副本之间无法自动进行故障转移。
独立服务器不能再次成为副本。
在只读副本上停止复制之前,请确保副本包含所需的全部数据。
了解如何停止复制到副本。
在源服务器和副本服务器之间无法自动进行故障转移。
只读副本适用于扩展读取密集型工作负载,但并不用于满足服务器的高可用性需求。 执行这种手动故障转移的方式是,停止只读副本上的复制以使其在读写模式下处于联机状态。
由于复制是异步的,因此在源和副本之间存在滞后时间。 滞后程度会受许多因素影响,例如,在源服务器上运行的工作负载有多大,以及数据中心之间的延迟有多严重。 大多数情况下,副本验证在几秒钟到几分钟之间。 可以使用“副本延迟”指标来跟踪实际的副本延迟,该指标适用于每个副本。 该指标显示的是自上次重播事务以来所经历的时间。 建议观察一段时间的副本延迟,以便确定平均延迟。 可以针对副本延迟设置警报,这样,当它超出预期范围时,你就可以采取行动。
如果故障转移到副本,在取消副本与源的链接时的滞后时间会表明会丢失多少数据。
在已决定要故障转移到某个副本之后,请执行以下操作:
请停止将数据复制到副本
此步骤是使副本服务器能够接受写入所必需的。 在此过程中,副本服务器会取消与源的链接。 在启动了停止复制操作之后,后端进程通常需要大约 2 分钟才能完成。 请参阅本文的停止复制部分,了解此操作的潜在影响。
将应用程序指向(以前的)副本
每个服务器都有唯一的连接字符串。 更新应用程序,使之指向(以前的)副本而不是源。
应用程序成功处理读取和写入操作即表明故障转移已完成。 应用程序经历的停机时间取决于何时检测到问题并完成上面的步骤 1 和 2。
全局事务标识符 (GTID)
全局事务标识符 (GTID) 是使用源服务器上已提交的每个事务创建的唯一标识符,在 Azure Database for MySQL 灵活服务器中默认“关闭”。 GTID 在版本 5.7 和 8.0 上受支持。 若要详细了解 GTID 及其在复制中的使用方式,请参阅 MySQL 的使用 GTID 进行复制文档。
以下服务器参数可用于配置 GTID:
服务器参数
gtid_mode
指示是否使用 GTID 标识事务。 若要在两个模式之间进行更改,只能按升序顺序一次完成一个步骤(例如 OFF
->OFF_PERMISSIVE
->ON_PERMISSIVE
->ON
)
OFF
:新事务和复制事务都必须是匿名事务
OFF_PERMISSIVE
:新事务是匿名事务。 复制的事务可以是匿名事务,也可以是 GTID 事务。
ON_PERMISSIVE
:新事务是 GTID 事务。 复制的事务可以是匿名事务,也可以是 GTID 事务。
ON
:新事务和复制事务都必须是 GTID 事务。
enforce_gtid_consistency
通过仅允许执行能够以事务性安全方式记录的语句来强制实施 GTID 一致性。 在启用 GTID 复制之前,必须将此值设置为 ON
。
OFF
:允许所有事务违反 GTID 一致性。
ON
:不允许任何事务违反 GTID 一致性。
WARN
:允许所有事务违反 GTID 一致性,但系统会生成警告。
*对于启用了高可用性功能的 Azure Database for MySQL 灵活服务器,默认值设置为 ON
在启用 GTID 后,无法再将其关闭。 如果需要关闭 GTID,请与支持人员联系。
若要更改 GTID 的值,只能按模式的升序一次完成一个步骤。 例如,如果 gtid_mode 设置为 OFF_PERMISSIVE,则可以更改为 ON_PERMISSIVE,但不能更改为 ON。
为了保持复制一致性,无法更新主服务器/副本服务器的此设置。
建议先将 enforce_gtid_consistency 设置为 ON,然后再设置 gtid_mode=ON
若要启用 GTID 并配置一致性行为,请使用 Azure 门户或 Azure CLI 更新 gtid_mode
和 enforce_gtid_consistency
服务器参数。
如果在源服务器上启用了 GTID(gtid_mode
= 开),新建的副本也将启用 GTID 并使用 GTID 复制。 为了确保复制一致性,在启用 GTID 的情况下创建主服务器或副本服务器后,不能更改gtid_mode
。
注意事项和限制
限制/注意事项
副本是使用与源相同的服务器配置创建的。 在创建副本后,可以独立于源服务器更改多项设置:计算代系、vCore 数、存储,以及备份保持期。 也可单独更改计算层。
重要事项
- 将源服务器的配置更新为新值之前,请将副本配置更新为与这些新值相等或更大的值。 此操作可确保副本与源服务器发生的任何更改保持同步。
在创建副本时,连接方法和参数设置会从源服务器继承到副本。 之后,副本的规则便会独立。
停止的副本
如果停止源服务器与只读副本之间的复制,已停止的副本会成为接受读取和写入操作的独立服务器。 独立服务器不能再次成为副本。
已删除的源服务器和独立服务器
在删除源服务器时,会对所有只读副本都停止复制。 这些副本会自动成为独立服务器,并且可以接受读取和写入。 源服务器本身会被删除。
源服务器上的用户会复制到只读副本。 只能使用源服务器上可用的用户帐户来连接到只读副本。
服务器参数
为了防止数据不同步并避免潜在的数据丢失或损坏,使用读取副本时,会锁定某些服务器参数以防止其更新。
源服务器和副本服务器上都会锁定以下服务器参数:
- innodb_file_per_table
- log_bin_trust_function_creators
副本服务器上的 event_scheduler
参数处于锁定状态。
若要在源服务器上更新上述参数之一,请删除副本服务器,更新源上的参数值,然后重新创建副本。
会话级别参数
在只读副本上配置“foreign_keys_checks”之类的会话级参数时,请确保在只读副本上设置的参数值与源服务器的参数值一致。
将 AUTO_INCREMENT 主键列添加到源服务器中的现有表中。
不建议在创建只读副本后使用 AUTO_INCREMENT 更改表,因为这会中断复制。 但是,如果想要在创建副本服务器后添加自动增量列。 建议使用以下两种方法:
- 创建一个架构与要修改的表相同的新表。 在新表中使用 AUTO_INCREMENT 更改列,然后从原始表中还原数据。 删除旧表并在源中将其重命名,无需删除副本服务器,但可能需要大量的插入成本来创建备份表。
- 另一种更快速的方法是在添加所有自动增量列后重新创建副本。
- 不支持创建副本服务器的副本。
- 内存中的表可能会导致副本服务器变得不同步。这是 MySQL 复制技术的限制。 有关详细信息,请阅读 MySQL 参考文档中的更多信息。
- 确保源服务器表具有主键。 缺少主键可能会导致源和副本之间出现复制延迟。
- 查看 MySQL 文档中 MySQL 复制限制的完整列表
了解如何使用 Azure 门户创建和管理只读副本
了解如何使用 Azure CLI 创建和管理只读副本