Choosing your architecture v4
Always On architectures reflect EDB’s Trusted Postgres architectures that encapsulate practices and help you to achieve the highest possible service availability in multiple configurations. These configurations range from single-location architectures to complex distributed systems that protect from hardware failures and data center failures. The architectures leverage EDB Postgres Distributed’s multi-master capability and its ability to achieve 99.999% availability, even during maintenance operations.
You can use EDB Postgres Distributed for architectures beyond the examples described here. Use-case-specific variations have been successfully deployed in production. However, these variations must undergo rigorous architecture review first. Also, EDB’s standard deployment tool for Always On architectures, TPAExec, must be enabled to support the variations before they can be supported in production environments.
EDB has identified four standard Always On architectures:
- Bronze: Single location with two data nodes, a witness node, and a local backup
- Silver: Single location with three data nodes and second location with an offsite backup
- Gold: Two locations with two data nodes each and a third location with a witness
- Platinum: Two locations with three data nodes each (two masters plus additional redundant hardware in a hot standby mode)
Note: A location is either a data center or availability zone [AZ].
All Always On architectures protect a progressively robust range of failure situations. For example, Always On Bronze protects against local hardware failure but doesn't provide protection from location (data center or AZ) failure. Always On Silver makes sure that a backup is kept at a different location, thus providing some protection in case of the catastrophic loss of a location. However, the database still must be restored from backup first, which might violate Recovery Time Objective (RTO) requirements. Always On Gold provides two locations connected in a multi-master mesh network, making sure that service remains available even in case a location goes offline. Finally, Always On Platinum adds redundant hot standby hardware in both locations to maintain local high availability in case of a hardware failure.
Each architecture can provide zero Recovery Point Objective (RPO), as data can be streamed synchronously to at least one local master, thus guaranteeing zero data loss in case of local hardware failure. However, synchronous replication is highly discouraged for Bronze architectures due to the extended RPO on failure of either data node.
Increasing the availability guarantee drives additional cost for hardware and licenses, networking requirements, and operational complexity. Carefully consider your availability and compliance requirements before choosing an architecture.
EDB Postgres Distributed uses a Raft-based consensus architecture. While regular database operations (insert, select, delete) don’t require cluster-wide consensus, EDB Postgres Distributed benefits from an odd number of nodes to make decisions that require consensus, such as generating new global sequences, or distributed DDL operations. Even the simpler architectures always have three nodes within a location, even if not all of them are storing data. Always On Gold and Platinum, which use two locations, introduce a fifth node as a witness node to support the RAFT requirements.
Applications connect to the standard Always On architectures by way of multi-host connection strings, where each HARP-proxy server is a distinct entry in the multi-host connection string. Other connection mechanisms have been successfully deployed in production, but they're not part of the standard Always On architectures.
All architectures provide the following:
- Hardware failure protection
- Zero downtime upgrades
- Support for availability zones in public/private cloud
Use these criteria to help you to select the appropriate Always On architecture.
|Minimum Locations Needed||1||2||3||2|
|Location failure protection||No - unless offsite backup||Yes - Recovery from backup||Yes - instant failover to fully functional site||Yes - instant failover to fully functional site|
|Failover to DR or full DC||NA (DR only if offsite backup)||DR using offsite backup||Full DC||Full DC|
|Fast local restoration of high availability after device failure||No; time to restore HA: (1) VM prov + (2) approx 60 min/500GB||Yes; three local data nodes allow to maintain HA after device failure||No; time to restore HA: (1) VM prov + (2) approx 60 min/500GB||Yes; logical standbys can quickly be promoted to master data nodes|
|Cross location network traffic||None (unless offsite backup then backup traffic only)||Backup traffic only||Full replication traffic||Full replication traffic|
|License cost||2 data nodes||3 data nodes||4 data nodes||4 data nodes |
2 logical standbys