Azure Database for MySQL 中的只读副本Read replicas in Azure Database for MySQL

使用只读副本功能可将数据从 Azure Database for MySQL 服务器复制到只读服务器。The read replica feature allows you to replicate data from an Azure Database for MySQL server to a read-only server. 可将源服务器中的数据复制到最多 5 个副本。You can replicate from the source server to up to five replicas. 使用 MySQL 引擎的基于本机二进制日志 (binlog) 文件位置的复制技术以异步方式更新副本。Replicas are updated asynchronously using the MySQL engine's native binary log (binlog) file position-based replication technology. 若要了解有关 binlog 复制的详细信息,请参阅 MySQL binlog 复制概述To learn more about binlog replication, see the MySQL binlog replication overview.

备注

将要查看的是 Azure Database for MySQL 的新服务。You are viewing the new service of Azure Database for MySQL. 若要查看经典 MySQL Database for Azure 的文档,请访问此页To view the documentation for classic MySQL Database for Azure, please visit this page.

副本是新的服务器,可以像管理普通的 Azure Database for MySQL 服务器一样对其进行管理。Replicas are new servers that you manage similar to regular Azure Database for MySQL servers. 每个只读副本按照预配计算资源的 vCore 数量以及每月 GB 存储量计费。For each read replica, you're billed for the provisioned compute in vCores and storage in GB/ month.

如需了解有关 MySQL 复制功能和问题的详细信息,请参阅 MySQL 复制文档To learn more about MySQL replication features and issues, see the MySQL replication documentation.

备注

本文包含对术语“从属”的引用,这是 Microsoft 不再使用的术语。This article contains references to the term slave, a term that Microsoft no longer uses. 在从软件中删除该术语后,我们会将其从本文中删除。When the term is removed from the software, we'll remove it from this article.

何时使用只读副本When to use a read replica

只读副本功能可帮助改善读取密集型工作负荷的性能与规模。The read replica feature helps to improve the performance and scale of read-intensive workloads. 读取工作负载可与副本隔离,而写入工作负载可定向到源。Read workloads can be isolated to the replicas, while write workloads can be directed to the source.

常见方案是让 BI 和分析工作负载将只读副本用作报告的数据源。A common scenario is to have BI and analytical workloads use the read replica as the data source for reporting.

副本是只读的,因此不能直接缓解源上的写入容量负担。Because replicas are read-only, they don't directly reduce write-capacity burdens on the source. 此功能并非面向写入密集型工作负荷。This feature isn't targeted at write-intensive workloads.

只读副本功能使用 MySQL 本机异步复制。The read replica feature uses MySQL asynchronous replication. 该功能不适用于同步复制方案。The feature isn't meant for synchronous replication scenarios. 源与副本之间将会存在明显的延迟。There will be a measurable delay between the source and the replica. 副本上的数据最终将与源上的数据保持一致。The data on the replica eventually becomes consistent with the data on the source. 对于能够适应这种延迟的工作负荷,可以使用此功能。Use this feature for workloads that can accommodate this delay.

跨区域复制Cross-region replication

可以在与源服务器不同的区域中创建只读副本。You can create a read replica in a different region from your source server. 跨区域复制对于灾难恢复规划或使数据更接近用户等方案非常有用。Cross-region replication can be helpful for scenarios like disaster recovery planning or bringing data closer to your users.

任何 Azure Database for MySQL 区域中都可以有源服务器。You can have a source server in any Azure Database for MySQL region. 源服务器可以在其配对区域中有副本。A source server can have a replica in its paired region.

配对区域Paired regions

可以在源服务器的 Azure 配对区域中创建只读副本。You can create a read replica in the Azure paired region of your source server. 如果你不知道所在区域的配对,可以从 Azure 配对区域一文中了解更多信息。If you don't know your region's pair, you can learn more from the Azure Paired Regions article.

如果你使用跨区域副本进行灾难恢复规划,建议你在配对区域中而不是其他某个区域中创建副本。If you're using cross-region replicas for disaster recovery planning, we recommend you create the replica in the paired region instead of one of the other regions. 配对区域可避免同时更新,并优先考虑物理隔离和数据驻留。Paired regions avoid simultaneous updates and prioritize physical isolation and data residency.

创建副本Create a replica

重要

只读副本功能仅适用于“常规用途”或“内存优化”定价层中的 Azure Database for MySQL 服务器。The read replica feature is only available for Azure Database for MySQL servers in the General Purpose or Memory Optimized pricing tiers. 请确保源服务器位于其中一个定价层中。Ensure the source server is in one of these pricing tiers.

如果源服务器没有现有的副本服务器,该源服务器会先重启,以便为复制做好自身准备。If a source server has no existing replica servers, the source will first restart to prepare itself for replication.

启动“创建副本”工作流时,将创建空白的 Azure Database for MySQL 服务器。When you start the create replica workflow, a blank Azure Database for MySQL server is created. 新服务器中会填充源服务器上的数据。The new server is filled with the data that was on the source server. 创建时间取决于源服务器上的数据量,以及自上次每周完整备份以来所经历的时间。The creation time depends on the amount of data on the source and the time since the last weekly full backup. 具体所需时间从几分钟到几小时不等。The time can range from a few minutes to several hours. 始终会在与源服务器相同的资源组和订阅中创建副本服务器。The replica server is always created in the same resource group and same subscription as the source server. 如果要将副本服务器创建到不同的资源组或不同的订阅,可以在创建后移动副本服务器If you want to create a replica server to a different resource group or different subscription, you can move the replica server after creation.

每个副本都启用了存储自动增长Every replica is enabled for storage auto-grow. 自动增长功能允许副本与复制到它的数据保持同步,并防止由于存储空间不足错误而导致的复制中断。The auto-grow feature allows the replica to keep up with the data replicated to it, and prevent an interruption in replication caused by out-of-storage errors.

了解如何在 Azure 门户中创建只读副本Learn how to create a read replica in the Azure portal.

连接到副本Connect to a replica

创建时,副本会继承源服务器的防火墙规则。At creation, a replica inherits the firewall rules of the source server. 之后,这些规则将独立于源服务器。Afterwards, these rules are independent from the source server.

副本会从源服务器继承管理员帐户。The replica inherits the admin account from the source server. 源服务器上的所有用户帐户都会复制到只读副本。All user accounts on the source server are replicated to the read replicas. 只能通过使用源服务器上可用的用户帐户来连接到只读副本。You can only connect to a read replica by using the user accounts that are available on the source server.

可以使用主机名和有效的用户帐户连接到副本,就像在常规的 Azure Database for MySQL 服务器上连接一样。You can connect to the replica by using its hostname and a valid user account, as you would on a regular Azure Database for MySQL server. 对于名称为 myreplica、管理员用户名为 myadmin 的服务器,可以使用 mysql CLI 连接到副本:For a server named myreplica with the admin username myadmin, you can connect to the replica by using the mysql CLI:

mysql -h myreplica.mysql.database.chinacloudapi.cn -u myadmin@myreplica -p

在提示符下,输入用户帐户的密码。At the prompt, enter the password for the user account.

监视复制Monitor replication

Azure Database for MySQL 在 Azure Monitor 中提供“复制滞后时间(秒)”指标。Azure Database for MySQL provides the Replication lag in seconds metric in Azure Monitor. 此指标仅适用于副本。This metric is available for replicas only. 此指标是使用 MySQL 的 SHOW SLAVE STATUS 命令中提供的 seconds_behind_master 指标计算的。This metric is calculated using the seconds_behind_master metric available in MySQL's SHOW SLAVE STATUS command. 请设置警报,以便在复制滞后时间达到工作负荷不可接受的值时收到通知。Set an alert to inform you when the replication lag reaches a value that isn't acceptable for your workload.

如果发现复制滞后时间增加,请参阅排查复制延迟问题,以便排除故障并了解可能的原因。If you see increased replication lag, refer to troubleshooting replication latency to troubleshoot and understand possible causes.

停止复制Stop replication

可以停止源与副本之间的复制。You can stop replication between a source and a replica. 在源服务器与只读副本之间停止复制后,该副本会成为独立服务器。After replication is stopped between a source server and a read replica, the replica becomes a standalone server. 独立服务器中的数据是启动“停止复制”命令时副本上可用的数据。The data in the standalone server is the data that was available on the replica at the time the stop replication command was started. 独立服务器不会与源服务器保持同步。The standalone server doesn't catch up with the source server.

选择停止复制到副本时,它会丢失指向其以前的源和其他副本的所有链接。When you choose to stop replication to a replica, it loses all links to its previous source and other replicas. 在源与其副本之间无法自动进行故障转移。There's no automated failover between a source and its replica.

重要

独立服务器不能再次成为副本。The standalone server can't be made into a replica again. 在只读副本上停止复制之前,请确保副本包含所需的全部数据。Before you stop replication on a read replica, ensure the replica has all the data that you require.

了解如何停止复制到副本Learn how to stop replication to a replica.

故障转移Failover

在源服务器和副本服务器之间无法自动进行故障转移。There's no automated failover between source and replica servers.

由于复制是异步的,因此在源和副本之间存在滞后时间。Since replication is asynchronous, there's lag between the source and the replica. 滞后程度会受许多因素影响,例如,在源服务器上运行的工作负载有多大,以及数据中心之间的延迟有多严重。The amount of lag can be influenced by many factors like how heavy the workload running on the source server is and the latency between data centers. 大多数情况下,副本验证在几秒钟到几分钟之间。In most cases, replica lag ranges between a few seconds to a couple minutes. 可以使用“副本延迟”指标来跟踪实际的副本延迟,该指标适用于每个副本。You can track your actual replication lag using the metric Replica Lag, which is available for each replica. 该指标显示的是自上次重播事务以来所经历的时间。This metric shows the time since the last replayed transaction. 建议观察一段时间的副本延迟,以便确定平均延迟。We recommend that you identify what your average lag is by observing your replica lag over a period of time. 可以针对副本延迟设置警报,这样,当它超出预期范围时,你就可以采取行动。You can set an alert on replica lag, so that if it goes outside your expected range, you can take action.

提示

如果你故障转移到副本,在取消副本与源的链接时的滞后时间将表明会丢失多少数据。If you failover to the replica, the lag at the time you delink the replica from the source will indicate how much data is lost.

在已决定要故障转移到某个副本之后,请执行以下操作:After you've decided you want to failover to a replica:

  1. 请停止将数据复制到副本Stop replication to the replica
    此步骤是使副本服务器能够接受写入所必需的。This step is necessary to make the replica server able to accept writes. 在此过程中,副本服务器会取消与源的链接。As part of this process, the replica server will be delinked from the source. 在启动停止复制操作之后,后端进程通常需要大约 2 分钟才能完成。After you initiate stop replication, the backend process typically takes about 2 minutes to complete. 请参阅本文的停止复制部分,了解此操作的潜在影响。See the stop replication section of this article to understand the implications of this action.

  2. 将应用程序指向(以前的)副本Point your application to the (former) replica
    每个服务器都有唯一的连接字符串。Each server has a unique connection string. 更新应用程序,使之指向(以前的)副本而不是源。Update your application to point to the (former) replica instead of the source.

应用程序成功处理读取和写入操作即表明故障转移已完成。After your application is successfully processing reads and writes, you've completed the failover. 应用程序经历停机时间的长短将取决于你何时检测到问题并完成前面列出的步骤 1 和 2。The amount of downtime your application experiences will depend on when you detect an issue and complete steps 1 and 2 listed previously.

全局事务标识符 (GTID)Global transaction identifier (GTID)

全局事务标识符 (GTID) 是使用源服务器上的每个提交的事务创建的唯一标识符,在 Azure Database for MySQL 中默认处于关闭状态。Global transaction identifier (GTID) is a unique identifier created with each committed transaction on a source server and is OFF by default in Azure Database for MySQL. GTID 在版本 5.7 和 8.0 中受支持,且仅在所支持的存储不超过 16 TB 的服务器上受支持。GTID is supported on versions 5.7 and 8.0 and only on servers that support storage up to 16 TB. 若要详细了解 GTID 及其在复制中的使用方式,请参阅 MySQL 的使用 GTID 进行复制文档。To learn more about GTID and how it's used in replication, refer to MySQL's replication with GTID documentation.

MySQL 支持两种类型的事务:GTID 事务(使用 GTID 标识)和匿名事务(未分配 GTID)MySQL supports two types of transactions: GTID transactions (identified with GTID) and anonymous transactions (don't have a GTID allocated)

以下服务器参数可用于配置 GTID:The following server parameters are available for configuring GTID:

服务器参数Server parameter 说明Description 默认值Default Value Values
gtid_mode 指示是否使用 GTID 标识事务。Indicates if GTIDs are used to identify transactions. 若要在两个模式之间进行更改,只能按升序顺序一次完成一个步骤(例如Changes between modes can only be done one step at a time in ascending order (ex. OFF -> OFF_PERMISSIVE -> ON_PERMISSIVE -> ON)OFF -> OFF_PERMISSIVE -> ON_PERMISSIVE -> ON) OFF OFF:新事务和复制事务都必须是匿名事务OFF: Both new and replication transactions must be anonymous
OFF_PERMISSIVE:新事务是匿名事务。OFF_PERMISSIVE: New transactions are anonymous. 复制的事务可以是匿名事务,也可以是 GTID 事务。Replicated transactions can either be anonymous or GTID transactions.
ON_PERMISSIVE:新事务是 GTID 事务。ON_PERMISSIVE: New transactions are GTID transactions. 复制的事务可以是匿名事务,也可以是 GTID 事务。Replicated transactions can either be anonymous or GTID transactions.
ON:新事务和复制事务都必须是 GTID 事务。ON: Both new and replicated transactions must be GTID transactions.
enforce_gtid_consistency 通过仅允许执行能够以事务性安全方式记录的语句来强制实施 GTID 一致性。Enforces GTID consistency by allowing execution of only those statements that can be logged in a transactionally safe manner. 在启用 GTID 复制之前,必须将此值设置为 ONThis value must be set to ON before enabling GTID replication. OFF OFF:允许所有事务违反 GTID 一致性。OFF: All transactions are allowed to violate GTID consistency.
ON:不允许任何事务违反 GTID 一致性。ON: No transaction is allowed to violate GTID consistency.
WARN:允许所有事务违反 GTID 一致性,但系统会生成警告。WARN: All transactions are allowed to violate GTID consistency, but a warning is generated.

备注

在启用 GTID 后,无法再将其关闭。After GTID is enabled, you cannot turn it back off. 如果需要关闭 GTID,请与支持人员联系。If you need to turn GTID OFF, please contact support.

若要启用 GTID 并配置一致性行为,请使用 Azure 门户Azure CLIPowerShell更新 gtid_modeenforce_gtid_consistency 服务器参数。To enable GTID and configure the consistency behavior, update the gtid_mode and enforce_gtid_consistency server parameters using the Azure portal, Azure CLI, or PowerShell.

如果在源服务器上启用了 GTID(gtid_mode = 开),则新创建的副本也将启用 GTID 并使用 GTID 复制。If GTID is enabled on a source server (gtid_mode = ON), newly created replicas will also have GTID enabled and use GTID replication. 无法在源或副本服务器上更新 gtid_mode,这是为了保持复制一致性。To keep replication consistent, you can't update gtid_mode on the source or replica server(s).

注意事项和限制Considerations and limitations

定价层Pricing tiers

只读副本当前仅适用于“常规用途”和“内存优化”的定价层。Read replicas are currently only available in the General Purpose and Memory Optimized pricing tiers.

备注

运行副本服务器的成本取决于副本服务器的运行区域。The cost of running the replica server is based on the region where the replica server is running.

源服务器重启Source server restart

在为没有现有副本的源创建副本时,该源服务器会先重启,以便为复制做好自身准备。When you create a replica for a source that has no existing replicas, the source will first restart to prepare itself for replication. 请考虑这一点并在非高峰期执行这些操作。Take this into consideration and perform these operations during an off-peak period.

新副本New replicas

只读副本创建为新的 Azure Database for MySQL 服务器。A read replica is created as a new Azure Database for MySQL server. 无法将现有的服务器设为副本。An existing server can't be made into a replica. 无法创建另一个只读副本的副本。You can't create a replica of another read replica.

副本配置Replica configuration

副本是使用与源相同的服务器配置创建的。A replica is created by using the same server configuration as the source. 在创建副本后,可以独立于源服务器更改多项设置:计算代系、vCore 数、存储,以及备份保持期。After a replica is created, several settings can be changed independently from the source server: compute generation, vCores, storage, and backup retention period. 定价层也可以独立更改,但“基本”层除外。The pricing tier can also be changed independently, except to or from the Basic tier.

重要

将源服务器的配置更新为新值之前,请将副本配置更新为与这些新值相等或更大的值。Before a source server configuration is updated to new values, update the replica configuration to equal or greater values. 此操作可确保副本与源服务器发生的任何更改保持同步。This action ensures the replica can keep up with any changes made to the source.

在创建副本时,防火墙规则和参数设置会从源服务器继承到副本。Firewall rules and parameter settings are inherited from the source server to the replica when the replica is created. 之后,副本的规则便会独立。Afterwards, the replica's rules are independent.

停止的副本Stopped replicas

如果停止源服务器与只读副本之间的复制,已停止的副本会成为接受读取和写入操作的独立服务器。If you stop replication between a source server and a read replica, the stopped replica becomes a standalone server that accepts both reads and writes. 独立服务器不能再次成为副本。The standalone server can't be made into a replica again.

已删除的源服务器和独立服务器Deleted source and standalone servers

在删除源服务器时,会对所有只读副本都停止复制。When a source server is deleted, replication is stopped to all read replicas. 这些副本会自动成为独立服务器,并且可以接受读取和写入。These replicas automatically become standalone servers and can accept both reads and writes. 源服务器本身会被删除。The source server itself is deleted.

用户帐户User accounts

源服务器上的用户会复制到只读副本。Users on the source server are replicated to the read replicas. 只能使用源服务器上可用的用户帐户来连接到只读副本。You can only connect to a read replica using the user accounts available on the source server.

服务器参数Server parameters

为了防止数据不同步并避免潜在的数据丢失或损坏,使用读取副本时,会锁定某些服务器参数以防止其更新。To prevent data from becoming out of sync and to avoid potential data loss or corruption, some server parameters are locked from being updated when using read replicas.

源服务器和副本服务器上都会锁定以下服务器参数:The following server parameters are locked on both the source and replica servers:

副本服务器上的 event_scheduler 参数处于锁定状态。The event_scheduler parameter is locked on the replica servers.

若要在源服务器上更新上述参数之一,请删除副本服务器,更新源上的参数值,然后重新创建副本。To update one of the above parameters on the source server, delete replica servers, update the parameter value on the source, and recreate replicas.

GTIDGTID

GTID 在以下版本上受支持:GTID is supported on:

  • MySQL 版本 5.7 和 8.0。MySQL versions 5.7 and 8.0.
  • 支持不超过 16 TB 的存储的服务器。Servers that support storage up to 16 TB. 若要获取支持 16 TB 存储的区域的完整列表,请参阅定价层一文。Refer to the pricing tier article for the full list of regions that support 16 TB storage.

GTID 默认处于关闭状态。GTID is OFF by default. 在启用 GTID 后,无法再将其关闭。After GTID is enabled, you can't turn it back off. 如果需要关闭 GTID,请与支持人员联系。If you need to turn GTID OFF, contact support.

如果在源服务器上启用了 GTID,则新创建的副本也将启用 GTID 并使用 GTID 复制。If GTID is enabled on a source server, newly created replicas will also have GTID enabled and use GTID replication. 无法在源或副本服务器上更新 gtid_mode,这是为了保持复制一致性。To keep replication consistent, you can't update gtid_mode on the source or replica server(s).

其他Other

  • 不支持创建副本服务器的副本。Creating a replica of a replica isn't supported.
  • 内存中的表可能会导致副本服务器变得不同步。这是 MySQL 复制技术的限制。In-memory tables may cause replicas to become out of sync. This is a limitation of the MySQL replication technology. 有关详细信息,请阅读 MySQL 参考文档中的更多信息。Read more in the MySQL reference documentation for more information.
  • 请确保源服务器表具有主键。Ensure the source server tables have primary keys. 缺少主键可能会导致源和副本之间出现复制延迟。Lack of primary keys may result in replication latency between the source and replicas.
  • 查看 MySQL 文档中 MySQL 复制限制的完整列表Review the full list of MySQL replication limitations in the MySQL documentation

后续步骤Next steps