[ClusterLabs] PAF with postgresql 13?
Jehan-Guillaume de Rorthais
jgdr at dalibo.com
Tue Mar 8 09:02:19 EST 2022
On Tue, 8 Mar 2022 12:28:06 +0000
CHAMPAGNE Julie <julie.champagne at pm.gouv.fr> wrote:
> I didn't know the arguments order was so important. I should have read the
> doc at first! Thank you so much!!
You're welcome.
> Oh and just a last question, is there a way to prefer node1 as master for the
> resource pgsqld? I probably need to define a score on it?
I would recommend to keep the cluster symmetric to keep things simple and
reproducible. It's important. Moving the primary from a node to the other is
simple et fast enough to do it by hand with these two commands:
pcs resource move --wait --master pgsqld-clone
pcs resource clear pgsqld-clone
This admin cookbook is a bit outdated, but should be useful enough with no or
little changes:
https://clusterlabs.github.io/PAF/CentOS-7-admin-cookbook.html
See chapter "Swapping primary and standby roles between nodes".
Make sure to read this page as well:
https://clusterlabs.github.io/PAF/administration.html
Regards,
> -----Message d'origine-----
> De : Jehan-Guillaume de Rorthais <jgdr at dalibo.com>
> Envoyé : mardi 8 mars 2022 11:21
> À : CHAMPAGNE Julie <julie.champagne at pm.gouv.fr>
> Cc : Cluster Labs - All topics related to open-source clustering welcomed
> <users at clusterlabs.org> Objet : Re: [ClusterLabs] PAF with postgresql 13?
>
> Hi,
>
> On Tue, 8 Mar 2022 08:00:22 +0000
> CHAMPAGNE Julie <julie.champagne at pm.gouv.fr> wrote:
>
> > I've created the ressource pgsqld as follow (don't think the cluster
> > creation command is necessary):
> >
> > pcs resource create pgsqld ocf:heartbeat:pgsqlms promotable \
>
> The problem is here. The argument order given to pcs is important. Every
> argument after "promotable" are interpreted as clone attributes. From the
> manpage:
>
> promotable [<clone id>] [<promotable options>]
>
> The "promotable" should appear at the end, just before the "meta notify=true".
>
> > PGDATA=/var/lib/postgresql/13/main \
> > bindir=/usr/lib/postgresql/13/bin \
> > start_opts="-c
> > config_file=/var/lib/postgresql/13/main/postgresql.conf" \
>
> Because of "promotable" appearing in front of these argument, they are read
> as clone attribute (for "pgsqld-clone"), where they should really be read as
> resource attribute (for "pgsqld").
>
> (NB: I'm surprised by your "postgresql.conf" path under Debian, is it on
> purpose?)
>
> > op start timeout=60s \
> > op stop timeout=60s \
> > op promote timeout=30s \
> > op demote timeout=120s \
> > op monitor interval=15s timeout=10s role="Master" meta master-max=1 \
> > op monitor interval=16s timeout=10s role="Slave" \ op notify
> > timeout=60s meta notify=true
>
> Because "op" appears, we are back in resource ("pgsqld") context, anything
> after is interpreted as ressource and operation attributes, even the "meta
> notify=true". That's why your pgsqld-clone doesn't have the meta attribute
> "notify=true" set.
>
> This argument ordering is kind of disturbing. You might prefer the alternate
> two commands form to create first "pgsqld", then "pgsqld-clone", each with
> their expected argument:
>
> pcs cluster cib cluster3.xml
>
> pcs -f cluster3.xml resource create pgsqld ocf:heartbeat:pgsqlms \
> pgdata="/etc/postgresql/13/main" \
> bindir="/usr/lib/postgresql/13/bin" \
> datadir="/var/lib/postgresql/13/main" \
> op start timeout=60s \
> op stop timeout=60s \
> op promote timeout=30s \
> op demote timeout=120s \
> op monitor interval=15s timeout=10s role="Master" \
> op monitor interval=16s timeout=10s role="Slave" \
> op notify timeout=60s
>
> pcs -f cluster3.xml resource promotable pgsqld pgsqld-clone \
> meta notify=true
>
> [...other pcs commands for other constraints...]
>
> pcs cluster cib-push scope=configuration cluster3.xml
>
> By the way, these commands has been adapted from the one-form command detailed
> here: https://clusterlabs.github.io/PAF/Quick_Start-Debian-10-pcs.html
>
> Make sure to read/adapt from this page.
>
> > BTW, I had to edit the file /usr/lib/ocf/resource.d/heartbeat/pgsqlms
> > because the default values of bindir, pgdata didn't match the
> > Debian/postgresql default settings:
> >
> > # Default parameters values
> > my $system_user_default = "postgres";
> > my $bindir_default = "/usr/lib/postgresql/13/bin";
> > my $pgdata_default = "/var/lib/postgresql/13/main";
>
> You might now understand you should not have to edit these fields if the
> resource are correctly setup :)
>
> Regards,
More information about the Users
mailing list