* Andrey Borodin <x4mmm@yandex-team.ru> [25/04/16 11:06]:
> > Andrey Borodin <x4mmm@yandex-team.ru> writes:
> >> I think it's what Konstantin is proposing. To have our own Raft implementation, without dependencies.
> >
> > Hmm, OK. I thought that the proposal involved relying on some existing
> > code, but re-reading the thread that was said nowhere. Still, that
> > moves it from a large project to a really large project :-(
> >
> > I continue to think that it'd be best to try to implement it as
> > an extension, at least up till the point of finding show-stopping
> > reasons why it cannot be that.
>
> I think I can provide some reasons why it cannot be neither extension, nor any part running within postmaster reign.
>
> 1. When joining cluster, there’s not PGDATA to run postmaster on top of it.
>
> 2. After failover, old Primary node must rejoin cluster by running pg_rewind and following timeline switch.
>
> The system in hand must be able to manipulate with PGDATA without starting Postgres.
>
> My question to Konstantin is Why wouldn’t you just add Raft to Patroni? Is there a reason why something like Patroni
isnot in core and noone rushes to get it in?
> Everyone is using it, or system like it.
Raft uses the same WAL to store configuration change records as is used
for commit records. This is at the core of the correctness of the
algorithm. This is also my biggest concern with correctness of
Patroni - but to the best of my knowledge 's 90%+ of
use cases of Patroni use a "fixed" quorum size, that's defined at
start of the deployment and never/rarely changes.
Contrast to that being able to a replica to the quorum at any
time, and all it takes is just starting this replica and pointing
it at the existing cluster. This greatly simplifies UX.
--
Konstantin Osipov, Moscow, Russia
