public inbox for [email protected]
help / color / mirror / Atom feedRe: Request for Feedback on PostgreSQL HA + Load Balancing Architecture
2+ messages / 2 participants
[nested] [flat]
* Re: Request for Feedback on PostgreSQL HA + Load Balancing Architecture
@ 2025-07-23 11:13 Achilleas Mantzios <[email protected]>
2025-07-23 11:39 ` Re: Request for Feedback on PostgreSQL HA + Load Balancing Architecture Jehan-Guillaume de Rorthais <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Achilleas Mantzios @ 2025-07-23 11:13 UTC (permalink / raw)
To: vijay patil <[email protected]>; [email protected]
On 6/18/25 18:12, vijay patil wrote:
> Hi Team,
>
> I am planning to implement a PostgreSQL High Availability (HA) and
> Load Balancing setup and would greatly appreciate your feedback on the
> architecture we've designed (see attached diagram).
>
> image.png
>
> *Overview of the Setup:*
>
> *
>
> Two PostgreSQL nodes (VM1 and VM2) configured with:
>
> o
>
> Asynchronous replication from the Primary DB (on VM1) to the
> Standby DB (on VM2) using |repmgr|
>
> o
>
> HAProxy for failover management:
>
> +
>
> HAProxy 1 (active) on VM1
>
> +
>
> HAProxy 2 (passive) on VM2 with Keepalive for heartbeat
> and failover detection
>
> o
>
> PgBouncer on both nodes for connection pooling
>
> *
>
> A Virtual IP (VIP) managed by HAProxy for routing traffic from the
> application
>
> *
>
> Read/Write operations go to the Primary DB, and Read-Only queries
> can be served from either node
>
> *Objectives:*
>
> *
>
> Ensure high availability with automatic failover
>
> *
>
> Enable basic load balancing for read-only queries
>
> *
>
> Maintain connection pooling and routing efficiency
>
> *Request for Feedback:*
>
> *
>
> Is this architecture considered a best practice within the
> PostgreSQL community?
>
> *
>
> Are there any potential bottlenecks or failure points I should be
> aware of?
>
> *
>
> Would you recommend any improvements or alternative tools for
> achieving better reliability and performance?
>
Personally I will test long run via app -> pgbouncer -> pgpool-ii in
order to combine :
* Query Routing (read/write automatic split)
* Load Balancing
* High Availability
* Query caching
Have you consider pgpool-ii ? I know most support / service companies
push for patroni, and manually separating read / write traffic from
within the app, but I still find pgpool's query routing very nice.
> *
>
>
> Thanks
>
> Vijay
>
Attachments:
[image/png] image.png (83.3K, 3-image.png)
download | view image
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Request for Feedback on PostgreSQL HA + Load Balancing Architecture
2025-07-23 11:13 Re: Request for Feedback on PostgreSQL HA + Load Balancing Architecture Achilleas Mantzios <[email protected]>
@ 2025-07-23 11:39 ` Jehan-Guillaume de Rorthais <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Jehan-Guillaume de Rorthais @ 2025-07-23 11:39 UTC (permalink / raw)
To: Achilleas Mantzios <[email protected]>; +Cc: vijay patil <[email protected]>; [email protected]
On Wed, 23 Jul 2025 12:13:26 +0100
Achilleas Mantzios <[email protected]> wrote:
…
> Have you consider pgpool-ii ? I know most support / service companies
> push for patroni, and manually separating read / write traffic from
> within the app,
Indeed
> but I still find pgpool's query routing very nice.
Using Pgpool for HA is a no go in my opinion. Pgpool HA requires the
DBA/sysadmin to deal alone with the real high availability challenges. Pgpool
doesn't handle the HA complexity itself, it stays quite "naive". It requires the
sysadmin/DBA to mess with the complexity to keep the cluster safe from
corruption. In other word, implement the HA safety stack in bash yourself. This
is partly true for repmgr as well last time I checked.
Don't implement Patroni or Pacemaker yourself in a collection of "action
scripts" triggered by a naive HA stack. Some people tried, some clusters has
been corrupted.
Pgpool for routing and/or pooling is an acceptable solution. Of course, it comes
with its drawbacks and some inefficiences, that's why most support/service
companies avoid it when possible. But depending on the context, it could be OK.
Regards,
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-07-23 11:39 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-07-23 11:13 Re: Request for Feedback on PostgreSQL HA + Load Balancing Architecture Achilleas Mantzios <[email protected]>
2025-07-23 11:39 ` Jehan-Guillaume de Rorthais <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox