The problem with infinity is that the moment when the node is back - there will be a second failover. This is bad for bulky DBs that power down/up more than 30 min (15 min down, 15 min up).
Best Regards, Strahil Nikolov В четвъртък, 3 декември 2020 г., 10:32:18 Гринуич+2, Andrei Borzenkov <arvidj...@gmail.com> написа: On Thu, Dec 3, 2020 at 11:11 AM Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> wrote: > > >>> Strahil Nikolov <hunter86...@yahoo.com> schrieb am 02.12.2020 um 22:42 in > Nachricht <311137659.2419591.1606945369...@mail.yahoo.com>: > > Constraints' values are varying from: > > infinity which equals to score of 1000000 > > to: > > - infinity which equals to score of -1000000 > > > > You can usually set a positive score on the prefered node which is bigger > > than on the other node. > > > > For example setting a location constraint like this will prefer node1: > > node1 - score 10000 > > node2 - score 5000 > > > > The bad thing with those numbers is that you are never sure which number to > use: > Is 50 enough? 100 Maybe? 1000? 10000? 100000? > +INFINITY score guarantees that resource will always be active on preferred node as long as this node is available but allow resource to be started on another node if preferred node is down. ... > > I believe I used the value infinity, so it will prefer the 2nd host over > > the 1st if at all possible. My 'pcs constraint': > > And this was the very first answer to this question. > > [root@centos-vsa2 ~]# pcs constraint > > Location Constraints: > > Resource: group-zfs > > Enabled on: centos-vsa2 (score:INFINITY) > > Ordering Constraints: > > Colocation Constraints: > > Ticket Constraints: > > _______________________________________________ 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/
