Re: Advice on cluster architecture for two related, but distinct, use cases

From: "sunyucong(at)gmail(dot)com" <sunyucong(at)gmail(dot)com>
To: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Cc: Matthias Leisi <matthias(at)leisi(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Advice on cluster architecture for two related, but distinct, use cases
Date: 2024-11-11 14:46:45
Message-ID: CAJygYd1Q0Zf6U8OWVT2ET5E3sg0d3XPbEJaD0jF93d3___UH7A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

CC

On Mon, Nov 11, 2024 at 09:28 Greg Sabino Mullane <htamfids(at)gmail(dot)com>
wrote:

> Some of those requirements are vague, but yes, Patroni should probably be
> the first approach you look at. If the second datacenter is just for
> redundancy, then a simple setup would be:
>
> DCA (data center A):
> Postgres server 1
> Postgres server 2
>
> DCB:
> Postgres server 3 (set no_failover: true)
>
> You will also need a DCS system of some sort (e.g. etcd on all three
> nodes), as well as a backup system (e.g. pgBackRest). Will also need to
> decide how automated you want things to be (for example, cross datacenter
> failover in the above would be manually done). It should definitely be able
> to handle your RPO/RTO requirements easily enough.
>
> [Patroni] However it seems relatively complex to set up and operate
>
>
> Setting things up can be a little complex, yes, but once done it just
> works, so very little operation resources are needed.
>
> We can not assume eg a load balancer.
>
>
> Possible via the application: see
> https://www.postgresql.org/docs/current/libpq-connect.html (esp.
> target_session_attrs)
>
> Cheers,
> Greg
>
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2024-11-11 16:18:40 Re: postgresql-17.0-1 Application - silent installation Issue
Previous Message Greg Sabino Mullane 2024-11-11 14:27:33 Re: Advice on cluster architecture for two related, but distinct, use cases