| From: | Konstantin Osipov <kostja(dot)osipov(at)gmail(dot)com> |
|---|---|
| To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
| Cc: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Built-in Raft replication |
| Date: | 2025-04-16 19:35:34 |
| Message-ID: | aAAGhnFNNoZwWszb@ark |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Greg Sabino Mullane <htamfids(at)gmail(dot)com> [25/04/16 22:33]:
> > Users find it a waste of resources to deploy 3 big PostgreSQL instances
> > just for HA where 2 suffice even if they deploy 3 lightweight DCS
> > instances. Having only some of the nodes act as DCS and others purely
> > PostgreSQL nodes will reduce waste of resources.
> >
>
> A big problem is that putting your DCS into Postgres means your whole
> system is now super-sensitive to IO/WAL-streaming issues, and a busy
> database doing database stuff is going to start affecting the DCS stuff.
Affecting in 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 philosophy of "do one thing, and do it well."
--
Konstantin Osipov, Moscow, Russia
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-04-16 19:55:09 | Re: not null constraints, again |
| Previous Message | Greg Sabino Mullane | 2025-04-16 19:29:05 | Re: Built-in Raft replication |