MIME-Version: 1.0
References: <Z_1Cq7JvabsFYjQo@ark> <CAKAnmmJxGHcQmzXqEQ-nppZjXyH7i5W_7Cz8JNMb2+6c5+D+og@mail.gmail.com>
 <CAM527d9+eGvdih1GxoPDJ2WYs6eitf39oNTxGxnCK1PgF=A8wg@mail.gmail.com>
 <1798838.1744759182@sss.pgh.pa.us> <20FB597F-641F-48F8-8428-D8DDBA802D58@yandex-team.ru>
 <CAExHW5udz081Unx5qcLZ89DnR4cp6OhW0TCoco3+AEkGw480uQ@mail.gmail.com> <212D5973-FDD0-4CF5-BCD0-2760EC319DF3@yandex-team.ru>
In-Reply-To: <212D5973-FDD0-4CF5-BCD0-2760EC319DF3@yandex-team.ru>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: Wed, 16 Apr 2025 11:48:05 +0530
Message-ID: <CAExHW5tq8ShEfboFa52wDMWmyaW+6kX_6x8MZ-0TP65tOhJ1wQ@mail.gmail.com>
Subject: Re: Built-in Raft replication
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Konstantin Osipov <kostja.osipov@gmail.com>, 
	Greg Sabino Mullane <htamfids@gmail.com>, Nikolay Samokhvalov <nik@postgres.ai>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAExHW5tq8ShEfboFa52wDMWmyaW%2B6kX_6x8MZ-0TP65tOhJ1wQ%40mail.gmail.com>
Precedence: bulk

On Wed, Apr 16, 2025 at 10:29=E2=80=AFAM Andrey Borodin <x4mmm@yandex-team.=
ru> wrote:
>
> > We may build an extension which
> > has a similar role in PostgreSQL world as zookeeper in Hadoop.
>
> Patroni, pg_consul and others already use zookeeper, etcd and similar sys=
tems for consensus.
> Is it any better as extension than as etcd?

I feel so. An extension runs from within a postgresql process, uses
the same protocol as PostgreSQL whereas etcd is another process and
another protocol.

>
> > It can
> > be then used for other distributed systems as well - like shared
> > nothing clusters based on FDW.
>
> I didn=E2=80=99t get FDW analogy. Why other distributed systems should ch=
oose Postgres extension over Zookeeper?

By other distributed systems I mean PostgreSQL distributed systems -
FDW based native sharding or native replication or a system which uses
both.

>
> > There's already a proposal to bring
> > CREATE SERVER to the world of logical replication - so I see these two
> > worlds uniting in future.
>
> Again, I=E2=80=99m lost here. Which two worlds?

Logical replication and FDW based native sharding.

>
> > The
> > distributed system based on logical replication or FDW or both will
> > use this ensemble to manage its shared state. The same ensemble can be
> > shared across multiple distributed clusters if it has scaling
> > capabilities.
>
> Yes, shared DCS are common these days. AFAIK, we use one Zookeeper instan=
ce per hundred Postgres clusters to coordinate pg_consuls.
>
> Actually, scalability is opposite to topic of this thread. Let me explain=
.
> Currently, Postgres automatic failover tools rely on databases with built=
-in automatic failover. Konstantin is proposing to shorten this loop and ma=
ke Postgres use its build-in automatic failover.
>
> So, existing tooling allows you to have 3 hosts for DCS, with majority of=
 2 hosts able to elect new leader in case of failover.
> And you can have only 2 hosts for Postgres - Primary and Standby. You can=
 have 2 big Postgres machines with 64 CPUs. And 3 one-CPU hosts for Zookepe=
r\etcd.
>
> If you use build-in failover you have to resort to 3 big Postgres machine=
s because you need 2/3 majority. Of course, you can install MySQL-stype arb=
iter - host that had no real PGDATA, only participates in voting. But this =
is a solution to problem induced by built-in autofailover.

Users find it a waste of resources to deploy 3 big PostgreSQL
instances just for HA where 2 suffice even if they deploy 3
lightweight DCS instances. Having only some of the nodes act as DCS
and others purely PostgreSQL nodes will reduce waste of resources.

--=20
Best Wishes,
Ashutosh Bapat