Replication and High Availability

PostgreSQL by VSHN runs on CloudNativePG and supports up to two standby replicas next to the primary.

Enable High Availability

To enable high availability you need to set the number of instances to 2 or 3, which will provision one or two stand-by replicas.

The following example configuration will start a PostgreSQL service with two replicas.

apiVersion: vshn.appcat.vshn.io/v1
kind: VSHNPostgreSQL
metadata:
  name: pgsql-app1-prod
spec:
  parameters:
    instances: 3

Please be aware that enabling high availability will use significantly more resources and will cost two to three times more.

If you configure high availability, you might also want to configure the service level guaranteed. See Service Level Agreement.

On APPUiO Cloud, it’s currently not possible to deploy more than two instances, or more than a single instance that is larger than standard-2. Please contact APPUiO Cloud support, if this blocks you from running your application.

Failover

Writes go to the primary only. The standbys replay the primary’s write-ahead log and are there for availability, so more instances do not add write capacity.

When the primary fails, the CloudNativePG operator shuts it down, promotes one of the standbys to primary, and restarts the former primary as a standby. The host in the connection secret (POSTGRESQL_HOST) points to the postgresql-rw service, which always routes to the current primary, so clients reconnect to the new primary without any configuration change. See Automated failover in the CloudNativePG documentation for the details.

Replication Mode

Replication from the primary to the standbys is asynchronous. A failover can therefore lose transactions that were committed on the primary but had not yet reached the promoted standby.

The replication.mode parameter (async, sync, strict-sync) belongs to the previous StackGres-based PostgreSQL service and has no effect on CloudNativePG instances.