Supported cluster types
BigAnimal supports three cluster types:
- Single node
- Standard high availability
- Extreme high availability (Preview)
You choose the type of cluster you want on the Create Cluster page in the BigAnimal portal.
Postgres distribution and version support varies by cluster type.
| Postgres distribution | Versions | Cluster type |
|---|---|---|
| PostgreSQL | 11–15 | Single node, high availability |
| Oracle Compatible | 11–15 | Single node, high availability |
| Oracle Compatible | 14–15 | Extreme high availability |
Single node
For nonproduction use cases where high availability isn't a primary concern, a cluster deployment with high availability not enabled provides one primary with no standby replicas for failover or read-only workloads.
In case of unrecoverable failure of the primary, a restore from a backup is required.
High availability
The high availability option is provided to minimize downtime in cases of failures. High-availability clusters—one primary and one or two standby replicas—are configured automatically, with standby replicas staying up to date through physical streaming replication.
If read-only workloads are enabled, then standby replicas serve the read-only workloads. In a two-node cluster, the single standby replica serves read-only workloads. In a three-node cluster, both standby replicas serve read-only workloads. The connections are made to the two standby replicas randomly and on a per-connection basis.
In cloud regions with availability zones, clusters are provisioned across zones to provide fault tolerance in the face of a datacenter failure.
In case of temporary or permanent unavailability of the primary, a standby replica becomes the primary.
Incoming client connections are always routed to the current primary. In case of failure of the primary, a standby replica is automatically promoted to primary, and new connections are routed to the new primary. When the old primary recovers, it rejoins the cluster as a standby replica.
Standby replicas
By default, replication is synchronous to one standby replica and asynchronous to the other. That is, one standby replica must confirm that a transaction record was written to disk before the client receives acknowledgment of a successful commit.
In a cluster with one primary and one replica (a two-node high availability cluster), you run the risk of the cluster being unavailable for writes because it doesn't have the same level of reliability as a three-node cluster. BigAnimal automatically disables synchronous replication during maintenance operations of a two-node cluster to ensure write availability. You can also change from the default synchronous replication for a two-node cluster to asynchronous replication on a per-session/per-transaction basis.
In PostgreSQL terms, synchronous_commit is set to on, and synchronous_standby_names is set to ANY 1 (replica-1, replica-2). You can modify this behavior on a per-transaction, per-session, per-user, or per-database basis with appropriate SET or ALTER commands.
To ensure write availability, BigAnimal disables synchronous replication during maintenance operations of a two-node cluster.
Since BigAnimal replicates to only one node synchronously, some standby replicas in three-node clusters might experience replication lag. Also, if you override the BigAnimal synchronous replication configuration, then the standby replicas are inconsistent.
Extreme high availability (Preview)
For use cases where high availability across regions is a major concern, a cluster deployment with extreme high availability enabled can provide two data group with three data nodes each, plus a witness group, for a true active-active solution. Extreme-high-availability clusters offer the ability to deploy a cluster across multiple regions or a single region. Extreme-high-availability clusters are powered by EDB Postgres Distributed using multi-master logical replication.
Extreme-high-availability clusters are only Oracle compatible.
Extreme-high-availability clusters are configured according to data groups. EDB Postgres Distributed (PGD) clusters create a PGD global group, which contains one or two data groups. Your data groups can be made up of a combination of data nodes and witness nodes. One of these data nodes is the leader at any given time, while the rest are shadow nodes.
The witness node/witness group doesn't host data but exists for management purposes, supporting operations that require a consensus, for example, in case of an availability zone failure.
The following are the possible node configurations for one data group:
- 2 data nodes + 1 local witness node
- 3 data nodes
If you're looking for a true active-active solution that protects against regional failures, select a two-data-group configuration. The following are the possible configurations for two data groups:
3 data nodes + 3 data nodes, 1 witness group in a different region
2 data nodes + 1 witness node, 2 data nodes + 1 witness node, and 1 witness group in a different region
For instructions on creating an extreme-high-availability cluster, see Creating an extreme-high-availability cluster.
If you want to restore an extreme-high-availability cluster, you can restore only one data group at a time. If you want to restore the second data group to the same cluster, you need to manually enter its details. For instructions, see Perform an extreme-high-availability cluster restore.