[ClusterLabs] PAF with postgresql 13?

[CHAMPAGNE Julie]

Wow !! It seems to work now! 

I didn't know the arguments order was so important. I should have read the doc at first! Thank you so much!!

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?

Thanks

-----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,