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
