Re: Built-in Raft replication
От | Yura Sokolov |
---|---|
Тема | Re: Built-in Raft replication |
Дата | |
Msg-id | 90951dcf-30fc-4f11-87c7-44ddfdcbf768@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Built-in Raft replication (Andrey Borodin <x4mmm@yandex-team.ru>) |
Список | pgsql-hackers |
16.04.2025 07:58, Andrey Borodin пишет: > Yes, shared DCS are common these days. AFAIK, we use one Zookeeper instance per hundred Postgres clusters to coordinatepg_consuls. > > Actually, scalability is opposite to topic of this thread. Let me explain. > Currently, Postgres automatic failover tools rely on databases with built-in automatic failover. Konstantin is proposingto shorten this loop and make Postgres use its build-in automatic failover. > > So, existing tooling allows you to have 3 hosts for DCS, with majority of 2 hosts able to elect new leader in case of failover. > And you can have only 2 hosts for Postgres - Primary and Standby. You can have 2 big Postgres machines with 64 CPUs. And3 one-CPU hosts for Zookeper\etcd. > > If you use build-in failover you have to resort to 3 big Postgres machines because you need 2/3 majority. Of course, youcan install MySQL-stype arbiter - host that had no real PGDATA, only participates in voting. But this is a solution toproblem induced by built-in autofailover. Arbiter can store WAL without (almost) any data. Then it is not only for voting, but also for reliability as almost full featured third server. Certainly, it may become only "read-only master" - just to replicate WAL's tail it has and commit it by commiting record in new term/timeline. Then it should give leadership to other replica immediately. This idea is not a fantasy. BiHA does it. -- regards Yura Sokolov aka funny-falcon
В списке pgsql-hackers по дате отправления: