Replication and High Availability
PostgreSQL by VSHN comes with support for multiple instances and High Availability using Patroni. You have the option to configure up to two additional replicas and also choose between three replication modes.
To enable high availability you need to set the number of instances to
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.|
On APPUiO Cloud, it’s currently not possible to deploy more than two instances, or more than a single instance that is larger than
You can also choose between one of three replication modes, by configuring it in the
apiVersion: vshn.appcat.vshn.io/v1 kind: VSHNPostgreSQL metadata: name: pgsql-app1-prod spec: parameters: instances: 3 replication: mode: sync
The three available modes are:
The asynchronous mode is the default replication mode. In this mode the cluster is allowed to lose some committed transactions to ensure availability. When the primary server fails or becomes unavailable for any other reason a sufficiently healthy standby will be promoted to primary. Any transactions that have not been replicated to that standby remain in a “forked timeline” on the primary, and are effectively unrecoverable.
When synchronous mode is turned on a standby will not be promoted unless it is certain that the standby contains all transactions that may have returned a successful commit status to client. If no suitable standby is available, primary server will still accept writes, but does not guarantee their replication. When the primary fails in this situation no standby will be promoted.
This mode essentially reduces the availability guarantee for better consistency guarantees. If you don’t have a use case where losing committed transactions is not permissible, we recommend using the asynchronous mode instead.
If it is absolutely necessary to guarantee that each write is stored durably on at least two nodes, you can enable the strict synchronous mode. In this mode, when no synchronous standby candidates are available, the primary won’t be available for writes, blocking all client write requests until at least one synchronous replica comes up.
We recommend to only use this mode if you have very strong consistency requirements and that you only use this mode with three instances, otherwise your instance will likely not accept any writes during maintenance and similar events.