Choosing your architecture¶

Always On architectures reflect EDB’s recommended 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.

Standard EDB Always On architectures¶

EDB has identified four standard Always On architectures:

Always On Bronze (single active location - cloud region or on prem data center) : Single active location (data center or availability

zone [AZ])

Always On Silver (single active location - cloud region or on prem data center) : Single active location with redundant hardware to

quickly restore failover capability and a backup in a disaster recovery (DR) location

Always On Gold (two active locations - cloud regions or on prem data centers) : Two active locations
Always On Platinum (two locations; fast HA restoration) : Two active locations with additional redundant

hardware in a hot standby mode

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 active 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.

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.

Architecture details¶

EDB Postgres Distributed uses a Monitoring Raft Consensus -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 BDR nodes to make decisions that require consensus, such as generating new global sequences, or distributed DDL operations. Even the simpler architectures always have three BDR nodes, even if not all of them are storing data. Always On Gold and Platinum, which use two active locations, introduce a fifth BDR 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 HA-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.