Hi Jehan-Guillaume, Thanks for your opinion.
At first glance, i may use for automatic failover PAF, a proxy HAproxy and for fencincg, i am a bit disappointed, i don't know what to do/use How about you, do you have any preference about tools/solutions to use ? now, I am aware that i will have to check and document limitation/risk... Le mer. 5 sept. 2018 à 11:38, Jehan-Guillaume (ioguix) de Rorthais < iog...@free.fr> a écrit : > Hi all, > > On Tue, 4 Sep 2018 15:09:51 +0000 > ROS Didier <didier....@edf.fr> wrote: > > > Hi > > I have made a lot of PostgreSQL High Availability tests > (more > > than 20 by solution) and the two following products respond well to the > need : > > > > (1) Repmgr (2ndQuadrant) > > > > (2) Pglookout (aiven) > > Both solutions use a simple and naive implementation, which makes them > easy to > use and admin. However, it gives the responsibilities to the admin to deal > with > fencing, which is a mandatory piece in almost all kind of DB cluster if you > want to cover most of the failure cases and avoid split brain. > > So yes, they are simple, because complexity is left to the admin skills. It > kind of require you rewrote and test yourself part of the fencing stack of > Pacemaker. Good luck. > > And I'm not speaking about watchdog here, which I just fail to imagine how > the > admin could implement it himself. > > Just consider how messy it is to deal with "logical fencing" when > considering > doing it with pgbouncer. > > In short: if you are ready to spend many dev/admin hours to build a safe HA > cluster for your DB and set strict requirements, those are fine. > > > About PAF, the product is hard to install and set up . It need a linux > > cluster and a system engineers team to use it. > > Indeed, Pacemaker has a steep learning cuve and documentation still > requires > some improvement. But HA is not an easy subject. Just look at RHEL or Suse > requirements before their team accept to support your DB cluster (spoiler: > fencing). > > Whatever solution you pick, you must **know and document** its limitations > and > risks. >
