Share via

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Database for PostgreSQL 灵活服务器中的只读副本

  • 项目

适用于：Azure Database for PostgreSQL 灵活服务器

使用只读副本功能，可将数据从 Azure Database for PostgreSQL 灵活服务器实例复制到只读副本。 副本通过 PostgreSQL 引擎的本机物理复制技术以异步方式更新。 使用复制槽位的流复制是默认的操作模式。 必要时，使用基于文件的日志传送来进行跟进。 可将主服务器中的数据最多复制到 5 个副本。

副本是新的服务器，可以像管理普通的 Azure Database for PostgreSQL 灵活服务器实例一样对其进行管理。 每个只读副本按照预配计算资源的 vCore 数量以及每月 GB 存储量计费。

了解如何创建和管理副本。

何时使用只读副本

只读副本功能可帮助改善读取密集型工作负荷的性能与规模。 “读取”工作负载可以隔离到副本，而“写入”工作负载可以定向到主服务器。 只读副本也可以部署在不同的区域，在发生灾难恢复时，可以将其提升为读-写服务器。

一个典型方案是让 BI 和分析工作负载将只读副本用作报告的数据源。

由于副本是只读的，因此它们不能直接减少主服务器上的写入容量负担。

注意事项

只读副本主要用于卸载查询非常有用，并且可管理轻微延迟的方案。 它们经过优化，可从主实例为大多数工作负载提供准实时更新，使它们成为读取密集型场景的绝佳解决方案。 但务必注意，它们不适用于需要最新数据准确度的同步复制方案。 虽然副本上的数据最终与主副本保持一致，但可能会存在通常从几秒钟到几分钟不等的延迟，在某些工作负载繁重或延迟较高的方案中，这可能会延长到数小时。 通常，与主副本位于同一区域的只读副本的延迟小于异地副本，因为后者通常会处理地理距离造成的延迟。 有关异地复制对性能造成的影响的更多见解，请参阅异地复制一文。 副本上的数据最终将与主服务器上的数据保持一致。 对于能够适应这种延迟的工作负荷，可以使用此功能。

注意

对于大多数工作负荷，只读副本提供来自主服务器的准实时更新。 但是，对于持久的大量写入密集型主工作负载，复制滞后时间可能会持续增长，并且只能赶上主服务器。 这还可能会增加主服务器的存储使用量，因为仅当在副本上收到 WAL 文件后，才会删除这些文件。 如果这种情况持续存在，可以选择在写入密集型工作负载完成后删除并重新创建只读副本，使副本恢复到相对于滞后的良好状态。 异步只读副本不适合这种繁重的写入工作负荷。 评估应用程序的只读副本时，请在完整的应用工作负载周期通过其高峰时间和非高峰时间监视副本上的滞后时间，以评估工作负载周期各个点可能的滞后时间和预期的 RTO/RPO。

创建副本

Azure Database for PostgreSQL 灵活服务器的主服务器可以部署在支持该服务的任何区域。 可以在同一区域中创建主服务器的副本，也可以在提供 Azure Database for PostgreSQL 灵活服务器的全球不同 Azure 区域中创建主服务器的副本。 创建副本的功能现在扩展到一些特殊的 Azure 区域。 有关可在其中创建副本的特殊区域的列表，请查看异地复制一文。

启动“创建副本”工作流时，将创建空白的 Azure Database for PostgreSQL 灵活服务器实例。 新服务器中填充了主服务器上的数据。 若要在同一区域中创建副本，请使用快照方法。 因此，创建时间与数据的大小无关。 异地副本是使用主实例的基础备份创建的，然后通过网络传输，因此创建时间可能从几分钟到几小时不等，具体取决于主实例的大小。

仅当满足以下两个条件时，副本才会被视为创建成功：主实例的整个备份必须复制到副本；事务日志必须同步且延迟不超过 1 GB。

为了成功完成创建操作，请避免在事务负载较高的时段创建副本。 例如，从其他源迁移到 Azure Database for PostgreSQL 灵活服务器时或在大容量加载操作期间，应避免创建副本。 如果你目前正在迁移数据或加载大量数据，最好先完成此任务。 完成后，便可以开始设置副本。 迁移或批量加载操作完成后，检查事务日志大小是否已恢复到其正常大小。 通常，事务日志大小应接近实例的 max_wal_size 服务器参数中定义的值。 可以使用已使用的事务日志存储指标跟踪事务日志存储占用情况，通过该指标可以了解事务日志使用的存储量。 通过监视此指标，可以确保事务日志大小在预期范围内，并且可以启动副本创建过程。

重要

目前，“常规用途”和“内存优化”服务器计算层支持只读副本。 不支持“可突发”服务器计算层。

重要

执行副本创建、删除和提升操作时，主服务器将进入更新状态。 在此期间，服务器管理操作（如修改服务器参数、更改高可用性选项或者添加或删除防火墙）将不可用。 请务必注意，更新状态仅影响服务器管理操作，不会影响数据平面操作。 这意味着数据库服务器将保持完全正常运行，能够接受连接，并提供读取和写入流量。

了解如何在 Azure 门户中创建只读副本。

配置管理

为 Azure Database for PostgreSQL 灵活服务器设置只读副本时，必须了解可调整的服务器配置，从主服务器继承的服务器配置以及任何相关限制。

继承的配置

创建只读副本时，该副本将从主服务器继承特定的服务器配置。 可以在副本创建期间或设置副本之后更改这些配置。 但是，特定的设置（例如异地备份）不会复制到只读副本。

副本创建期间的配置

  • 层、存储大小：对于“提升到主服务器”操作，此配置必须与主服务器相同。 对于“提升到独立服务器并从复制中删除”操作，此配置可与主服务器相同或更高。
  • 性能层 (IOPS)：可调整。
  • 数据加密：可调整，包括从服务管理的密钥迁移到客户管理的密钥。

创建后的配置

  • 防火墙规则：可以添加、删除或修改。
  • 层、存储大小：对于“提升到主服务器”操作，此配置必须与主服务器相同。 对于“提升到独立服务器并从复制中删除”操作，此配置可与主服务器相同或更高。
  • 性能层 (IOPS)：可调整。
  • 身份验证方法：可调整，选项包括从 PostgreSQL 身份验证切换到 Microsoft Entra。
  • 服务器参数：大部分参数都可调整。 但是，那些影响共享内存大小的参数应与主服务器保持一致，尤其是对于潜在的“提升到主服务器”方案。 对于“提升到独立服务器并从复制中删除”操作，这些参数应与主服务器上的参数相同或更高。
  • 维护计划：可调整。

只读副本上不支持的功能

某些功能仅限于主服务器，无法在只读副本上设置。 这些设置包括：

  • 备份，包括异地备份。
  • 高可用性 (HA)

如果源 Azure Database for PostgreSQL 灵活服务器实例使用客户管理的密钥加密，请参阅文档以了解其他注意事项。

连接到副本

创建副本时，该副本不会继承主服务器的防火墙规则或虚拟网络服务终结点。 这些规则可能会在副本创建期间以及将来的任何时间点发生更改。

副本从主服务器继承管理员帐户。 主服务器上的所有用户帐户将复制到只读副本。 只能使用主服务器上可用的用户帐户连接到只读副本。

可以通过两种方法连接到副本：

  • 直接连接到副本实例：可使用主机名和有效的用户帐户连接到副本，就像在常规的 Azure Database for PostgreSQL 灵活服务器实例上连接一样。 对于名称为 myreplica、管理员用户名为 myadmin 的服务器，可以使用 psql 连接到副本：
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

在提示符下，输入用户帐户的密码。

此外，为了简化连接过程，Azure 门户提供了可直接使用的连接字符串。 可以在“连接”页中找到这些连接字符串。 它们包含 libpq 变量以及为 bash 控制台自定义的连接字符串。

  • 通过虚拟终结点连接：还有一种使用虚拟终结点的替代连接方法，如虚拟终结点一文中所述。 使用虚拟终结点可以将只读终结点配置为始终指向副本，而不管哪个服务器当前拥有副本角色。

监视复制

Azure Database for PostgreSQL 灵活服务器中的只读副本功能依赖于复制槽机制。 复制槽位的主要优势在于，它们可以自动调整所有副本服务器所需的事务日志（WAL 段）的数量。 这有助于防止副本不同步，因为它可确保在将主副本上的 WAL 段发送到副本之后才将其删除。 该方法的缺点是，如果复制槽长时间保持不活动状态，则可能会出现主服务器空间不足的风险。 在这种情况下，主服务器会累积 WAL 文件，导致存储使用量出现递增增长。 当存储使用率达到 95% 或可用容量小于 5 GiB 时，服务器会自动切换为只读模式，目的是避免因磁盘已满而发生的错误。
因此，监视复制延迟和复制槽状态对于只读副本至关重要。

建议为已用存储或存储百分比以及复制延迟设置警报规则，以便在其超过特定阈值时主动操作来增加存储大小并删除出现延迟的只读副本。 例如，可设置当存储使用百分比超过 80%，或者副本延迟超过 5 分钟时发出警报。 已用的事务日志存储空间指标将显示 WAL 文件累积是否是存储空间使用过多的主要原因。

Azure Database for PostgreSQL 灵活服务器提供了两个用于监视复制的指标。 这两个指标是“物理复制最大滞后时间”和“只读副本滞后时间”。 若要了解如何查看这些指标，请参阅只读副本操作指南文章的“监视副本”部分。

“物理复制最大滞后时间”指标显示主服务器与滞后时间最长的副本之间的滞后时间（以字节为单位）。 此指标仅在主服务器上适用并可用，且仅当至少有一个只读副本已连接到主服务器时才可用。 当副本正在追赶主服务器时、在创建副本期间或者当复制变得不活动时，也会显示滞后时间信息。

“只读副本滞后时间”指标显示自上次重放事务以来所经历的时间。 例如，如果主服务器上没有事务发生，并且最后一个事务是在 5 秒前重放的，则只读副本滞后时间将显示 5 秒的延迟。 此指标仅在副本上适用且可用。

请设置警报，以便在副本滞后时间达到工作负载不可接受的值时收到通知。

若要获取更多见解，请直接查询主服务器，以获取所有副本上的复制滞后时间。

注意

如果主服务器或只读副本重启，“副本滞后时间”指标中会反映重启以及跟上进度所花费的时间。

复制状态

若要监视复制和提升操作的进度与状态，请参考 Azure 门户中的“复制状态”列。 此列位于复制页中，它会显示各种状态，让你深入了解只读副本的当前状况及其与主服务器的链接。 对于依赖 Azure 资源管理器 API 的用户，在调用 GetReplica API 时，状态会在 replica 属性包中会显示为 ReplicationState。

可能的值有：

复制状态 描述 提升顺序 只读副本创建顺序
正在重新配置 正在等待副本与主服务器之间开始建立链接。 如果副本或其所在区域不可用（例如发生灾难），建立链接所需的时间可能更长。 1 不可用
预配 此时正在预配只读副本，并且两个服务器之间的复制尚未开始。 在预配完成之前，无法连接到只读副本。 不可用 1
正在更新 在完成触发的操作（例如提升或只读副本创建）之后，正在准备服务器配置。 2 2
同步 正在副本上应用 WAL 文件。 在提升期间，此阶段的持续时间取决于所选的数据同步选项 - 计划或者强制。 3 3
活动 正常状态，表示只读副本已成功连接到主服务器。 如果服务器已停止但之前已成功连接，则状态将保持为活动。 4 4
中断 不正常状态，表示提升操作可能失败，或者副本由于某种原因无法连接到主服务器。 请删除副本并重新创建副本以解决此问题。 空值 空值

了解如何监视复制。

注意事项

本部分汇总了有关只读副本功能的注意事项。 请注意以下事项。

  • 电源操作：电源操作（包括启动和停止操作）可以同时应用于主服务器和副本服务器。 但是，为了保持系统完整性，应遵循特定的顺序。 在停止只读副本之前，请确保先停止主服务器。 开始操作时，在启动主服务器之前，请在副本服务器上开始启动操作。
  • 如果服务器具有只读副本，则应先删除只读副本，然后再删除主服务器。
  • Azure Database for PostgreSQL 灵活服务器中的就地主版本升级需要删除服务器上当前启用的所有只读副本。 删除副本后，主服务器可以升级到所需的主版本。 升级完成后，可以重新创建副本以恢复复制过程。
  • 高级 SSD v2：从当前版本开始，如果主服务器将高级 SSD v2 用于存储，则不支持创建只读副本。
  • 重置管理员密码：当前不支持在副本服务器上重置管理员密码。 此外，也不支持在同一请求中随提升副本操作更新管理员密码。 如果要执行此操作，必须首先提升副本服务器，然后分别更新新升级的服务器上的密码。

新副本

只读副本被创建为新的 Azure Database for PostgreSQL 灵活服务器实例。 无法将现有的服务器设为副本。 无法创建另一个只读副本的副本，即不支持级联复制。

资源移动

用户可以在与主服务器不同的资源组中创建只读副本。 但是，不支持在创建只读副本后将其移动到另一个资源组。 此外，不支持将副本移动到不同的订阅，也不支持将包含只读副本的主服务器移动到另一个资源组或订阅。

存储自动增长

为 Azure Database for PostgreSQL 灵活服务器实例配置只读副本时，必须确保副本上的存储自动增长设置与主服务器的设置匹配。 存储自动增长功能允许数据库存储自动增加，以防止空间不足导致数据库服务中断。 下面介绍如何有效管理存储自动增长设置：

  • 无论主服务器的设置如何，都可以在任何副本上启用存储自动增长。
  • 如果在主服务器上启用了存储自动增长，则还必须在副本服务器上启用它，以确保存储扩展行为的一致性。
  • 要在主副本上启用存储自动增长，必须先在副本上启用它。 这种操作顺序对于维护复制完整性至关重要。
  • 相反，如果你希望禁用存储自动增长，请首先在主服务器上禁用它，然后再在副本上禁用它，以避免复制复杂化。

备份和还原

管理 Azure Database for PostgreSQL 灵活服务器实例的备份和还原时，必须记住服务器在不同提升方案中的当前角色和先前角色。 以下是需要记住的要点：

提升到主服务器

  1. 不从只读副本创建备份：永远不会从只读副本服务器中创建备份，无论该服务器过去的角色如何。

  2. 保留过去的备份：如果服务器曾经是主服务器并且在此期间创建了备份，则会保留这些备份。 它们将一直保留到用户定义的保留期结束。

  3. 还原操作限制：即使已转换为只读副本的服务器存在过去的备份，还原操作也会受到限制。 仅当服务器已提升回到主要角色时，才能启动还原操作。

为了澄清起见，下表说明了这些要点：

服务器角色 已创建备份 允许还原
主要 是 是
只读副本 否 否
提升到主服务器的只读副本 是 是

提升到独立服务器并从复制中删除

虽然服务器是只读副本，但不会创建任何备份。 但是，在提升到独立服务器后，提升的服务器和主服务器都将创建备份，并且两者都允许还原操作。

网络

只读副本支持 Azure Database for PostgreSQL 灵活服务器支持的所有网络选项。

重要

主服务器和只读副本之间的双向通信对于 Azure Database for PostgreSQL 灵活服务器设置至关重要。 必须规定如何在 Azure 虚拟网络子网中通过目标端口 5432 发送和接收流量。

上述要求不仅有利于同步过程，而且还能确保提升机制的正常运行，其中副本可能需要以相反的顺序通信（从副本到主服务器），尤其是在执行“提升到主服务器”操作期间。 此外，必须允许连接到存储预写日志 (WAL) 存档的 Azure 存储帐户，以维护数据持久性并实现高效的恢复过程。

若要详细了解如何为只读副本配置专用访问（虚拟网络集成）以及了解专用网络上下文中跨 Azure 区域和虚拟网络复制的影响，请参阅使用专用网络跨 Azure 区域和虚拟网络进行复制页。

复制槽问题缓解

在极少数情况下，由于 WAL 文件累积，复制槽引起的高延迟可能会导致主服务器上的存储使用量增加。 如果存储使用率达到 95% 或可用容量低于 5 GiB，则服务器会自动切换到只读模式，以防止出现磁盘已满错误。

由于维护主服务器的运行状况和功能是首要任务，因此在此类边缘情况下，可能会丢弃复制槽，以确保主服务器在读取和写入流量方面保持正常运行。 因此，复制将切换到基于文件的日志传送模式，这可能会导致更高的复制延迟。

必须密切监视存储使用情况和复制延迟，并采取必要措施在升级之前缓解潜在问题。

服务器参数

创建只读副本后，它将从主服务器继承服务器参数。 这是为了确保一致而可靠的起点。 但是，在创建只读副本后对主服务器上的服务器参数所做的任何更改都不会自动复制。 此行为提供对只读副本进行单独优化的优势，例如在不修改主服务器参数的情况下，增强其读取密集型操作的性能。 虽然这提供了灵活性和自定义选项，但当需要服务器参数的一致性时，还需要谨慎和手动管理，以保持主服务器参数与其副本之间的一致性。

管理员可以更改只读副本服务器上的服务器参数，并设置与主服务器中的值不同的值。 唯一的例外是可能影响副本恢复的参数，以下“缩放”部分也提到了这些参数：max_connections、max_prepared_transactions、max_locks_per_transaction、max_wal_senders、max_worker_processes。 为了确保只读副本的恢复是无缝的并且不会遇到共享内存限制，这些特定参数应始终设置为等于或大于主服务器上配置的值。

缩放

可以随意纵向扩展和缩减计算 (vCore)，将服务层级从“常规用途”更改为“内存优化”（反之亦然），以及纵向扩展存储，但请注意以下事项。

对于计算缩放：

  • Azure Database for PostgreSQL 灵活服务器要求副本上的多个参数大于或等于主服务器上的设置，以确保副本在恢复期间不会耗尽共享内存。 受影响的参数为：max_connections、max_prepared_transactions、max_locks_per_transaction、max_wal_senders、max_worker_processes。

  • 纵向扩展：先纵向扩展副本的计算，然后纵向扩展主服务器。

  • 纵向缩减：先纵向缩减主服务器的计算，然后纵向缩减副本。

  • 主服务器上的计算必须始终等于或小于最小副本上的计算。

对于存储缩放：

  • 纵向扩展：先纵向扩展副本的存储，然后纵向扩展主服务器。

  • 主服务器上的存储大小必须始终等于或小于最小副本上的存储大小。

相关内容