Configure high availability in an Azure Database for PostgreSQL flexible server

APPLIES TO: Azure Database for PostgreSQL - Flexible Server

This article describes how you can enable or disable high availability configuration in your Azure Database for PostgreSQL flexible server in same zone, or zone redundant deployment models.

High availability feature deploys physically separate primary and standby replicas. Both replicas can be provisioned within the same availability zone or each on a different zone, depending on the deployment model you choose. For more information, see high availability concepts. You can enable high availability at creation time of your Azure Database for PostgreSQL flexible server, or you can do it after the server is created.

Important

Billing Model Update for Azure Database for PostgreSQL Flexible Server (v5 HA): In April, we implemented a billing model update for v5 SKU with High Availability (HA) enabled servers. This change aims to correctly reflect the charges, by accounting for both the primary and standby servers. Before this change, we were incorrectly charging customers for the primary server only. Customers using v5 SKU with HA enabled servers will now see billing quantities multiplied by 2. This update doesn't impact v4 and v3 SKUs.

Enable high availability for existing servers

Portal

Using the Azure portal:

1. Select your Azure Database for PostgreSQL flexible server.

2. In the resource menu, under the Settings section, select High availability.

   

3. If high availability isn't enabled, the Enable high availability checkbox appears unchecked, and High availability status is shown as Not Enabled.

   

4. Select the Enable high availability checkbox to enable the option. It shows Same zone and Zone redundant options. If you choose Same zone, the standby server is created in the same availability zone as the primary server.

   

Note

If the region in which your server is created doesn't support high availability with zone redundancy, the Zone redundant option is grayed out and disabled.

5. If the region supports zone redundancy, and you select Zone redundant, you can choose in which of the other available zones you want to deploy your standby server.

   

6. When everything is configured according to your needs, select Save to apply the changes. A dialog informs you of the cost increase associated with the deployment of the standby server. If you decide to proceed, select Enable HA.

   

7. A deployment initiates and, when it completes, a notification shows that high availability is successfully enabled.

   

CLI

You can enable high availability in an existing server via the az postgres flexible-server update command.

To enable high availability so that standby server is deployed in the same zone as the primary server, use this command:

az postgres flexible-server update --resource-group <resource_group> --name <server> --high-availability SameZone

To enable high availability with standby server deployed in a different zone than the primary server, and if you want the zone to be automatically selected, use this command:

az postgres flexible-server update --resource-group <resource_group> --name <server> --high-availability ZoneRedundant

Also, optionally, you can select the availability zone in which the standby server should be deployed. To do so, use this command:

az postgres flexible-server update --resource-group <resource_group> --name <server> --high-availability ZoneRedundant --standby-zone <standby_zone>

If you're enabling high availability with zone redundancy, and the zone specified for standby matches the zone of the primary, you get this error:

Your server is in availability zone <server>. The zone of the server cannot be same as the standby zone.

If you're enabling high availability with zone redundancy, and the zone specified for standby isn't available in that region, you get this error:

Code: InvalidParameterValue
Message: Invalid value given for parameter StandbyAvailabilityZone,availabilityZone. Specify a valid parameter value.

If you're enabling high availability with zone redundancy, and the region doesn't have multiple availability zones, you get this error:

This region is single availability zone. Zone redundant high availability is not supported in a single availability zone region.

If high availability is enabled in one mode, and you try to enable it again, specifying a different mode, you get the following error:

Code: InvalidParameterValue
Message: Invalid value given for parameter Cannot switch Properties.HighAvailability.Mode directly from SameZone to ZoneRedundant. Please disable HA and then enable HA.. Specify a valid parameter value.

Disable high availability

Portal

Using the Azure portal:

1. Select your Azure Database for PostgreSQL flexible server.

2. In the resource menu, under the Settings section, select High availability.

   

3. If high availability is enabled, the Enable high availability checkbox appears checked, High availability mode is set to the mode configured, and High availability status is typically shown as Healthy.

   

4. Clear the Enable high availability checkbox to disable the option.

   

5. Select Save to apply the changes. A dialog informs you of the cost reduction associated with the removal of the standby server. If you decide to proceed, select Disable HA.

   

6. A deployment initiates and, when it completes, a notification shows that high availability is successfully disabled.

   

CLI

You can disable high availability in an existing server via the az postgres flexible-server update command.

To disable high availability, use this command:

az postgres flexible-server update --resource-group <resource_group> --name <server> --high-availability Disabled

Enable high availability during server provisioning

Portal

Using the Azure portal:

1. During provisioning of a new instance of Azure Database for PostgreSQL Flexible Server, in the High availability section, select Same zone or Zone redundant.

   

Note

If the region in which your server is created doesn't support high availability with zone redundancy, the Zone redundant option is grayed out and disabled.

2. If you select a specific zone for the primary server by setting Availability zone to any value other than No preference, when you select Zone redundant, you can also select an explicitly selected value for the standby server in Standby availability zone. Setting the zones to specific zones is useful if you want to collocate your application in the same zone as the database, to reduce latency. Choose No preference if you want the standby server to deploy on an availability zone automatically chosen for you.

   

CLI

You can enable high availability while provisioning a new server via the az postgres flexible-server create command.

Note

The following commands need to be completed with other parameters, whose presence and values would vary depending on how you want to configure other features of the provisioned server.

To deploy the primary server with a standby server in the same zone, and let the service choose for you the zone, use this command:

az postgres flexible-server create --resource-group <resource_group> --name <server> --high-availability SameZone ...

To deploy the primary server with a standby server in the same zone, and explicitly choose the zone, use this command:

az postgres flexible-server create --resource-group <resource_group> --name <server> --high-availability SameZone --zone <zone> ...

If the availability zone specified isn't supported in the selected region, you get this error:

Code: AvailabilityZoneNotAvailable
Message: Specified availability zone is not supported in this region. Please choose a different availability zone.

To deploy the primary server with a standby server in a different zone, and let the service choose for you both zones, use this command:

az postgres flexible-server create --resource-group <resource_group> --name <server> --high-availability ZoneRedundant ...

To deploy the primary server with a standby server in a different zone, explicitly specify the zone for the primary but let the service choose the zone for the standby, use this command:

az postgres flexible-server create --resource-group <resource_group> --name <server> --high-availability ZoneRedundant --zone <zone> ...

To deploy the primary server with a standby server in a different zone, and explicitly specify the zone for the primary and the standby, use this command:

az postgres flexible-server create --resource-group <resource_group> --name <server> --high-availability ZoneRedundant --zone <zone> --standby-zone <standby_zone>...

If you choose zone redundant high availability, and the same value is specified for the zones of the primary and standby servers, you get this error:

Your server is in availability zone <zone>. The zone of the server cannot be same as the standby zone.

If the high availability mode selected is zone redundant, and the region doesn't have multiple availability zones, you get this error:

This region is single availability zone. Zone redundant high availability is not supported in a single availability zone region.

Forced failover

Follow these steps to force a failover of your primary server to the standby server in an Azure Database for PostgreSQL flexible server. Initiating a forced failover immediately brings the primary server down, and triggers a failover to the standby server. Initiating a forced failover is useful for cases in which 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-20 minutes between failovers. Such wait allows the new standby server to be fully established.

• The overall end-to-end operation time, as reported on the portal, could be longer than the actual downtime experienced by the application. You should measure the downtime from the application perspective.

Portal

Using the Azure portal:

1. Select your Azure Database for PostgreSQL flexible server that has high availability enabled.

2. In the resource menu, under the Settings section, select High availability.

   

3. If high availability mode is set to Zone redundant mode, you may want to take note of the values assigned to Primary availability zone and Standby availability zone, as they should be reversed after the failover operation completes.

   

4. Select Forced Failover to initiate the manual failover procedure. A dialog informs you of the expected downtime until the failover completes. If you decide to proceed, select OK.

   

5. A notification appears to mention that failover is in progress.

   

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

   

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.

   

CLI

You can enable high availability while provisioning a new server via the az postgres flexible-server restart command.

To initiate a forced failover, use this command:

az postgres flexible-server restart --resource-group <resource_group> --name <server> --failover Forced

If you try to force a failover of an Azure Database for PostgreSQL flexible server that doesn't have high availability enabled, you get this error:

Failing over can only be triggered for zone redundant or same zone servers.

If you try to force a failover of an Azure Database for PostgreSQL flexible server that has high availability enabled, but isn't ready to initiate the failover operation, you get this error:

Code: OperationFailed
Message: Operation HandleWalServiceFailureManagementOperation failed, because server <server> not in active state.

Planned failover

Follow these steps to perform a planned failover from your primary server to the standby server in an Azure Database for PostgreSQL flexible server. Initiating this operation first prepares the standby server, and then performs the failover. This failover operation provides the least downtime, as it performs a graceful failover to the standby server. It's useful for situations like after an unexpected failover occurs, and you want to bring the primary server back to your preferred availability zone.

Important

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

• We recommended performing planned failovers during low activity periods.

• The overall end-to-end operation time, as reported on the portal, could be longer than the actual downtime experienced by the application. You should measure the downtime from the application perspective.

Portal

Using the Azure portal:

1. Select your Azure Database for PostgreSQL flexible server that has high availability enabled.

2. In the resource menu, under the Settings section, select High availability.

   

3. If high availability mode is set to Zone redundant mode, you may want to take note of the values assigned to Primary availability zone and Standby availability zone, as they should be reversed after the failover operation completes.

   

4. Select Planned Failover to initiate the manual failover procedure. A dialog informs you of the expected downtime until the failover completes. If you decide to proceed, select OK.

   

5. A notification appears to mention that failover is in progress.

   

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

   

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.

   

CLI

You can enable high availability while provisioning a new server via the az postgres flexible-server restart command.

To initiate a forced failover, use this command:

az postgres flexible-server restart --resource-group <resource_group> --name <server> --failover Planned

If you try to force a failover of an Azure Database for PostgreSQL flexible server that doesn't have high availability enabled, you get this error:

Failing over can only be triggered for zone redundant or same zone servers.

If you try to force a failover of an Azure Database for PostgreSQL flexible server that has high availability enabled, but isn't ready to initiate the failover operation, you get this error:

Code: OperationFailed
Message: Operation HandleWalServiceFailureManagementOperation failed, because server <server> not in active state.

Special considerations

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

• High availability with both replicas deployed in the same zone is supported and available in all regions in which Azure Database for PostgreSQL - Flexible Server is supported. However, high availability with zone redundancy is only available in certain regions.

• High availability isn't supported in the Burstable tier. It's only supported in General purpose or Memory optimized tiers.

• If you deploy a server in a region that consists of a single availability zone, you can enable high availability in 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 with high availability configured as same zone or zone redundant. However, for any instances that were deployed in the region when the region consisted of a single availability zone, you can't directly enable high availability in zone redundant mode for them. As a workaround, you can restore those instances onto new instances, and then enable zone redundant high availability on the restored servers.

  1. Follow the instructions provided in Point-in-time restore of an Azure Database for PostgreSQL flexible server, to restore the existing instance on a new one, using the latest restore point.
  2. Once the new server is created, 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 instance.

Share your suggestions and bugs with the Azure Database for PostgreSQL product team.

• Overview of business continuity with Azure Database for PostgreSQL - Flexible Server.
• High availability in Azure Database for PostgreSQL - Flexible Server.
• Point-in-time restore of an Azure Database for PostgreSQL - Flexible Server instance.