[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-admin
Subject: HAProxy + Patroni + pgBouncer High Availability setup
From: Jānis_Pūris <janis () puris ! lv>
Date: 2019-08-04 0:27:39
Message-ID: 6ae63a77-5f9c-4f57-b409-e79a8b0244fb () Spark
[Download RAW message or body]
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.
[Attachment #3 (text/html)]
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div dir="auto">Hello,
<div dir="auto"><br /></div>
<div dir="auto">I have a working HAProxy, Patroni, PG stack and would like to add \
pgbouncer in the mix.</div> <div dir="auto"><br /></div>
<div dir="auto"><b>Current topology descr.</b></div>
<div dir="auto">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!</div> <div dir="auto"><br /></div>
<div dir="auto"><b>The problem</b></div>
<div dir="auto"><span style="caret-color: rgb(213, 218, 222);">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.</span></div> <div dir="auto"><span \
style="caret-color: rgb(213, 218, 222);"><br /></span></div> <div \
dir="auto"><b>Topology</b></div> <div dir="auto">[client] <--> [haproxy] \
<---> [pgbouncer] <---> [postgres]<br /> \
|-----------> [patroni] <-------->/<br /></div> <div \
dir="auto"><span style="caret-color: rgb(213, 218, 222);"><br /></span></div> <div \
dir="auto">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.</div> <div dir="auto"><br /></div>
<div dir="auto">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.</div> <div \
dir="auto"><br /></div> <div dir="auto">Best regards, JP.</div>
</div>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic