Azure Database for PostgreSQL(单一服务器)中的只读副本Read replicas in Azure Database for PostgreSQL - Single Server

使用只读副本功能可将数据从 Azure Database for PostgreSQL 服务器复制到只读服务器。The read replica feature allows you to replicate data from an Azure Database for PostgreSQL server to a read-only server. 副本通过 PostgreSQL 引擎的本机物理复制技术以异步方式更新。Replicas are updated asynchronously with the PostgreSQL engine native physical replication technology. 可将主服务器中的数据最多复制到 5 个副本。You can replicate from the primary server to up to five replicas.

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

了解如何创建和管理副本Learn how to create and manage replicas.

何时使用只读副本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 primary. 只读副本也可以部署在不同的区域,并且在发生灾难恢复时,可以将其提升为读/写服务器。Read replicas can also be deployed on a different region and can be promoted to be a read/write server in the event of a disaster recovery.

常见方案是让 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 primary.

注意事项Considerations

此功能适用于可接受滞后的方案,旨在减轻查询负担。The feature is meant for scenarios where the lag is acceptable and meant for offloading queries. 它不适用于同步复制方案,此类方案要求副本数据是最新数据。It isn't meant for synchronous replication scenarios where the replica data is expected to be up-to-date. 主服务器与副本之间将存在明显的延迟。There will be a measurable delay between the primary and the replica. 这可能是几分钟甚至几小时,具体取决于工作负荷以及主服务器与副本之间的延迟。This can be in minutes or even hours depending on the workload and the latency between the primary and the replica. 副本上的数据最终将与主服务器上的数据保持一致。The data on the replica eventually becomes consistent with the data on the primary. 对于能够适应这种延迟的工作负荷,可以使用此功能。Use this feature for workloads that can accommodate this delay.

备注

对于大多数工作负荷,只读副本提供来自主服务器的准实时更新。For most workloads read replicas offer near-real-time updates from the primary. 但是,对于持久的大量写入密集型主工作负荷,复制滞后时间可能会持续增长,并且可能永远都无法赶上主服务器。However, with persistent heavy write-intensive primary workloads, the replication lag could continue to grow and may never be able to catch-up with the primary. 这也可能会增加主服务器上的存储使用量,因为在副本收到 WAL 文件之前,这些文件不会被删除。This may also increase storage usage at the primary as the WAL files are not deleted until they are received at the replica. 如果这种情况持续存在,则可以选择在写入密集型工作负荷完成后删除并重新创建只读副本,以使副本恢复到相对于滞后的良好状态。If this situation persists, deleting and recreating the read replica after the write-intensive workloads completes is the option to bring the replica back to a good state with respect to lag. 异步只读副本不适合这种繁重的写入工作负荷。Asynchronous read replicas are not suitable for such heavy write workloads. 评估应用程序的只读副本时,请在完整的应用工作负荷周期,通过其高峰时间和非高峰时间来监视副本上的滞后时间,以获取工作负荷周期各个点可能的滞后时间和预期的 RTO/RPO。When evaluating read replicas for your application, monitor the lag on the replica for a full app work load cycle thru its peak and non-peak times to access the possible lag and the expected RTO/RPO at various points of the workload cycle.

跨区域复制Cross-region replication

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

备注

基本层服务器仅支持相同区域复制。Basic tier servers only support same-region replication.

你可以在任何 Azure Database for PostgreSQL 区域中拥有主服务器。You can have a primary server in any Azure Database for PostgreSQL region. 主服务器可以在其配对区域中有一个副本。A primary server can have a replica in its paired region.

配对区域Paired regions

如果你使用跨区域副本进行灾难恢复规划,建议你在配对区域而不是其他某个区域中创建副本。If you are 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 PostgreSQL 服务器。When you start the create replica workflow, a blank Azure Database for PostgreSQL server is created. 新服务器中填充了主服务器上的数据。The new server is filled with the data that was on the primary server. 创建时间取决于主服务器上的数据量,以及自上次每周完整备份以来所经历的时间。The creation time depends on the amount of data on the primary and the time since the last weekly full backup. 具体所需时间从几分钟到几小时不等。The time can range from a few minutes to several hours.

每个副本都启用了存储自动增长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 a break in replication caused by out of storage errors.

只读副本功能使用 PostgreSQL 的物理复制,而不使用逻辑复制。The read replica feature uses PostgreSQL physical replication, not logical replication. 使用复制槽位的流复制是默认的操作模式。Streaming replication by using replication slots is the default operation mode. 必要时,使用日志传送来跟上进度。When necessary, log shipping is used to catch up.

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

连接到副本Connect to a replica

创建副本时,该副本不会继承主服务器的防火墙规则或 VNet 服务终结点。When you create a replica, it doesn't inherit the firewall rules or VNet service endpoint of the primary server. 必须单独为副本设置这些规则。These rules must be set up independently for the replica.

副本从主服务器继承管理员帐户。The replica inherits the admin account from the primary server. 主服务器上的所有用户帐户将复制到只读副本。All user accounts on the primary 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 primary server.

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

psql -h myreplica.postgres.database.chinacloudapi.cn -U myadmin@myreplica -d postgres

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

监视复制Monitor replication

Azure Database for PostgreSQL 提供了两个用于监视复制的指标。Azure Database for PostgreSQL provides two metrics for monitoring replication. 这两个指标是 副本的最大滞后时间副本滞后时间The two metrics are Max Lag Across Replicas and Replica Lag. 若要了解如何查看这些指标,请参阅只读副本操作指南文章的“监视副本”部分。To learn how to view these metrics, see the Monitor a replica section of the read replica how-to article.

“副本的最大滞后时间”指标显示主服务器与滞后时间最长的副本之间的滞后时间(以字节为单位)。The Max Lag Across Replicas metric shows the lag in bytes between the primary and the most-lagging replica. 此指标仅适用于主服务器,仅当至少有一个只读副本已连接到主服务器且主服务器处于流式复制模式时才可用。This metric is applicable and available on the primary server only, and will be available only if at least one of the read replica is connected to the primary and the primary is in streaming replication mode. 如果副本正在使用主服务器的存档日志,在文件传输复制模式下与主服务器保持同步,则滞后信息不会显示详细信息。The lag information does not show details when the replica is in the process of catching up with the primary using the archived logs of the primary in a file-shipping replication mode.

“副本滞后时间”指标显示的是自上次重放事务以来所经历的时间。The Replica Lag metric shows the time since the last replayed transaction. 如果主服务器上未发生任何事务,则该指标会反映此滞后时间。If there are no transactions occurring on your primary server, the metric reflects this time lag. 此指标仅适用于副本服务器。This metric is applicable and available for replica servers only. “副本滞后时间”是从 pg_stat_wal_receiver 视图计算得出的:Replica Lag is calculated from the pg_stat_wal_receiver view:

SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());

请设置警报,以便在副本滞后时间达到工作负荷不可接受的值时收到通知。Set an alert to inform you when the replica lag reaches a value that isn’t acceptable for your workload.

若要获取更多见解,请直接查询主服务器,以获取所有副本上的复制滞后情况(以字节为单位)。For additional insight, query the primary server directly to get the replication lag in bytes on all replicas.

备注

如果主服务器或只读副本重启,“副本滞后时间”指标中会反映重启以及跟上进度所花费的时间。If a primary server or read replica restarts, the time it takes to restart and catch up is reflected in the Replica Lag metric.

停止复制/提升副本Stop replication / Promote replica

你可以随时停止主服务器与副本之间的复制。You can stop the replication between a primary and a replica at any time. 停止操作将导致副本重新启动,并将副本提升为独立的可读写服务器。The stop action causes the replica to restart and promotes the replica to be an independent, standalone read-writeable server. 独立服务器中的数据是停止复制时副本服务器上可用的数据。The data in the standalone server is the data that was available on the replica server at the time the replication is stopped. 主服务器上的任何后续更新都不会传播到副本。Any subsequent updates at the primary are not propagated to the replica. 但是,副本服务器可能已经累积了尚未应用的日志。However, replica server may have accumulated logs that are not applied yet. 在重启过程中,副本会在接受客户端连接之前应用所有挂起的日志。As part of the restart process, the replica applies all the pending logs before accepting client connections.

注意事项Considerations

  • 在只读副本上停止复制之前,请检查复制滞后时间,确保副本包含所需的全部数据。Before you stop replication on a read replica, check for the replication lag to ensure the replica has all the data that you require.
  • 由于只读副本必须应用所有挂起的日志,才能成为独立的服务器,因此在停止复制时,写入繁重的工作负荷的 RTO 可能较高,因为副本上可能会有明显的延迟。As the read replica has to apply all pending logs before it can be made a standalone server, RTO can be higher for write heavy workloads when the stop replication happens as there could be a significant delay on the replica. 计划提升副本时,请注意这一点。Please pay attention to this when planning to promote a replica.
  • 提升后的副本服务器不能再次成为副本。The promoted replica server cannot be made into a replica again.
  • 如果将副本提升为主服务器,则无法与旧的主服务器重新建立复制。If you promote a replica to be the primary server, you cannot establish replication back to the old primary server. 如果要返回到旧的主区域,可以使用新名称建立新的副本服务器,或删除旧的主服务器,然后使用旧的主名称创建副本。If you want to go back to the old primary region, you can either establish a new replica server with a new name (or) delete the old primary and create a replica using the old primary name.
  • 如果你有多个只读副本,并将其中一个提升为主服务器,则其他副本服务器仍连接到旧的主服务器。If you have multiple read replicas, and if you promote one of them to be your primary server, other replica servers are still connected to the old primary. 你可能需要从新的已提升服务器重新创建副本。You may have to recreate replicas from the new, promoted server.

停止复制后,副本会失去指向其以前的主服务器和其他副本的所有链接。When you stop replication, the replica loses all links to its previous primary and other replicas.

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

故障转移到副本Failover to replica

在主服务器发生故障的情况下,系统不会自动故障转移到只读副本。In the event of a primary server failure, it is not automatically failed over to the read replica.

由于复制是异步的,因此在主服务器和副本之间可能存在明显的滞后。Since replication is asynchronous, there could be a considerable lag between the primary and the replica. 滞后时间量受许多因素影响,例如,主服务器上运行的工作负荷类型,以及主服务器和副本服务器之间的延迟。The amount of lag is influenced by a number of factors such as the type of workload running on the primary server and the latency between the primary and the replica server. 在一般情况下,如果运行名义上的写入工作负荷,副本滞后时间预期为几秒钟到几分钟。In typical cases with nominal write workload, replica lag is expected between a few seconds to few minutes. 但是,如果主服务器运行非常繁重的写入密集型工作负荷并且副本的跟进速度不够快,则滞后时间可能会长得多。However, in cases where the primary runs very heavy write-intensive workload and the replica is not catching up fast enough, the lag can be much higher. 可以使用指标“副本滞后时间”跟踪每个副本的复制滞后时间。You can track the replication lag for each replica using the metric Replica Lag. 该指标显示的是自副本上的上次重放事务以来所经历的时间。This metric shows the time since the last replayed transaction at the replica. 建议观察一段时间的副本滞后时间,以便确定平均滞后时间。We recommend that you identify the average lag by observing the 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 will be notified to take action.

提示

如果故障转移到副本,则取消副本与主服务器之间的链接时的滞后时间会指示丢失了多少数据。If you failover to the replica, the lag at the time you delink the replica from the primary will indicate how much data is lost.

一旦决定要故障转移到某个副本,Once you have decided you want to failover to a replica,

  1. 请停止将数据复制到副本Stop replication to the replica
    若要使副本服务器成为独立服务器并且能够接受写入,必须执行此步骤。This step is necessary to make the replica server to become a standalone server and be able to accept writes. 在此过程中,副本服务器会重启,并且副本服务器与主服务器之间的链接会取消。As part of this process, the replica server will restart and be delinked from the primary. 启动停止复制操作后,后端进程通常需要几分钟的时间来应用尚未应用的所有残留日志,并将数据库作为可读写服务器打开。Once you initiate stop replication, the backend process typically takes few minutes to apply any residual logs that were not yet applied and to open the database as a read-writeable server. 请参阅本文的停止复制部分,了解此操作的潜在影响。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 connection string to point to the (former) replica instead of the primary.

如果应用程序成功处理了读取和写入操作,则表明故障转移已完成。Once your application is successfully processing reads and writes, you have 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 above.

灾难恢复Disaster recovery

当出现重大灾难事件(例如区域性故障)时,可以通过提升只读副本来执行灾难恢复操作。When there is a major disaster event such as regional failures, you can perform disaster recovery operation by promoting your read replica. 在 UI 门户中,可以导航到只读副本服务器。From the UI portal, you can navigate to the read replica server. 然后单击“复制”选项卡,并且可以停止副本以将其提升为独立服务器。Then click the replication tab, and you can stop the replica to promote it to be an independent server. 或者,你可以使用 Azure CLI 来停止和提升副本服务器。Alternatively, you can use the Azure CLI to stop and promote the replica server.

注意事项Considerations

本部分汇总了有关只读副本功能的注意事项。This section summarizes considerations about the read replica feature.

先决条件Prerequisites

只读副本和逻辑解码都依赖 Postgres 预写日志 (WAL) 来获取信息。Read replicas and logical decoding both depend on the Postgres write ahead log (WAL) for information. 这两个功能需要来自 Postgres 的不同级别的日志记录。These two features need different levels of logging from Postgres. 逻辑解码需要的日志记录的级别比只读副本需要的更高。Logical decoding needs a higher level of logging than read replicas.

若要配置正确的日志记录级别,请使用 Azure 复制支持参数。To configure the right level of logging, use the Azure replication support parameter. Azure 复制支持有三个设置选项:Azure replication support has three setting options:

  • 关闭 - 在 WAL 中包含最少的信息。Off - Puts the least information in the WAL. 大多数 Azure Database for PostgreSQL 服务器上都不提供此设置。This setting is not available on most Azure Database for PostgreSQL servers.
  • 副本 - 比“关闭”详细。Replica - More verbose than Off. 这是运行只读副本所需的最低日志记录级别。This is the minimum level of logging needed for read replicas to work. 此设置是大多数服务器上的默认设置。This setting is the default on most servers.
  • 逻辑 - 比“副本”详细。Logical - More verbose than Replica. 这是运行逻辑解码所需的最低日志记录级别。This is the minimum level of logging for logical decoding to work. 使用此设置时,只读副本也可以运行。Read replicas also work at this setting.

新副本New replicas

只读副本创建为新的 Azure Database for PostgreSQL 服务器。A read replica is created as a new Azure Database for PostgreSQL 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 compute and storage settings as the primary. 创建副本后,可以更改多个设置,包括存储和备份保留期。After a replica is created, several settings can be changed including storage and backup retention period.

创建副本时或之后,防火墙规则、虚拟网络规则和参数设置不会从主服务器继承到副本。Firewall rules, virtual network rules, and parameter settings are not inherited from the primary server to the replica when the replica is created or afterwards.

扩展Scaling

缩放 vCore 或者在“常规用途”和“内存优化”之间缩放:Scaling vCores or between General Purpose and Memory Optimized:

  • PostgreSQL 要求辅助服务器上的 max_connections 设置大于或等于主服务器上的设置,否则辅助服务器将不会启动。PostgreSQL requires the max_connections setting on a secondary server to be greater than or equal to the setting on the primary, otherwise the secondary will not start.
  • 在 Azure Database for PostgreSQL 中,所允许的每台服务器的最大连接数已固定到计算 sku,因为连接会占用内存。In Azure Database for PostgreSQL, the maximum allowed connections for each server is fixed to the compute sku since connections occupy memory. 可以详细了解 max_connections 与计算 sku 之间的映射You can learn more about the mapping between max_connections and compute skus.
  • 纵向扩展:先纵向扩展副本的计算,然后纵向扩展主服务器。Scaling up: First scale up a replica's compute, then scale up the primary. 此顺序可防止因违反 max_connections 要求而出现错误。This order will prevent errors from violating the max_connections requirement.
  • 纵向缩减:先纵向缩减主服务器的计算,然后纵向缩减副本。Scaling down: First scale down the primary's compute, then scale down the replica. 如果尝试将副本缩放至低于主服务器的级别,将会出现错误,因为这样会违反 max_connections 要求。If you try to scale the replica lower than the primary, there will be an error since this violates the max_connections requirement.

缩放存储:Scaling storage:

  • 所有副本都启用了存储自动增长,以防止存储空间已满的副本出现复制问题。All replicas have storage auto-grow enabled to prevent replication issues from a storage-full replica. 无法禁用此设置。This setting cannot be disabled.
  • 你也可以手动纵向扩展存储,就像在任何其他服务器上一样You can also manually scale up storage, as you would do on any other server

基本层Basic tier

基本层服务器仅支持相同区域复制。Basic tier servers only support same-region replication.

max_prepared_transactionsmax_prepared_transactions

PostgreSQL 要求只读副本上的 max_prepared_transactions 参数值大于或等于主服务器上的值,否则副本不会启动。PostgreSQL requires the value of the max_prepared_transactions parameter on the read replica to be greater than or equal to the primary value; otherwise, the replica won't start. 如果要更改主服务器上的 max_prepared_transactions,请先在副本上进行相应更改。If you want to change max_prepared_transactions on the primary, first change it on the replicas.

停止的副本Stopped replicas

如果停止主服务器与只读副本之间的复制,副本会重启以应用更改。If you stop replication between a primary server and a read replica, the replica restarts to apply the change. 已停止的副本将成为可接受读取和写入的独立服务器。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 primary and standalone servers

删除主服务器后,其所有只读副本将成为独立服务器。When a primary server is deleted, all of its read replicas become standalone servers. 副本将会重启以反映此项更改。The replicas are restarted to reflect this change.

后续步骤Next steps