Choosing a deployment architecture¶
Failover Manager is a high-availability module that monitors the healthof a Postgres streaming replication cluster and verifies failuresquickly. When a database failure occurs, Failover Manager canautomatically promote a streaming replication standby node into awritable primary node. This capability ensures continued performance and protectsagainst data loss with minimal service interruption.
A Failover Manager cluster is made up of Failover Manager processesthat reside on the following hosts on a network:
A primary node is the primary database server that is servicing
database clients.
One or more standby nodes are streaming replication servers
associated with the primary node.
The witness node confirms assertions of either the primary or a
standby in a failover scenario. If, during a failure situation, the
primary is in a partition with half or more of the nodes,
it stays primary. As such, Failover Manager supports running in
a cluster with an even number of agents.
Failover Manager provides various high availability options for EDBPostgres Advanced Server using the Postgres connection poolers andconnection libraries. These options have implications for ahigh-availability architecture.
To ensure the high availability of your database, you can combine core features of Failover Manager with the Postgres connection libraries (client connect failover) and connection poolers.
With the capabilities of Failover Manager, EDB has designed four basicarchitectures to run a high-availability environment:
Failover Manager using VIP (virtual IP): Failover Manager has a keycapability to manage VIP addresses out of the box. VIP addressesallow applications to connect to a single IP address that is beingrouted to the primary database server. This architecture is the mostbasic solution to run when VIP addresses are available in yourenvironment.
Failover Manager using client connect failover:PostgreSQL client libraries like libpq and jdbc allow for clientconnection failover. With client connection failover, the connectionstring contains multiple servers (host=srv1,srv2) and theclient library loops over the available hosts to find aconnection that is available and capable of read-write operations.This capability allows clients to follow the master during aswitchover. This solution doesn’t rely on virtual IP addresses. You can use it in every environmentwhere such client configurations can be set.
Failover Manager with PgBouncer: PgBouncer addscapabilities such as connection pooling and the option to halt traffic.You can also use it as a proxy between the client and the Postgres database server.By leveraging the integration options in Failover Manager to run reconfiguration of PgBouncer during afailover, you can use PgBouncer to route the traffic to the correctprimary database server.
Failover Manager with Pgpool: Pgpool-II isanother tool used as a proxy between the client and thePostgres database server. Pgpool-II adds capabilities suchas running in cluster mode with a Watchdog, managing VIPs, andread-only scalability. Failover Manager has native capabilities tointegrate with Pgpool-II to redirect traffic to another primaryduring Database failover operations.
These features are supported in each of thearchitectures:
Client connect failover
Connection pooling |
Yes |
Yes |
||
Runs on cloud (no VIP) |
Yes |
Yes |
Yes |
|
Halt traffic option |
Yes |
|||
Read-only scalability |
Yes (using multiple connection factories) |
Yes |
||
Clustered proxy |
Yes |
|||
Proxy integration |
ssh |
PCP |
||
Minimum servers required |
3 |
3 |
5 |
6 |
Complexity |
Low |
Low |
Medium |
High |
Network hops |
1 |
1 |
||
Failover duration |
Low |
Medium |
Low |
Low |
