Date: Tue, 15 Apr 2025 14:14:35 +0300
From: Konstantin Osipov <kostja.osipov@gmail.com>
To: Yura Sokolov <y.sokolov@postgrespro.ru>
Cc: Kirill Reshke <reshkekirill@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Built-in Raft replication
Message-ID: <Z_4_m2LB8JL5LD0j@ark>
References: <Z_1Cq7JvabsFYjQo@ark>
 <CALdSSPgzhXTsY4UF-S2AsJwVBMvTSn1sB+Lc9jOcnQ8x3ebktg@mail.gmail.com>
 <142418c4-5db1-4221-a0a4-cd8aa9a17e83@postgrespro.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <142418c4-5db1-4221-a0a4-cd8aa9a17e83@postgrespro.ru>
Archived-At: <https://www.postgresql.org/message-id/Z_4_m2LB8JL5LD0j%40ark>
Precedence: bulk

* Yura Sokolov <y.sokolov@postgrespro.ru> [25/04/15 12:02]:

> > OTOH Raft needs to write its own log, and what's worse, it sometimes
> > needs to remove already written parts of it (so, it is not appended
> > only, unlike WAL). If you have a production system which maintains two
> > kinds of logs with different semantics, it is a very hard system to
> > maintain..
> 
> Raft is log replication protocol which uses log position and term.
> But... PostgreSQL already have log position and term in its WAL structure.
> PostgreSQL's timeline is actually the Term.
> Raft implementer needs just to correct rules for Term/Timeline switching:
> - instead of "next TimeLine number is just increment of largest known
> TimeLine number" it needs to be "next TimeLine number is the result of
> Leader Election".
> 
> And yes, "it sometimes needs to remove already written parts of it".
> But... It is exactly what every PostgreSQL's cluster manager software have
> to do to join previous leader as a follower to new leader - pg_rewind.
> 
> So, PostgreSQL already have 70-90%% of Raft implementation details.
> Raft doesn't have to be implemented in PostgreSQL.
> Raft has to be finished!!!
> 
> PS: One of the biggest issues is forced snapshot on replica promotion. It
> really slows down leader switch time. It looks like it is not really
> needed, or some small workaround should be enough.

I'd say my pet peeve is storing the cluster topology (the so
called raft configuration) inside the database, not in an external
state provider. Agree on other points.

-- 
Konstantin Osipov