MySQL 是一种常用的数据库引擎,用于运行 Internet 规模的 Web 和移动应用程序。 许多客户将 Azure Database for MySQL 用于各种应用程序,包括在线教育、视频流、数字支付、电子商务、游戏、新闻门户、政府和医疗保健网站。 这些服务必须能够在 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 Database for MySQL 灵活服务器可用的任何 Azure 支持区域中 预配只读副本。 利用此功能,源服务器可以在其配对区域或通用副本区域中拥有副本。 请参阅 此处 ,查找 Azure Database for MySQL 灵活服务器目前可用的 Azure 区域列表。
创建副本
启动创建副本工作流时,请创建一个空白的 Azure Database for MySQL 灵活服务器实例。 新服务器包含源服务器上的数据。 创建时间取决于源服务器上的数据量,以及自上次每周完整备份以来所经历的时间。 具体所需时间从几分钟到几小时不等。
注意
使用与源相同的服务器配置创建只读副本。 可以在创建后更改副本服务器配置。 始终在与源服务器相同的资源组和订阅中创建副本服务器。 如果要在不同的资源组或其他订阅中创建副本服务器,可以在创建后 移动副本服务器 。 将副本服务器的配置保留为等于或大于源的值,以确保副本可以跟上源。
了解如何在 Azure 门户中创建只读副本。
连接到副本
创建副本时,它将继承源服务器的连接方法。 不能更改副本的连接方法。 例如,如果源服务器使用专用访问(VNet 集成),则副本无法使用公共访问(允许的 IP 地址)。
副本会从源服务器继承管理员帐户。 源服务器上的所有用户帐户都会复制到只读副本。 只能使用源服务器上可用的用户帐户连接到只读副本。
可使用主机名和有效的用户帐户连接到副本,就像在常规的 Azure Database for MySQL 灵活服务器实例上连接一样。 对于使用管理员用户名 myadmin 的名为 myreplica 的服务器,可以使用 MySQL CLI 连接到副本:
mysql -h myreplica.mysql.database.chinacloudapi.cn -u myadmin -p
在提示符下,输入用户帐户的密码。
监视复制
Azure Database for MySQL 灵活服务器在 Azure Monitor 中提供“复制滞后时间(秒)”指标。 此指标仅适用于副本。 Azure Monitor 使用 seconds_behind_master
MySQL 命令中的 SHOW SLAVE STATUS
指标计算此指标。 设置警报,以便在复制滞后时间超过工作负荷的不可接受的阈值时通知你。
如果发现复制滞后时间增加,请参阅排查复制延迟问题,以便排除故障并了解可能的原因。
重要
只读副本使用基于存储的SLAVE_IO_RUNNING
/REPLICA_IO_RUNNING
复制技术,该技术不再使用 SHOW SLAVE
STATUS'/'SHOW
REPLICA STATUS
MySQL 命令中提供的指标。 此值始终显示为“否”,不指示复制状态。 若要了解复制的正确状态,请参阅“监视”页下的复制指标 - 副本 IO
状态 和 副本 SQL 状态 。
停止复制
可以停止源服务器和副本服务器之间的复制。 停止源服务器和只读副本之间的复制时,副本服务器将成为独立服务器。 独立服务器包含启动停止复制命令时副本服务器上可用的数据。 独立服务器不会同步源服务器中的任何缺失数据。
停止复制到副本服务器时,副本服务器会丢失其以前的源服务器和其他副本服务器的所有链接。 源服务器与其副本服务器之间没有自动故障转移。
重要
无法将独立服务器转换回副本服务器。 在停止只读副本上的复制之前,请确保副本服务器具有所需的所有数据。
有关详细信息,请参阅 停止复制到副本。
故障转移
在源服务器和副本服务器之间无法自动进行故障转移。
只读副本可缩放读取密集型工作负荷,并且不会为服务器提供高可用性。 通过在读写模式下将其联机来停止只读副本上的复制,可以执行手动故障转移。
由于复制是异步的,因此源和副本之间存在滞后时间。 许多因素会影响延迟量,例如源服务器上的工作负荷和数据中心之间的延迟。 在大多数情况下,副本滞后时间介于几秒钟到几分钟之间。 可以使用副本 滞后 指标跟踪实际的复制滞后时间,该指标可用于每个副本。 该指标显示的是自上次重播事务以来所经历的时间。 我们建议通过观察副本随时间推移来识别平均滞后时间。 可以针对副本延迟设置警报,这样,当它超出预期范围时,你就可以采取行动。
提示
如果故障转移到副本,则从源取消链接副本时延迟表示丢失的数据量。
决定故障转移到副本后:
请停止将数据复制到副本
需要停止复制,使副本服务器能够接受写入。 此过程从源中取消链接副本服务器。 启动停止复制后,后端过程通常需要大约两分钟才能完成。 请参阅本文的停止复制部分,了解此操作的潜在影响。
将应用程序指向(以前的)副本
每个服务器都有唯一的连接字符串。 更新应用程序,使之指向(以前的)副本而不是源。
当应用程序成功处理读取和写入时,完成故障转移。 应用程序体验的停机时间取决于检测到问题并完成步骤 1 和步骤 2 的时间。
全局事务标识符 (GTID)
全局事务标识符(GTID)是源服务器为每个提交的事务创建的唯一标识符。 默认情况下,Azure Database for MySQL 灵活服务器关闭 GTID。 版本 5.7 和 8.0 支持 GTID。 有关 GTID 及其使用方式的详细信息,请参阅 MySQL 的 复制与 GTID 文档。
使用以下服务器参数配置 GTID:
服务器参数 | 说明 | 默认值 | 值 |
---|---|---|---|
gtid_mode |
指示是否使用 GTID 标识事务。 模式之间的更改一次只能按升序执行一个步骤(例如, OFF ->OFF_PERMISSIVE ->ON_PERMISSIVE ->ON ) |
OFF* |
OFF :新事务和复制事务都必须是匿名事务OFF_PERMISSIVE :新事务是匿名事务。 复制的事务可以是匿名事务,也可以是 GTID 事务。ON_PERMISSIVE :新事务是 GTID 事务。 复制的事务可以是匿名事务,也可以是 GTID 事务。ON :新事务和复制事务都必须是 GTID 事务。 |
enforce_gtid_consistency |
通过仅允许执行能够以事务性安全方式记录的语句来强制实施 GTID 一致性。 在启用 GTID 复制之前设置值 ON 。 |
OFF* |
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 并配置一致性行为,请更新 gtid_mode
和 enforce_gtid_consistency
服务器参数。
使用 Azure 门户在 Azure Database for MySQL 灵活服务器中使用配置服务器参数,或使用 Azure CLI 在 Azure Database for MySQL 灵活服务器中配置服务器参数。
如果源服务器启用 GTID (gtid_mode
= ON
),新创建的副本也会启用 GTID 并使用 GTID 复制。 若要确保复制一致性,在创建启用了 GTID 的主服务器或副本服务器后,无法更改 gtid_mode
。
注意事项和限制
方案 | 限制/注意事项 |
---|---|
可突发定价层中的服务器副本 | 不支持 |
定价 | 运行副本服务器的成本取决于运行副本服务器的区域。 |
源服务器停机时间/重启 | 创建只读副本时无需重启或停机。 此作是联机作。 |
新副本 | 将只读副本创建为新的 Azure Database for MySQL 灵活服务器实例。 不能将现有服务器设为副本。 无法创建另一个只读副本的副本。 |
副本配置 | 使用与源相同的服务器配置创建副本。 创建副本后,可以独立于源服务器更改多个设置:计算生成、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 复制限制的完整列表。 |