Edit

Share via

Configure high availability for Azure Database for PostgreSQL

This article describes how to enable or disable high availability (HA) on your Azure Database for PostgreSQL flexible server instance by using the Azure portal or the Azure CLI. The information applies whether you're using instances in the same zone or using a zone-redundant deployment model.

The high-availability feature deploys physically separate primary and standby replicas. You can provision the replicas within the same availability zone or in different zones, depending on the deployment model that you choose. For more information, see the article about high-availability concepts. You can enable high availability during or after the creation of your Azure Database for PostgreSQL flexible server instance.

Important

In April 2024, we updated the billing model for the v5 compute tier with HA-enabled servers. This change correctly reflects the charges by accounting for both the primary and standby servers. Before this change, you were incorrectly charged for the primary server only. If you use the v5 tier with HA-enabled servers, you now see billing quantities multiplied by 2. This update doesn't affect the v4 and v3 tiers.

Enable high availability for existing servers

  1. In the Azure portal, select your Azure Database for PostgreSQL flexible server instance.

  2. On the left menu, in the Settings section, select High availability.

The Zonal Resiliency option controls whether your server is protected across availability zones. You have two choices:

  • Enabled – When you select this option, Azure tries to create the standby server in a different availability zone than the primary. This option gives you the best protection against zone-level failures.
  • Disabled – High availability isn't configured.

If you enable zonal resiliency but your region doesn't have enough capacity for a zone-redundant setup, you see a checkbox under the Enabled option. Selecting this checkbox allows you to create the standby server in the same zone as the primary. This option ensures you still get node-level protection even when zone capacity is limited. Later, when zonal capacity becomes available, Azure automatically migrates your standby server to a different zone during a maintenance window to minimize downtime.

  1. If Zonal Resiliency isn't enabled, select the Enabled radio button.

    Screenshot that shows the pane for configuring high availability.

  2. On selecting the Enabled radio button, the Zone redundant option can be applied by default for regions that have support for availability zones, as it's the recommended configuration to protect against zonal failures.

    Screenshot that shows the checkbox selected to enable high availability.

  3. If the region doesn't have zonal capacity, to make sure that high availability (HA) gets enabled in your preferred region, you have to select the checkbox under the enabled option to allow creating HA with Same-Zone mode of the region. It automatically migrates your workloads to Zone-Redundant HA once zonal capacity becomes available:

    Screenshot that shows selection of the same-zone option for high availability.

  4. When everything is configured according to your needs, select Save to apply the changes.

  5. A dialog shows the cost increase associated with the deployment of the standby server. If you decide to proceed, select Enable high availability.

    Screenshot that shows the dialog to confirm the enablement of high availability.

  6. A deployment starts. When it finishes, a notification shows that you successfully enabled high availability.

    Screenshot that shows a notification about completed deployment of a high-availability configuration.

Disable high availability

  1. In the Azure portal, select your Azure Database for PostgreSQL flexible server instance.

  2. On the left menu, in the Settings section, select High availability.

  3. If high availability is enabled, the Enabled radio button for Zonal Resiliency is already selected. Also, High availability mode is set to the configured mode, and the High availability status value is typically Healthy.

    Screenshot that shows the pane for configuring high availability, with high-availability options already selected and a status of Healthy.

  4. Select the Disabled radio button to disable HA.

    Screenshot that shows the checkbox for enabling high availability cleared.

  5. Select Save to apply the changes.

  6. A dialog shows the cost reduction associated with the removal of the standby server. If you decide to proceed, select Disable high availability.

    Screenshot that shows the dialog to confirm disablement of high availability.

  7. A deployment starts. When it finishes, a notification shows that you successfully disabled high availability.

    Screenshot that shows a notification about successful disablement of high availability.

Enable high availability during server provisioning

  1. In the Azure portal, during provisioning of a new Azure Database for PostgreSQL flexible server instance, go to the Business Critical (High availability) section. Select the Enabled radio button in the Zonal Resiliency section.

    • By default, the server attempts to create the standby server in a different availability zone with Zone-Redundant HA mode for maximum zonal resiliency.

    • If zonal capacity isn't available, you can select the Allow standby in same zone if zonal resiliency fails checkbox as a fallback. This option ensures HA is still enabled, and Azure automatically migrates to zone-redundant HA when capacity becomes available.

      Screenshot that shows high-availability options during provisioning of a new flexible server instance.

  2. Select a specific zone for the primary server by setting Availability zone to any value other than No preference.

    Screenshot that shows the selection of specific availability zones for primary server.

Initiate a forced failover

Follow these steps to force a failover of your primary server to the standby server in Azure Database for PostgreSQL.

When you initiate a forced failover, the primary server immediately goes down and triggers a failover to the standby server. Initiating a forced failover is useful when you want to test how a failover caused by an unplanned outage would affect your workload.

Important

  • Don't perform immediate, back-to-back failovers. Wait for at least 15 to 20 minutes between failovers. This wait time allows the new standby server to be fully established.

  • The overall end-to-end operation time, as reported on the portal, might be longer than the actual downtime that the application experiences. You should measure the downtime from the application's perspective.

  1. In the Azure portal, select your Azure Database for PostgreSQL flexible server instance that has high availability enabled.

  2. On the left menu, in the Settings section, select High availability.

  3. If the high-availability mode is set to Zone redundant, note the values assigned to Primary availability zone and Standby availability zone. They should be reversed after the failover operation finishes.

  4. Select Forced failover to start the manual failover procedure. A dialog informs you of the expected downtime until the failover finishes. If you decide to proceed, select Initiate forced failover.

    Screenshot that shows the dialog displayed before the initiation of a forced failover.

  5. A notification appears and mentions that a failover is in progress.

    Screenshot that shows a notification about a failover in progress after the initiation of a forced failover.

  6. After the failover to the standby server is complete, a notification informs you of the completion.

    Screenshot that shows the notification displayed when a forced failover finishes.

  7. If the high-availability mode is configured as Zone redundant, confirm that the values of Primary availability zone and Standby availability zone are now reversed.

Initiate a planned failover

Follow these steps to perform a planned failover from your primary server to the standby server in Azure Database for PostgreSQL. Initiating this operation prepares the standby server and then performs the failover.

This failover operation provides the least downtime, because it performs a graceful failover to the standby server. It's useful for situations like bringing the primary server back to your preferred availability zone after an unexpected failover.

Important

  • Don't perform immediate, back-to-back failovers. Wait for at least 15 to 20 minutes between failovers. This wait time allows the new standby server to be fully established.

  • Perform planned failovers during low-activity periods.

  • The overall end-to-end operation time, as reported on the portal, might be longer than the actual downtime that the application experiences. You should measure the downtime from the application's perspective.

  1. In the Azure portal, select your Azure Database for PostgreSQL flexible server instance that has high availability enabled.

  2. On the left menu, in the Settings section, select High availability.

  3. If the high-availability mode is set to Zone redundant, note the values assigned to Primary availability zone and Standby availability zone. They should be reversed after the failover operation finishes.

  4. Select Planned failover to start the manual failover procedure. A dialog informs you of the expected downtime until the failover finishes. If you decide to proceed, select Initiate planned failover.

    Screenshot that shows the dialog displayed before the initiation of a planned failover.

  5. A notification appears and mentions that failover is in progress.

    Screenshot that shows a notification about a failover in progress after the initiation of a planned failover.

  6. After the failover to the standby server is complete, a notification informs you of the completion.

    Screenshot that shows the notification displayed when a planned failover finishes.

  7. If the high-availability mode is configured as Zone redundant, confirm that the values of Primary availability zone and Standby availability zone are now reversed.

Special considerations

  • Enabling or disabling high availability on an Azure Database for PostgreSQL flexible server instance doesn't change other settings, including networking configuration, firewall settings, server parameters, or backup retention. Enabling or disabling high availability is an online operation. It doesn't affect your application connectivity and operations.

  • Azure Database for PostgreSQL flexible server instances support high availability with both replicas deployed in the same zone. This configuration is available in all supported regions. However, high availability with zone redundancy is available only in certain regions.

  • The Burstable tier doesn't support high availability. Only the General purpose and Memory optimized tiers support high availability.

  • If you deploy a server in a region that consists of a single availability zone, you can enable high availability in the same-zone mode only. If the region is enhanced in the future with multiple availability zones, you can deploy new Azure Database for PostgreSQL flexible server instances with high availability configured as same zone or zone redundant.

    However, for any instances that you deployed in the region when the region consisted of a single availability zone, you can't directly enable high availability in zone-redundant mode. As a workaround, you can restore those instances on new servers, and then enable zone-redundant high availability on the restored servers:

    1. Restore an existing instance on a new server by using the latest restore point.
    2. After you create the new server, enable high availability with zone redundancy.
    3. After data verification, you can optionally delete the old server.
    4. Make sure that the connection strings of your clients are modified to point to your newly restored server.

Related content