Re: Built-in Raft replication

n what way? Do you have a scenario in mind where an external state provider would act differently (better)? > With three lightweight DCS servers, you don't really need to worry about > how stressed the database servers are. In that way, I feel etcd et al. are > adhering to the unix philo

Re: Built-in Raft replication

x27;ll still work, but no automation will be available, just like today with Patroni. However, if the storage cost is an argument, then the logical path is to disaggregate storage/compute altogether, i.e. use projects like neon. -- Konstantin Osipov, Moscow, Russia

Re: Built-in Raft replication

k, but it's a plumbing trick. The new member needs to generate and persist a globally unique identifier as the first step. Later it can reintroduce itself to the cluster given this identifier can be preserved in the new incarnation (popen + fork). -- Konstantin Osipov, Moscow, Russia

Re: Built-in Raft replication

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

Re: Built-in Raft replication

, converting most of participants to non-voters in large clusters. Raft replication, again, if implemented in a naive way, would require a O(outstanding transaction) * number of replicas amount of RAM. But that doesn't have to be naive. To sum up, I am not aware of any principal limitations in this area. -- Konstantin Osipov, Moscow, Russia

Re: Built-in Raft replication

rusive change than adding raft on top of the existing synchronous replication in PostgreSQL. Given that Raft already provides an amortized single-round-trip commit time, and the goal is simplicity of UX and unification, I'd say it's wise to wait and see for the leader-less approaches

Re: Built-in Raft replication

proxies, clients). I understand and accept that it's a multi-year effort, but I do not accept the retort - my main point is that external tools are not a replacement, and I'd like to reach consensus on that. -- Konstantin Osipov, Moscow, Russia

Re: Built-in Raft replication

re incidents without manual intervention. It allowed cluster > maintenance (software and hardware upgrades) without application downtime. > I really dream PostgreSQL will be as reliable as MongoDB without need of > external services. thanks for pointing out mongodb, so built-in raft would he

Re: Built-in Raft replication

to invest community resources into something else. My personal take away from this as a community member would be seamless coordinator failover in Greenplum and all of its forks (CloudBerry, Greengage, synxdata, what not). I also imagine there is a number of PostgreSQL derivatives that could benefit from built-in transparent failover since it standardizes the solution space. -- Konstantin Osipov

Re: Built-in Raft replication

ough. 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

Re: Built-in Raft replication

rietary implementation out in the field confirms it could be a good idea to have it in PostgreSQL trunk. In any case I'm interested in contributing to the trunk, not building a proprietary module/fork. -- Konstantin Osipov

Built-in Raft replication

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