Hi,
I am considering starting work on implementing a built-in Raft
replication for PostgreSQL.
Raft's advantage is that it unifies log replication, cluster
configuration/membership/topology management and initial state transfer
into a single protocol.
Currently the cluster configuration/topology is often managed by
Patroni, or similar tools, however, it seems there are certain
usability drawbacks with this approach:
- it's a separate tool, requiring an external state provider like etcd;
raft could store its configuration in system tables; this is
also an observability improvement since everyone could look up
cluster state the same way as everything else
- same for watchdog; raft has a built-in failure detector that's
configuration aware;
- flexible quorums; currently quorum size is a configurable;
with a built-in raft, extending the quorum could be a matter
of starting a new node and pointing it to an existing cluster
Going forward I can see PostgreSQL providing transparent bouncing
on pg_wire level, given that Raft state is now part of the
system, so drivers and all cluster nodes could easily see where
the leader is.
If anyone is working on Raft already I'd be happy to discuss
the details. I am fairly new to the PostgreSQL hackers ecosystem
so cautious of starting work in isolation/knowing there is no
interest in accepting the feature into the trunk.
Thanks,
--
Konstantin Osipov
