High availability of a Managed Service for PostgreSQL cluster

High availability of a Managed Service for PostgreSQL cluster depends on the number and placement of its hosts, replication settings, and other cluster parameters.

Number and placement of cluster hostsNumber and placement of cluster hosts

A cluster may consist of one or more hosts.

A single-host cluster does not provide high availability. If the master host VM fails, your cluster will be unavailable for reading and writing until the VM recovers completely. Single-host clusters are not covered by the Service level agreement (SLA).

A cluster with two hosts located in different availability zones is considered highly available and is subject to the SLA. This option is suitable for medium-sized applications in a production environment. The default cluster configuration offered in the management console includes two hosts.

A cluster with three or more hosts located in three different availability zones is considered highly available and is subject to the SLA. Such clusters are suitable for production environments subject to high availability and performance requirements.

For more information, see Planning cluster topology.

Replication settingsReplication settings

High cluster availability is achieved through replication and master failover mechanisms, which have the following features:

• Clusters uses streaming replication. Each replica host receives a replication stream from another host, typically the master. Managed Service for PostgreSQL manages replication streams in the cluster automatically, but you can manage them manually if you need to. When you set the replication source manually, the replicas will have a number of limitations.
• If you have configured public access for the master host, you must also enable it for the replicas; otherwise, the cluster may become unavailable after a master failover.
• The cluster uses automatic master selection and failover in case the current master fails.

Replication management and automatic failover ensure the highest possible write availability for clusters with any number of hosts.

In a cluster of three or more hosts:

• If the master fails, the system automatically switches to a new master.
• Loss of a replica does not affect cluster availability.

In a two-host cluster:

• If the master fails, the system automatically fails over to a synchronous replica with zero data loss.
• If a replica fails, the cluster automatically switches to asynchronous replication mode within 15 seconds. During this period, transactions may pause while awaiting confirmation but resume and complete successfully once the cluster switches to asynchronous mode. While recovering from the failure, the replica fully synchronizes with the master, and the cluster resumes operation in synchronous replication mode.

To minimize the risk of a cluster being unavailable for writes, we recommend deploying Managed Service for PostgreSQL clusters with three or more hosts.

Maintenance settingsMaintenance settings

In some cases, maintenance is impossible without connection loss. Therefore, any application that accesses the database must be resilient to connection drops.

During maintenance, a cluster with two or more hosts may be unavailable for writes while switching masters. The host being restarted becomes unreadable. Single-host clusters are completely unavailable during restarts. We recommend selecting maintenance day and hour based on estimated cluster load.

PostgreSQL version upgrades make a cluster unavailable for writes. Replicas become unreadable one by one, i.e., at least one replica remains readable in a three-host cluster, two in a four-host cluster, etc. Single-host and two-host clusters become completely unavailable during PostgreSQL version upgrades. Take this into account when planning to upgrade your cluster version.

Other settingsOther settings

The following settings may also affect cluster availability:

• Backup settings.
• Storage disk type you selected.
• Host classes.
• Connection pooler's operation mode and settings.
• Quotas and limits.
• Write-ahead log (WAL) settings.