提升 Azure Database for PostgreSQL 灵活服务器中的只读副本
适用于：
Azure Database for PostgreSQL 灵活服务器
“提升”是指命令副本结束其副本模式并转换为完全读写操作的过程。
重要
提升操作不是自动化的。 当主服务器发生故障时，系统不会独立切换到只读副本。 提升操作始终需要用户操作。
可以采用两种不同的方式提升副本：
提升到主服务器
此操作将副本提升为主服务器的角色。 在此过程中，当前主服务器将降级为副本角色，两者的角色将会交换。 若要成功提升，必须为当前主服务器配置一个虚拟终结点作为写入方终结点，并将要提升到的副本配置为读取方终结点。 仅当目标副本包含在读取方终结点配置中时，提升才会成功。
下图演示了提升之前的服务器配置以及提升操作成功完成后的最终状态。
提升到独立服务器并从复制中删除
选择此选项时，副本将提升成为独立服务器并从复制过程中移除。 因此，主服务器和提升后的服务器都将充当两个独立的读写服务器。 应该注意的是，虽然可以配置虚拟终结点，但它们并不是此操作所必需的。 新提升的服务器将不再是任何现有虚拟终结点的一部分，即使读取方终结点之前指向该服务器。 因此，如果应用程序要连接到新提升的副本，则必须更新应用程序的连接字符串以定向到该副本。
此图显示了服务器提升之前的设置以及在成功成为独立服务器之后的配置。
重要
“提升到独立服务器并从复制中删除”操作与以前的提升功能后向兼容。
重要
服务器对称性：若要使用“提升到主服务器”操作成功完成提升，主服务器和副本服务器必须具有相同的层和存储大小。 例如，如果主服务器有 2 个 vCore，而副本服务器有 4 个 vCore，则唯一可行的选项是使用“提升到独立服务器并从复制中删除”操作。 此外，两者的用于分配共享内存的服务器参数值必须相同。
对于这两种提升方法，还可以考虑其他选项：
计划：此选项可确保在提升之前同步数据。 它在接受客户端连接之前应用所有待处理的日志以确保数据一致性。
强制：此选项可以在发生区域服务中断等情况时实现快速恢复。 一旦服务器处理了实现最接近的一致状态所需的 WAL 文件，服务器就可以开始运行，而无需等待同步主服务器中的所有数据。 如果使用此选项提升副本，则取消副本与主服务器之间的链接时的滞后时间会指示丢失了多少数据。
重要
“强制”提升选项专门用于解决区域性中断问题，在这种情况下，它会跳过所有检查（包括服务器对称要求）并继续提升。 这是因为它优先考虑服务器的即时可用性以处理灾难场景。 但是，如果不满足文档中指定的对只读副本的要求，特别是服务器对称性要求，则不允许对区域性中断之外的场景使用强制选项，因为这可能会导致复制中断等问题。
了解如何将副本提升到主服务器和提升到独立服务器并从复制中删除。
配置管理
就控制平面配置而言，只读副本被视为单独的服务器。 此方法为读取扩展方案提供了灵活性。 但是，在使用副本进行灾难恢复时，用户必须确保配置符合需要。
提升操作不会继承特定的配置和参数。 下面是一些值得注意的事项：
- PgBouncer：在提升过程中不会复制内置 PgBouncer 连接池的设置和状态。 如果在主服务器上启用了 PgBouncer，但未在副本上启用，则提升后它将在副本上保持禁用状态。 如果你希望在新提升的服务器上使用 PgBouncer，则必须在执行提升操作之前或之后启用它。
- 异地冗余备份存储：不会转移异地备份设置。 由于副本无法启用异地备份，因此提升的主服务器（以前是副本）在提升后就没有它了。 该功能只能在标准服务器创建时激活（而非副本）。
- 服务器参数：如果这些参数的值在主服务器和只读副本上不同，则在提升期间它们不会更改。 必须注意的是，影响共享内存大小的参数在主服务器和副本上必须具有相同的值。 服务器参数部分详细说明了此要求。
- Microsoft Entra 身份验证：如果为主服务器配置了 Microsoft Entra 身份验证，但为副本设置了 PostgreSQL 身份验证，则提升后，副本不会自动切换到 Microsoft Entra 身份验证。 它将保留 PostgreSQL 身份验证。 用户需要在提升过程之前或之后在提升的副本上手动配置 Microsoft Entra 身份验证。
- 高可用性 (HA)：如果在提升后需要 HA，则必须在角色反转后在新提升的主服务器上进行配置。
注意事项
提升期间的服务器状态
在“按计划”和“强制”提升场景中，服务器（主服务器和副本）都必须处于“可用”状态。 如果服务器状态是“可用”以外的任何状态（例如“正在更新”或“正在重启”），则提升通常会出现问题而无法继续进行。 但是，在区域性中断情况下有一个例外。
在此类区域性中断期间，无论主服务器的当前状态如何，都可以实施强制提升方法。 此方法允许快速采取措施应对潜在的区域性灾难，从而绕过对服务器可用性的正常检查。
请注意，如果以前的主服务器在其副本提升期间发生故障而无法恢复，则唯一的选择是删除以前的主服务器并重新创建副本服务器。
在非配对区域中提升期间多个副本的可见性
在处理多个副本时，如果主要区域缺少配对的区域，则必须考虑一些特殊因素。 如果发生影响主服务器的区域性中断，新提升的副本将不会自动识别任何其他副本。 虽然应用程序仍可以定向到提升的副本以继续操作，但无法识别的副本在服务中断期间将保持断开连接状态。 仅当原始主要区域还原后，这些其他副本才会重新关联并恢复其角色。
提升期间的时间点还原
在“按计划”和“强制”提升场景中，需要最新的自动备份来确保 PITR 操作成功。 我们意识到一个问题：PITR 操作在故障转移和故障回复操作后可能会遇到以下错误。 我们计划在即将发布的版本中解决该问题。 为了确保最新的 PITR 操作成功，可以等待自动备份在提升操作后完成。
Error : Point-in-time-restore of server to the period when the siteswap operation for this server was in-progress or when the server was replica is not allowed.
常见问题解答
如果我的主服务器启用了高可用性 (HA)，我可以提升副本吗？
可以。无论主服务器是否启用了 HA，你都可以提升其只读副本。 能否将只读副本提升为主服务器与主服务器的 HA 配置无关。
如果我具有启用了 HA 的主服务器和一个只读副本，我提升该副本，然后换回原始主服务器，该服务器是否仍处于 HA 状态？
不会，我们在初始提升期间会禁用 HA，因为我们不支持启用了 HA 的只读副本。 将只读副本提升为主服务器意味着原始主服务器正在将其角色更改为副本。 如果要切换回来，则需要在原始主服务器上启用 HA。