From: Jānis Pūris <janis@puris.lv>
To: pgsql-admin@postgresql.org
Subject: HAProxy + Patroni + pgBouncer High Availability setup
Date: Sun, 4 Aug 2019 02:27:39 +0200
Message-ID: <6ae63a77-5f9c-4f57-b409-e79a8b0244fb@Spark> (raw)
In-Reply-To: <5c247980-5a8f-4864-9e5a-3d330adcc253@Spark>
References: <5c247980-5a8f-4864-9e5a-3d330adcc253@Spark>
Hello,
I have a working HAProxy, Patroni, PG stack and would like to add pgbouncer in the mix.
Current topology descr.
Haproxy is checking Patroni API, if the node it is responsible for is primary, if so, the requests are routed to it's postgresql server. When a failure occurs Patroni would do its magic and a different node in the cluster is promoted, HAProxy sees it via Patroni API checks and requests are rerouted to this new node. It works!
The problem
if I'd deploy pgBouncer between HAProxy and PostgreSQL, it would be a single point of failure. For example, if pgBouncer fails on primary, Patroni would not mind and no other node would take primary to mitigate the disaster.
Topology
[client] <--> [haproxy] <---> [pgbouncer] <---> [postgres]
|-----------> [patroni] <-------->/
How can I improve the architecture, to avoid single point of failure ? I could of course add watchdog and similar processes, but I would really prefer not too overcomplicate the stack.
P.S. Deploying pgBouncer before client app is not an option, as a lot of different API and clients are talking to the cluster, as well as they are deployed in range of environments, i.e. kubernetes, metal, vms etc and so on.
Best regards, JP.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: janis@puris.lv
Subject: Re: HAProxy + Patroni + pgBouncer High Availability setup
In-Reply-To: <6ae63a77-5f9c-4f57-b409-e79a8b0244fb@Spark>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox