你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用只读副本功能，可将数据从 Azure Database for PostgreSQL 灵活服务器实例复制到只读副本。 副本通过 PostgreSQL 引擎的本机物理复制技术以异步方式更新。 使用复制槽位的流复制是默认的操作模式。 必要时，使用基于文件的日志传送来进行跟进。 可将主服务器中的数据最多复制到 5 个副本。
副本是新的服务器，可以像管理普通的 Azure Database for PostgreSQL 灵活服务器实例一样对其进行管理。 每个只读副本按照预配计算资源的 vCore 数量以及每月 GB 存储量计费。
了解如何 创建读取副本。
何时使用只读副本
只读副本功能可帮助改善读取密集型工作负载的性能与规模。 “读取”工作负载可以隔离到副本，而“写入”工作负载可以定向到主服务器。 只读副本也可以部署在不同的区域，并且在需要灾难恢复时，可以提升为读写服务器。
一个典型应用场景是让 BI 和分析工作负载将只读副本用作报告的数据源。
由于副本是只读的，因此它们不能直接减少主服务器上的写入容量负担。
注意事项
只读副本主要针对卸载查询有益且可以接受轻微延迟的应用场景设计。 它们经过优化，可从主服务器为大多数工作负载提供准实时更新，使它们成为读操作密集型场景的绝佳解决方案。 但务必注意，它们不适用于需要最新数据准确度的同步复制方案。 虽然副本上的数据最终与主副本保持一致，但可能会存在通常从几秒钟到几分钟不等的延迟，在某些工作负载繁重或延迟较高的方案中，这可能会延长到数小时。 通常，与主服务器位于同一区域的只读副本的延迟比异地复制副本的延迟要小，因为后者常常会受到地理距离导致的延迟影响。 有关异地复制对性能造成的影响的更多见解，请参阅异地复制一文。 副本上的数据最终将与主服务器上的数据保持一致。 对于能够适应这种延迟的工作负荷，可以使用此功能。
注释
对于大多数工作负载，只读副本提供来自主服务器的准实时更新。 但是，对于持久的大量写入密集型主工作负载，复制滞后时间可能会持续增长，并且可能只能赶上主服务器。 这也可能会增加主服务器的存储用量，因为仅当副本上收到 WAL 文件时才会删除该文件。 如果这种情况持续存在，则可以在写入密集型工作负载后删除并重新创建只读副本，以使副本的滞后恢复到良好状态。 异步只读副本不适合这种繁重的写入工作负载。 评估应用程序的只读副本时，请监视整个应用工作负载周期中副本在其高峰和非高峰时间的滞后时间，以评估工作负载周期各个时间点上可能的滞后时间和预期的 RTO/RPO。
创建副本
可以在 支持该服务的任何区域中部署 Azure Database for PostgreSQL 灵活服务器实例的主服务器。 可以在同一区域或跨不同的全球 Azure 区域（有可用的 Azure Database for PostgreSQL）创建主服务器的副本。 创建副本的功能现在扩展到一些特殊的 Azure 区域。 有关可在其中创建副本的特殊区域的列表，请查看异地复制一文。
启动“创建副本”工作流时，将创建空白的 Azure Database for PostgreSQL 灵活服务器实例。 新服务器中填充了主服务器上的数据。 若要在同一区域中创建副本，请使用快照方法。 因此，创建时间与数据的大小无关。 异地副本是使用主实例的基础备份创建的，然后通过网络传输，因此创建时间可能从几分钟到几小时不等，具体取决于主实例的大小。
仅当满足以下两个条件时，副本才会被视为创建成功：主实例的整个备份必须复制到副本；事务日志必须同步且延迟不超过 1 GB。
为了成功完成创建操作，请避免在事务负载较高的时段创建副本。 例如，在从其他源迁移到 Azure Database for PostgreSQL 灵活服务器实例或在大容量加载作业期间，应避免生成副本。 如果你目前正在迁移数据或加载大量数据，最好先完成此任务。 完成后，便可以开始设置副本。 迁移或批量加载操作完成后，检查事务日志大小是否已恢复到其正常大小。 通常，事务日志大小应接近实例的 max_wal_size 服务器参数中定义的值。 可以使用已使用的事务日志存储指标跟踪事务日志存储占用情况，通过该指标可以了解事务日志使用的存储量。 通过监视此指标，可以确保事务日志大小在预期范围内，并且可以启动副本创建过程。
重要
目前，“常规用途”和“内存优化”服务器计算层级支持只读副本。 不支持可突发服务器计算层。
重要
执行副本创建、删除和提升操作时，主服务器将进入更新状态。 在此期间，服务器管理操作（如修改服务器参数、更改高可用性选项或者添加或删除防火墙）将不可用。 请务必注意，更新状态仅影响服务器管理操作，不会影响数据平面操作。 这意味着数据库服务器将保持完全正常运行，能够接受连接，并提供读取和写入流量。
了解如何创建只读副本。
配置管理
为 Azure Database for PostgreSQL 灵活服务器实例设置只读副本时，必须了解哪些服务器配置可以调整，哪些是从主服务器继承的，以及任何相关的限制。
继承的配置
创建只读副本时，该副本将从主服务器继承特定的服务器配置。 可以在副本创建期间或设置副本之后更改这些配置。 不过，某些特定设置（如地理备份）不会被复制到只读副本中。
副本创建期间的配置
- 层、存储大小：对于“提升到主服务器”操作，此配置必须与主服务器相同。 对于“提升到独立服务器并从复制中删除”操作，此配置可与主服务器相同或更高。
- 性能层 (IOPS)：可调整。
- 数据加密：可调整，包括从服务管理的密钥迁移到客户管理的密钥。
创建后的配置
- 防火墙规则：可以添加、删除或修改。
- 层、存储大小：对于“提升到主服务器”操作，此配置必须与主服务器相同。 对于“提升到独立服务器并从复制中删除”操作，此配置可与主服务器相同或更高。
- 性能层 (IOPS)：可调整。
- 身份验证方法：可调整，选项包括从 PostgreSQL 身份验证切换到 Microsoft Entra。
- 服务器参数：大部分参数都可调整。 但是，那些影响共享内存大小的参数应与主服务器保持一致，尤其是对于潜在的“提升到主服务器”方案。 对于“提升到独立服务器并从复制中删除”操作，这些参数应与主服务器上的参数相同或更高。
- 维护计划：可调整。
只读副本不支持的功能
某些功能仅限于主服务器，无法在只读副本上设置。 这些包括：
- 备份，包括异地备份。
- 高可用性 (HA)
如果源 Azure Database for PostgreSQL 灵活服务器实例使用客户管理的密钥加密，请参阅文档以了解其他注意事项。
创建级联只读副本（预览版）
级联只读副本有助于分发读取工作负载，从而减少主服务器上的负载。 在不同区域（跨区域读取副本）中部署读取副本有助于使读取流量更接近分布在不同地理位置的用户。 可以将级联只读副本添加到 Azure Database for PostgreSQL 灵活服务器实例中，此功能在公共预览容量中受支持。 这样，就可以在现有只读副本的基础上创建新的只读副本，现有只读副本则充当下一级别的源。
第一级只读副本从主服务器异步复制数据。 然后，可以将第一级副本作为源来创建二级只读副本，从而形成两层复制架构。 此体系结构可提高可伸缩性，支持主服务器最多支持 30 个只读副本服务器，最多允许 5 个只读副本，每个副本支持 5 个额外的副本。 若要将级联只读副本添加到 Azure Database for PostgreSQL 灵活服务器实例，请选择现有只读副本（从主服务器创建），然后导航到“复制”选项卡并单击“创建副本”。
例如，主服务器最多可以有 5 个只读副本（级别 1）。 其中一个副本（例如 read-replica-1）可以作为另一个副本 read-replica-2 的源，而 read-replica-2 会成为（级别 2）的一部分。
预览注意事项：
- 每个源只读副本最多可创建 5 个只读副本，且支持 2 个复制层级。
- 对于带有级联只读副本的中间只读副本，不支持执行提升操作。
- 级联副本不支持虚拟终结点。
- PostgreSQL 版本 14 及更高版本的中间副本支持级联只读副本。
- 此功能受支持：美国西部、西班牙中部、澳大利亚东部、美国中南部、英国西部、波兰中部、意大利北部、美国西部 2、美国东部 2、东亚和加拿大中部。
连接到副本
创建副本时，该副本会继承主服务器的防火墙规则或虚拟网络服务终结点。 这些规则可能会在副本创建期间以及将来的任何时间点发生更改。
副本从主服务器继承管理员帐户。 主服务器上的所有用户帐户将复制到只读副本。 只能使用主服务器上可用的用户帐户连接到只读副本。
可以通过两种方法连接到副本：
- 直接连接到副本实例：可使用主机名和有效的用户帐户连接到副本，就像在常规的 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 服务提供用于监视复制的以下指标。
可以使用增强指标来监视和提醒读取复制。
启用增强指标
- 默认情况下，大多数新指标处于“已禁用”状态。 不过，默认情况下会启用一些例外情况。 下表中最右侧的列指示默认情况下是否启用每个指标。
- 若要启用默认情况下未启用的指标，请将服务器参数
metrics.collector_database_activity设置为ON。 此参数是动态的，不需要重启实例。
逻辑复制
| 显示名称 | 指标 ID | 单位 | Description | 尺寸 | 默认启用 |
|---|---|---|---|---|---|
| 最大逻辑复制延迟 | logical_replication_delay_in_bytes |
字节 | 所有逻辑复制槽的最大滞后时间。 | 不适用 | 是的 |
重复
| 显示名称 | 指标 ID | 单位 | Description | 尺寸 | 默认启用 |
|---|---|---|---|---|---|
| 最大物理复制延迟 | physical_replication_delay_in_bytes |
字节 | 所有异步物理复制槽的最大滞后时间。 | 不适用 | 是的 |
| 读取副本延迟 | physical_replication_delay_in_seconds |
秒 | 只读副本滞后时间（秒）。 | 不适用 | 是的 |
要了解详细信息，请参阅只读副本操作说明文章。
物理复制最大滞后时间指标显示主服务器与滞后时间最长的副本之间的滞后时间（以字节为单位）。 此指标仅适用于主服务器，且仅当至少有一个只读副本已连接到主服务器时才可用。 当副本正在与主服务器同步时、在副本创建期间或当复制变为非活动状态时，也会显示滞后信息。
“只读副本滞后时间”指标显示的是自上次重放事务以来所经历的时间。 例如，如果主服务器上没有发生事务，且上一个事务在 5 秒前重播，则“只读副本滞后时间”会显示 5 秒的延迟。 此指标仅在副本上适用且可用。
请设置警报，以便在副本滞后时间达到工作负载不可接受的值时收到通知。
若要获取更多见解，请直接查询主服务器，以获取所有副本上的复制滞后时间。
注释
如果主服务器或只读副本重启，“副本滞后时间”指标中会反映重启以及跟上进度所花费的时间。
复制状态
若要监视复制和提升操作的进度与状态，请参考 Azure 门户中的“复制状态”列。 此列位于复制页面中，并且会显示各种状态，让你可以深入了解只读副本的当前状态及其与主服务器的连接情况。 对于依赖 Azure 资源管理器 API 的用户，在调用 GetReplica API 时，状态会在 replica 属性包中会显示为 ReplicationState。
可能的值有：
| 复制状态 | 说明 | 促进秩序 | 只读副本创建顺序 |
|---|---|---|---|
| 正在重新配置 | 正在等待副本与主服务器开始建立连接。 如果副本或其所在区域不可用（例如由于灾难），此状态可能会持续更长时间。 | 1 | N/A |
| 预配 | 正在预配只读副本，并且两台服务器之间的复制尚未开始。 在预配完成之前，无法连接到只读副本。 | N/A | 1 |
| 正在更新 | 在触发诸如提升或创建只读副本等操作后，正在准备服务器配置。 | 2 | 2 |
| 同步 | 正在副本上应用 WAL 文件。 在提升期间，此阶段的持续时间取决于所选的数据同步选项 - 计划或者强制。 | 3 | 3 |
| 活动 | 正常状态，表示只读副本已成功连接到主服务器。 如果服务器已停止但之前已成功连接，则状态将保持为活动。 | 4 | 4 |
| 中断 | 不正常状态，表示提升操作可能失败，或者副本由于某种原因无法连接到主服务器。 请删除副本并重新创建副本以解决此问题。 | N/A | N/A |
了解如何监视复制。
注意事项
本部分汇总了有关读取副本功能的注意事项。 请注意以下事项。
- 电源操作：电源操作（包括启动和停止操作）可以同时应用于主服务器和副本服务器。 但是，为了保持系统完整性，应遵循特定的顺序。 在停止只读副本之前，请务必先停止主服务器。 开始操作时，在启动主服务器之前，请在副本服务器上开始启动操作。
- 如果服务器具有只读副本，则应先删除只读副本，然后再删除主服务器。
- Azure Database for PostgreSQL 灵活服务器实例的就地重大版本升级需要删除服务器上启用的任何只读副本和级联的只读副本。 删除副本后，主服务器可以升级到所需的主版本。 升级完成后，可以重新创建副本以恢复复制过程。
- 重置管理员密码：当前不支持在副本服务器上重置管理员密码。 此外，也不支持在同一请求中同时更新管理员密码和推动副本操作。 如果要执行此操作，必须首先提升副本服务器，然后分别更新新升级的服务器上的密码。
新复制品
只读副本被创建为新的 Azure Database for PostgreSQL 灵活服务器实例。 无法将现有的服务器设为副本。 无法创建另一个只读副本的副本，即不支持级联复制。
资源移动
用户可以在与主服务器不同的资源组中创建只读副本。 但是，不支持在创建只读副本后将其移动到另一个资源组。 此外，不支持将副本移动到不同的订阅，也不支持将具有只读副本的主服务器移动到另一个资源组或订阅。
存储自动增长
在为 Azure Database for PostgreSQL 灵活服务器实例配置只读副本时，必须确保副本上的存储自动增长设置与主服务器上的设置匹配。 存储自动增长功能允许数据库存储自动增加，以防止空间不足导致数据库服务中断。 下面介绍如何有效管理存储自动增长设置：
- 无论主服务器的设置如何，都可以在任何副本上启用存储自动增长。
- 如果在主服务器上启用了存储自动增长，则还必须在副本服务器上启用它，以确保存储扩展行为的一致性。
- 要在主服务器上启用存储自动增长，必须先在副本上启用它。 这种操作顺序对于维护复制完整性至关重要。
- 相反，如果你希望禁用存储自动增长，请首先在主服务器上禁用它，然后再在副本上禁用它，以避免复制复杂化。
备份和还原
管理 Azure Database for PostgreSQL 灵活服务器实例的备份和还原时，必须记住服务器在不同提升方案中的当前角色和先前角色。 以下是需要记住的要点：
提升到主服务器
不从只读副本创建备份：永远不会从只读副本服务器中创建备份，无论该服务器过去的角色如何。
保留过去的备份：如果服务器曾经是主服务器并且在此期间创建了备份，则会保留这些备份。 它们将一直保留到用户定义的保留期结束。
还原操作限制：即使已转换为只读副本的服务器存在过去的备份，还原操作也会受到限制。 只有在服务器提升回主服务器角色后，才能启动还原操作。
为了澄清起见，下表说明了这些要点：
| 服务器角色 | 已创建备份 | 允许还原 |
|---|---|---|
| 主要 | 是的 | 是的 |
| 只读副本 | 否 | 否 |
| 提升为只读副本的主服务器 | 是的 | 是的 |
提升为独立服务器并从复制中移除
当服务器是只读副本时，不会进行备份。 但是，一旦将其提升为独立服务器，提升后的服务器和主服务器都会进行备份，并且两者都允许还原操作。
网络
只读副本支持 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。 为了确保只读副本的恢复是无缝的并且不会遇到共享内存限制，这些特定参数应始终设置为等于或大于主服务器上配置的值。
Scale
可以随意纵向扩展和缩减计算 (vCore)，将服务层级从“常规用途”更改为“内存优化”（反之亦然），以及纵向扩展存储，但请注意以下事项。
对于计算缩放：
Azure Database for PostgreSQL 服务要求副本上的多个参数 大于或等于主副本上的设置 ，以确保副本在恢复期间不会耗尽共享内存。 受影响的参数为：
max_connections、max_prepared_transactions、max_locks_per_transaction、max_wal_senders、max_worker_processes。扩容：先扩容副本的计算资源，然后扩容主节点。
纵向缩减：先纵向缩减主服务器的计算，然后纵向缩减副本。
主服务器上的计算必须始终等于或小于最小副本上的计算。
对于存储缩放：
纵向扩展：先扩展副本的存储容量，然后扩展主节点。
主服务器上的存储大小必须始终等于或小于最小副本上的存储大小。