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

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

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

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

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

何时使用只读副本

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

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

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

注意事项

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

异地复制

可以在主服务器所在的同一区域和不同区域中创建只读副本。 跨区域复制对于灾难恢复规划或使数据更接近用户等方案非常有用。

你可以在任何 Azure Database for PostgreSQL 灵活服务器区域中拥有主服务器。 主服务器还可以在支持 Azure Database for PostgreSQL 的任何 Azure 区域中拥有副本。

将配对区域用于灾难恢复目的

虽然可以在任何受支持的区域中创建副本，但在配对区域中选择副本可以带来明显的好处，尤其是出于灾难恢复目的设计体系结构时：

• 区域恢复顺序：整个地理区域发生服务中断中，将优先恢复每个配对集中的一个区域，以确保跨配对区域的应用程序始终有一个区域可供快速恢复。

• 按顺序更新：配对区域的更新按时间顺序交错进行，从而最大程度地降低更新相关问题导致停机的风险。

• 物理隔离：配对区域中的不同数据中心至少保持 300 英里的距离，从而降低因重大事件而同时出现服务中断的风险。

• 数据驻留：配对集中的区域驻留在同一地理位置（只有少数例外情况），可满足数据驻留要求。

• 性能：虽然配对区域通常提供较低的网络延迟，从而增强数据易访问性和用户体验，但它们不一定是延迟绝对最低的区域。 如果主要目标是为更靠近用户的数据提供服务而不是优先考虑灾难恢复，则评估所有可用性区域的延迟至关重要。 在某些情况下，非配对区域的延迟可能是最低的。

若要更深入地了解配对区域的优势，请参阅 Azure 有关跨区域复制的文档。

创建副本

Azure Database for PostgreSQL 灵活服务器的主服务器可以部署在支持该服务的任何区域。 你可以在同一区域或不同 Azure 区域（可使用 Azure Database for PostgreSQL 灵活服务器）中创建主服务器的副本。

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

在 Azure Database for PostgreSQL 灵活服务器中，仅当主实例的整个备份复制到副本目标并且事务日志同步达到最大 1GB 延迟阈值时，副本的创建操作才会被视为成功。

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

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

配置管理

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

继承的配置

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

副本创建期间的配置

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

创建后的配置

• 防火墙规则：可以添加、删除或修改。
• 层，存储大小：它可以与主服务器相同或比之更高。
• 身份验证方法：可调整，选项包括从 PostgreSQL 身份验证切换到 Microsoft Entra。
• 服务器参数：大部分参数都可调整。 这些参数应相同或超过主服务器中的参数。
• 维护计划：可调整。

只读副本上不支持的功能

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

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

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

连接到副本

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

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

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

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

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

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

提升副本

“提升”是指命令副本结束其副本模式并转换为完全读写操作的过程。

下图演示了提升前的服务器配置以及成功完成“提升到独立服务器”操作后的最终状态。

需要考虑很多选项。

• 计划：此选项可确保在提升之前同步数据。 它在接受客户端连接之前应用所有待处理的日志以确保数据一致性。

• 强制：此选项可以在发生区域服务中断等情况时实现快速恢复。 一旦服务器处理了实现最接近的一致状态所需的 WAL 文件，服务器就可以开始运行，而无需等待同步主服务器中的所有数据。 如果使用此选项提升副本，则取消副本与主服务器之间的链接时的滞后时间会指示丢失了多少数据。

了解如何提升为独立服务器并从副本中删除。

配置管理

就控制平面配置而言，只读副本被视为单独的服务器。 这为读取扩展方案提供了灵活性。 但是，在使用副本进行灾难恢复时，用户必须确保配置符合需要。

提升操作不会继承特定的配置和参数。 下面是一些值得注意的事项：

• PgBouncer：在提升过程中不会复制内置 PgBouncer 连接池的设置和状态。 如果在主服务器上启用了 PgBouncer，但未在副本上启用，则提升后它将在副本上保持禁用状态。 如果你希望在新提升的服务器上使用 PgBouncer，则必须在执行提升操作之前或之后启用它。
• 异地冗余备份存储：不会转移异地备份设置。 由于无法为副本启用异地备份，因此提升的主服务器（先前为副本）不会在提升后启用异地备份。 该功能只能在标准服务器创建时激活（而非副本）。
• 服务器参数：如果这些参数的值在主服务器和只读副本上不同，则在提升期间它们不会更改。 必须注意的是，影响共享内存大小的参数在主服务器和副本上必须具有相同的值。 服务器参数部分详细说明了此要求。
• Microsoft Entra 身份验证：如果为主服务器配置了 Microsoft Entra 身份验证，但为副本设置了 PostgreSQL 身份验证，则提升后，副本不会自动切换到 Microsoft Entra 身份验证。 它将保留 PostgreSQL 身份验证。 用户需要在提升过程之前或之后在提升的副本上手动配置 Microsoft Entra 身份验证。
• 高可用性 (HA)：如果在提升后需要 HA，则必须在角色反转后在新提升的主服务器上进行配置。

监视复制

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

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

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

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

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

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

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

复制状态

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

可能的值有：

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

了解如何监视复制。

区域故障和恢复

各个区域的 Azure 设施都采用高可靠设计。 但是，在极少数情况下，由于网络故障或自然灾害等严重情况，可能无法访问整个区域。 Azure 的功能允许创建分布在多个区域的应用程序，以确保一个区域发生的故障不会影响其他区域。

为区域灾难做好准备

为潜在的区域灾难做好准备对于确保应用程序和服务的不间断运行至关重要。 如果考虑为 Azure Database for PostgreSQL 灵活服务器实例制定可靠的应变计划，以下是关键步骤和注意事项：

1. 建立异地复制只读副本：必须在与主服务器不同的区域中设置只读副本。 这可以确保主要区域出现服务中断时保持业务连续性。 有关更多详细信息，请参阅异地复制部分。
2. 配置只读副本：并非主服务器中的所有设置都会复制到只读副本。 必须确保在只读副本上正确设置全部所需的配置和功能（例如 PgBouncer）。 有关详细信息，请参阅配置管理部分。
3. 为高可用性 (HA) 做好准备：如果你的设置需要高可用性，请注意不会在提升的副本上自动启用此功能。 请准备好在提升后激活它。 考虑自动执行此步骤以最大程度地减少停机时间。
4. 定期测试：定期模拟区域灾难场景以验证现有的阈值、目标和配置。 确保应用程序在这些测试场景中按预期做出响应。
5. 遵循 Azure 的一般指南：Azure 提供了有关可靠性和灾难准备的综合指导。 查阅这些资源并将最佳做法整合到准备计划中会很有帮助。

主动提前为区域灾难做好准备可确保应用程序和数据的复原能力和可靠性。

当服务中断影响了 SLA 时

如果特定区域中的 Azure Database for PostgreSQL 灵活服务器出现长时间中断，威胁到应用程序的服务级别协议 (SLA)，请注意，下面讨论的两个操作都不是服务驱动的。 这两个操作都需要用户干预。 最佳做法是尽可能自动执行整个过程并采取可靠的监视方案。 若要详细了解服务中断期间会提供哪些信息，请参阅服务中断页。 在发生区域故障时，只能进行强制提升，这意味着数据丢失量大致等同于副本和主服务器之间的当前滞后时间。 因此，监视滞后时间至关重要。 考虑以下步骤：

假设服务器不满足服务器对称性要求（例如，异地副本的层比主服务器更高或存储空间更多）。 在这种情况下，这是唯一可行的选项。 提升服务器后，需要更新应用程序的连接字符串。 原始区域还原后，旧的主服务器可能再次变为活动状态。 请确保将其删除，以避免产生不必要的费用。 如果你希望保留以前的拓扑，请重新创建只读副本。

注意事项

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

• 电源操作：电源操作（包括启动和停止操作）可以同时应用于主服务器和副本服务器。 但是，为了保持系统完整性，应遵循特定的顺序。 在停止只读副本之前，请确保先停止主服务器。 开始操作时，在启动主服务器之前，请在副本服务器上开始启动操作。
• 如果服务器具有只读副本，则应先删除只读副本，然后再删除主服务器。
• Azure Database for PostgreSQL 灵活服务器中的就地主版本升级需要删除服务器上当前启用的所有只读副本。 删除副本后，主服务器可以升级到所需的主版本。 升级完成后，可以重新创建副本以恢复复制过程。

新副本

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

资源移动

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

升级

提升部分介绍了提升期间的不可用服务器状态。

提升期间的不可用服务器状态

在“计划”提升方案中，如果主服务器或副本服务器状态不是“可用”（例如“正在更新”或“正在重启”），则会出现错误。 但使用“强制”方法时，无论主服务器当前状态如何，都会继续提升，以快速解决潜在的区域灾难。 必须注意的是，如果在此过程中先前的主服务器转换为不可恢复状态，则唯一的解决方法就是重新创建副本。

在非配对区域中提升期间多个副本的可见性

在处理多个副本时，如果主要区域缺少配对的区域，则必须考虑一些特殊因素。 如果发生影响主服务器的区域服务中断，新提升的副本将不会自动识别任何附加副本。 虽然应用程序仍可以定向到提升的副本以继续操作，但无法识别的副本在服务中断期间将保持断开连接状态。 仅当原始主要区域还原后，这些附加副本才会重新关联并恢复其角色。

备份和还原

管理 Azure Database for PostgreSQL 灵活服务器实例的备份和还原时，请务必记住服务器当前和以前的角色。 以下是需要记住的要点：

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

网络

只读副本支持通过虚拟网络集成进行专用访问，以及通过允许的 IP 地址进行公共访问。

上述要求不仅有助于同步过程，而且可确保升级机制正常运行。 此外，必须允许连接到存储预写日志 (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。

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

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

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

对于存储缩放：

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

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

相关内容

• 在 Azure 门户中创建和管理只读副本
• 使用虚拟网络跨区域复制