MySQL 是一种常用的数据库引擎，用于运行 Internet 规模的 Web 和移动应用程序。 许多客户将Azure Database for MySQL用于各种应用程序，包括在线教育、视频流、数字支付、电子商务、游戏、新闻门户、政府和医疗保健网站。 这些服务必须能够在 Web 或移动应用程序上的流量增加时，满足服务要求并实现扩展。
在应用程序端，开发人员通常使用Java或 PHP。 它们迁移应用程序以在Azure Virtual Machine Scale Sets、Azure App服务上运行，或将其容器化为在 Azure Kubernetes Service (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 复制文档。
注意
本文包含对术语 slave 的引用，该术语Microsoft不再使用。 从软件中删除术语时，我们会将其从本文中删除。
只读副本的常见用例
只读副本功能可帮助你提高读取密集型工作负荷的性能和规模。 可以将读取工作负荷隔离到副本，同时将写入工作负荷定向到源。
常见方案包括：
- 使用轻型连接代理（如 ProxySQL 或基于微服务的模式）缩放来自应用程序的读取工作负荷，以横向扩展来自应用程序的读取查询到只读副本
- 使用只读副本作为 BI 或分析报告工作负载的数据源
- 在 IoT 或制造场景中使用多个读副本生成数据报告，并将遥测信息导入 MySQL 数据库引擎
副本是只读的，因此不能直接缓解源上的写入容量负担。 此功能不适用于写入密集型的工作负载。
读取副本功能使用 MySQL 异步复制。 该功能不适用于同步复制方案。 源与副本之间存在可以衡量的延迟。 副本上的数据最终将与源上的数据保持一致。 对于能够适应这种延迟的工作负荷，可以使用此功能。
跨区域复制
可以在与源服务器所在区域不同的区域中创建只读副本。 跨区域复制对于灾难恢复规划或使数据更接近用户等方案非常有用。 Azure Database for MySQL 灵活服务器允许您在任何 Azure Database for MySQL 灵活服务器可用的 Azure 受支持的区域中创建只读副本。 利用此功能，源服务器可以在其配对区域或通用副本区域中拥有副本。 请参阅 here，查找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在 MySQL 的 seconds_behind_master 命令中使用 SHOW SLAVE STATUS 指标计算此指标。 设置警报，以便在复制滞后时间超过工作负荷的不可接受的阈值时通知你。
如果发现复制滞后时间增加，请参阅排查复制延迟问题，以便排除故障并了解可能的原因。
重要
只读副本使用基于存储的复制技术，该技术不再使用 MySQL 的SLAVE_IO_RUNNING/REPLICA_IO_RUNNING命令中提供的SHOW SLAVESTATUS'/'SHOWREPLICA STATUS指标。 此值始终显示为“否”，不指示复制状态。 若要了解复制的正确状态，请参阅“监视”页下的复制指标 - 副本 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 Database for MySQL - 灵活服务器中，通过使用 Azure 门户配置服务器参数 或通过使用 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 复制限制的完整列表。 |