Re: increasing HA - Mailing list pgsql-general
| From | Thomas Poty |
|---|---|
| Subject | Re: increasing HA |
| Date | |
| Msg-id | CAN_ctngdTdD5iEQDquBjfSoyea1sFOQSgWFXBXK_F3f9SOM7fg@mail.gmail.com Whole thread Raw |
| In response to | Re: increasing HA ("Jehan-Guillaume (ioguix) de Rorthais" <ioguix@free.fr>) |
| Responses |
Re: increasing HA
("Jehan-Guillaume (ioguix) de Rorthais" <ioguix@free.fr>)
|
| List | pgsql-general |
> In fact, PAF does not support slots. So it is not a good candidate if slot are
> a requirement.
> > 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 ?
> If you want a simple and well community adopted solution, pick Patroni. It deals
> with slots, rely on etcd or zookeeper, fit nicely with haproxy, deal with
> watchdog to keep itself under monitor. However, it lacks of fencing and its
> callback are asynchronous. You would have to take special care of your
> network and master connectivity upon primary failure.
> If you want something able to keep multiple services avaliable (PostgreSQL, vIP,
> storage, pgBouncer, apache, whatever...), deal with dependencies, locations,
> constraints, rules etc, pick Pacemaker (and a larger coffee machine). I would
> (obviously) recommend PAF as resource agent for PgSQL, but you would have to
> a requirement.
Effectively slots are a requirement we prefer to keep
> > a proxy HAproxy and
> > for fencincg, i am a bit disappointed, i don't know what to do/use
> Depend on your hardware or your virtualization technology.
Our production cluster (master and slave) runs on LXC container. Each LXC container runs on a HPE Blade Server. The storage is on a SAN 3PAR array.
Any advice ?
> > How about you, do you have any preference about tools/solutions to use ?
> If you want a simple and well community adopted solution, pick Patroni. It deals
> with slots, rely on etcd or zookeeper, fit nicely with haproxy, deal with
> watchdog to keep itself under monitor. However, it lacks of fencing and its
> callback are asynchronous. You would have to take special care of your
> network and master connectivity upon primary failure.
I am looking after some infrmation about this solution on their doc/irc...
Your opinion about it is important for me by knowing you maintain PAF :-)
> storage, pgBouncer, apache, whatever...), deal with dependencies, locations,
> constraints, rules etc, pick Pacemaker (and a larger coffee machine). I would
> (obviously) recommend PAF as resource agent for PgSQL, but you would have to
> design your cluster without slots :/
many thanks
Le mer. 5 sept. 2018 à 14:15, Jehan-Guillaume (ioguix) de Rorthais <ioguix@free.fr> a écrit :
On Wed, 5 Sep 2018 13:23:41 +0200
Thomas Poty <thomas.poty@gmail.com> wrote:
> Hi Jehan-Guillaume,
Hello,
> Thanks for your opinion.
>
> At first glance, i may use for automatic failover PAF,
In fact, PAF does not support slots. So it is not a good candidate if slot are
a requirement.
> a proxy HAproxy and
> for fencincg, i am a bit disappointed, i don't know what to do/use
Depend on your hardware or your virtualization technology.
> How about you, do you have any preference about tools/solutions to use ?
If you want a simple and well community adopted solution, pick Patroni. It deals
with slots, rely on etcd or zookeeper, fit nicely with haproxy, deal with
watchdog to keep itself under monitor. However, it lacks of fencing and its
callback are asynchronous. You would have to take special care of your
network and master connectivity upon primary failure.
If you want something able to keep multiple services avaliable (PostgreSQL, vIP,
storage, pgBouncer, apache, whatever...), deal with dependencies, locations,
constraints, rules etc, pick Pacemaker (and a larger coffee machine). I would
(obviously) recommend PAF as resource agent for PgSQL, but you would have to
design your cluster without slots :/
++
pgsql-general by date: