提升是指命令副本结束其副本模式并转换到完全读写操作的过程。
重要
升级操作不是自动的。 如果主服务器上发生故障，系统不会独立切换到只读副本。 提升操作始终需要用户操作。
您可以通过两种不同的方式提升副本：
提升到主服务器
此操作将副本提升为主服务器的角色。 在此过程中，当前主服务器将降级为副本角色，两者的角色将会交换。 若要成功完成提升，您需要为当前主节点配置一个虚拟终结点作为写入器终结点，并为计划提升的副本配置一个虚拟终结点作为读取器终结点。 仅当目标副本包含在读取方终结点配置中时，提升才会成功。 在源服务器上具有 Microsoft.DBforPostgreSQL/servers/write 权限的用户可以执行切换操作。
如果主服务器具有任何损坏的副本，请先删除这些副本，然后再启动提升到主服务器操作。 在这一过程中，只读副本被提升为新的主服务器。 此操作可能会导致大约 1-3 分钟的短暂停机时间，具体取决于升级时的复制延迟（对于计划的升级）。 升级完成后，将重新配置以前的主服务器以作为只读副本运行。
下图显示了升级前的服务器配置，以及升级操作成功完成后生成的状态。
提升为独立服务器并从复制中移除
选择此选项时，副本将提升成为独立服务器并从复制过程中移除。 因此，主服务器和提升后的服务器都将充当两个独立的读写服务器。 虽然可以配置虚拟终结点，但它们不需要执行此操作。 新提升的服务器不再是任何现有虚拟终结点的一部分，即使读取器终结点之前指向它。 如果应用程序应连接到新提升的副本，请更新应用程序的连接字符串以指向该副本。
下图显示了这些服务器在被提升之前的设置方式，以及在成功成为独立服务器之后的配置。
重要
“提升为独立服务器并从复制中删除”操作与以前的提升功能后向兼容。
重要
Server Symmetry：要通过“提升为主服务器”操作成功完成提升，主服务器和副本服务器必须具有相同的级别和存储大小。 例如，如果主副本有 2 个 vCore，而副本有 4 个 vCore，则唯一可行的选项是使用“提升为独立服务器并将其移出复制”操作。 此外，他们需要为 分配共享内存的参数共享相同的值。
对于这两种升级方法，请考虑以下选项：
计划：此选项可确保在提升之前同步数据。 它在接受客户端连接之前应用所有待处理的日志以确保数据一致性。
强制：此选项可以在发生区域服务中断等情况时实现快速恢复。 一旦服务器处理了实现最接近的一致状态所需的 WAL 文件，服务器就可以开始运行，而无需等待同步主服务器中的所有数据。 如果使用此选项提升副本，则在将副本与主副本解除链接时的延迟表明会丢失多少数据。
重要
“强制”提升选项用于解决区域性中断问题，在这种情况下，它会跳过所有检查（包括服务器对称要求）并继续提升。 此优先级是处理灾难方案的即时服务器可用性。 但是，如果未满足文档中规定的只读副本要求，尤其是服务器对称性要求，则不允许在区域故障场景之外使用“强制”选项，因为这可能会导致复制中断等问题。
了解如何 将只读副本切换到主服务器 并 提升为独立服务器并从复制关系中移除。
配置管理
控制平面将只读副本视为单独的服务器，因此可以独立管理配置。 此方法为读取扩展方案提供了灵活性。 但是，使用副本进行灾难恢复时，必须确保配置是所需的。
提升操作不会继承特定的配置和参数。 下面是一些值得注意的事项：
- PgBouncer：在提升过程中不会复制内置 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，因为Azure Database for PostgreSQL不支持启用 HA 的只读副本。 将只读副本提升为主实例意味着原来的主实例会变为副本实例。 如果要切换回来，则需要在原始主服务器上启用 HA。
相关内容
- Azure Database for PostgreSQL中读取副本。
- Azure Database for PostgreSQL 中的 地理复制。
- Azure Database for PostgreSQL 中用于只读副本的虚拟终结点。
- 创建读取副本。
- 使用专用网络跨Azure区域和虚拟网络进行复制。