Re: Built-in Raft replication
От | Andrey Borodin |
---|---|
Тема | Re: Built-in Raft replication |
Дата | |
Msg-id | 20FB597F-641F-48F8-8428-D8DDBA802D58@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: Built-in Raft replication (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Built-in Raft replication
Re: Built-in Raft replication |
Список | pgsql-hackers |
> On 16 Apr 2025, at 04:19, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > feebly, and seems to have a bus factor of 1. Another example is the > Spencer regex engine; we thought we could depend on Tcl to be the > upstream for that, but for a decade or more they've acted as though > *we* are the upstream. I think it's what Konstantin is proposing. To have our own Raft implementation, without dependencies. IMO to better understand what is proposed we need some more description of proposed systems. How the new system will be configured?initdb and what than? How new node joins cluster? What is running pg_rewind when necessary? Some time ago Peter E proposed to be able to start replication atop of empty directory, so that initial sync would be morestraightforward. And also Heikki proposed to remove archive race condition when choosing new timeline. I think this stepsare gradual movement in the same direction. My view is what Konstantin wants is automatic replication topology management. For some reason this technology is calledHA, DCS, Raft, Paxos and many other scary words. But basically it manages primary_conn_info of some nodes to providesome fault-tolerance properties. I'd start to design from here, not from Raft paper. Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: