Vitaly,
I forgot to mention that the described behavior of preferring new role
names in CIB only applies to pcs-0.11. On the other hand, pcs-0.10
prefers to put old role names into CIB.
Tomas
Dne 11. 04. 25 v 21:55 vitaly napsal(a):
Tomas,
Our cib is at 3.8 as you can see below.
pcs constraint shows correct Promoted and cib shows Master (from older
configuration before system upgrade).
If I remove constraints and add them again they will show Promoted in
cibadmin on most of the systems, but I did have cases when it still
was showing Master.
The good thing is that after removing and re-adding constraints we can
reconfigure postgres without failures in constraints but we will have
to find a better way to confirm that.
I do not want to take more of your time on this (unless you are
interested in fixing inconsistency). We will try to hook to the name
of the constraint in cibadmin instead of the role.
Thanks again!
_Vitaly
module-248 ~ # pcs cluster cib | head -n 2
<cib crm_feature_set="3.15.0" validate-with="pacemaker-3.8" epoch="55"
num_updates="23" admin_epoch="1" cib-last-written="Fri Apr 11 18:12:38
2025" update-origin="module-248" update-client="cibadmin"
update-user="root" have-quorum="1" dc-uuid="1">
<configuration>
module-248 ~ # pcs constraint config | grep -w Promoted
Started resource 'DBSlave' with Promoted resource 'postgres-ms'
Started resource 'DBMaster' with Promoted resource 'postgres-ms'
module-248 ~ # pcs constraint config | grep -w Master
module-248 ~ # cibadmin --query | grep -w Master
<op id="postgres-monitor-interval-5s" interval="5s"
name="monitor" on-fail="restart" role="Master" timeout="300s"/>
<rsc_colocation id="colocation-DBSlave-postgres-ms-Master"
rsc="DBSlave" rsc-role="Started" score="-10000" with-rsc="postgres-ms"
with-rsc-role="Master"/>
<rsc_colocation id="colocation-DBMaster-postgres-ms-Master"
rsc="DBMaster" rsc-role="Started" score="INFINITY"
with-rsc="postgres-ms" with-rsc-role="Master"/>
module-248 ~ # cibadmin --query | grep -w Promoted
On 04/11/2025 5:28 AM EDT Tomas Jelinek <tojel...@redhat.com> wrote:
Hi Vitaly,
New role names are supported in CIB schema 3.7. If your CIB hasn't
been updated to at least that version of the schema, then pcs has no
choice other than to put the old role names into CIB.
To see your CIB schema version, run 'pcs cluster cib | head' and
check the value of validate-with attribute of the root xml element.
To update CIB to a newer schema, run 'pcs cluster cib-upgrade'.
Regards,
Tomas
Dne 10. 04. 25 v 14:31 vitaly napsal(a):
Hi Tomas.
Thank you very much for clarification.
The only reason I worry is that the script that I am running is
supposed to run on the client systems. After the "fix" where I
remove old constraints and create new ones I run another check to
confirm that old settings are gone and will not cause any issues
after upgrade.
If this check comes back with old values I am issuing a warning that
configuration "may" need to be updated.
Below is condensed list of commands I use to replace the old with new.
In any case, if pcs constraints list always shows new values I could
use it instead of cibadmin to verify correct values.
pcs constraint colocation remove DBMaster postgres-ms
pcs constraint colocation remove DBSlave postgres-ms
pcs constraint colocation add DBMaster with Promoted postgres-ms
INFINITY id=colocation- DBMaster-postgres-ms-Promoted
pcs constraint colocation add DBSlave with Promoted postgres-ms
"-10000" id=colocation- DBSlave-postgres-ms-Promoted
pcs resource op delete postgres-monitor-interval-5s
pcs resource op add postgres monitor interval=5s timeout=300s
on-fail=restart role=Promoted
Thank you very much for your help!
_Vitaly
On 04/10/2025 5:17 AM EDT Tomas Jelinek <tojel...@redhat.com> wrote:
Hi Vitaly,
You don't need to worry much about this.
When pcs is editing CIB, it prefers using the new role names and
automatically falls back to the old role names based on pacemaker /
CIB schema version. When pcs is printing the configuration, it does
a reverse transformation and prints the new role names even if CIB
contains the old ones.
Pacemaker 2.1, which pcs 0.11 is compatible with, is capable of
handling both old and new role names.
If you want to get rid of the old role names, you may replace them
in CIB ('pcs cluster edit') or drop the constraints and recreate
them using pcs. If it fails, you maybe have an old CIB version. You
can update that with 'pcs cluster cib-upgrade'.
Regards,
Tomas
Dne 09. 04. 25 v 20:35 vitaly napsal(a):
Hello,
I have dual node clusters with postgres as one of the resources.
The clusters were upgraded from pcs v 0.10 to pcs v 0.11.
Pcs V 0.11 eliminated Master role and replaced it with Promoted.
For clusters that were upgraded I needed to remove old
configuration for colocation because with old one in place while
creating new one commit of the configuration was failing due to
duplicate constraint.
Update works fine on all the clusters but on one of them AFTER
UPGRADE I see different output in “cibadmin --query” and in “pcs
constraint list”
The constraints in “cibadmin –query” are showing:
<rsc_colocation rsc="DBSlave" with-rsc="postgres-ms"
score="-10000" rsc-role="Started" with-rsc-role="Master"
id="colocation-DBSlave-postgres-ms-Promoted"/>
<rsc_colocation rsc="DBMaster" with-rsc="postgres-ms"
score="INFINITY" rsc-role="Started" with-rsc-role="Master"
id="colocation-DBMaster-postgres-ms-Promoted"/>
Same constraints in “pcs constraint list” were showing:
Colocation Constraints:
Started resource 'DBSlave' with Promoted resource
'postgres-ms' score=-10000
Started resource 'DBMaster' with Promoted resource
'postgres-ms' score=INFINITY
On all other systems “cibadmin –query” is in agreement with pcs
and shows:
<rsc_colocation rsc="DBSlave" with-rsc="postgres-ms"
score="-10000" rsc-role="Started" with-rsc-role="Promoted"
id="colocation-DBSlave-postgres-ms-Promoted"/>
<rsc_colocation rsc="DBMaster" with-rsc="postgres-ms"
score="INFINITY" rsc-role="Started" with-rsc-role="Promoted"
id="colocation-DBMaster-postgres-ms-Promoted"/>
So my problem is in with-rsc-role showing “Master” on a single
system and “Promoted” on all others.
Would appreciate it if anybody could shed some light on the issue.
Thank you very much!
_Vitaly
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home:https://www.clusterlabs.org/
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
