You can bump the 'token' to a higher value (for example 10s ) and adjust the
consensus based on that value. See man 5 corosync.conf
Don't forget to sync the nodes and reload the corosync stack.
Of course proper testing on non-Prod is highly recommend.
Note: Both parameters use milliseconds (at least based on the manpage)
Best Regards,Strahil Nikolov
On Wed, Mar 9, 2022 at 12:46, FLORAC Thierry<thierry.flo...@onf.fr> wrote:
#yiv4997566984 P {margin-top:0;margin-bottom:0;}Hi,
I manage an active/passive PostgreSQL cluster using DRBD, LVM, Pacemaker and
Corosync on a Debian GNU/Linux operating system.Everything is OK, but my
platform seems to be quite "sensitive" to small network timeouts which are
generating a cluster migration start from active to passive node; generally,
the process doesn't go through to the end: as soon as the connection is back
again, the migration is cancelled and the database restarts!That should be OK
but on the application side, some database connections (on a Java WildFly
server) can become "invalid"! So I would like to avoid these migrations when
this kind of small timeout occurs...
So my question is: which cluster settings can I change to increase the timeout
before starting a cluster migration?
Best regards,Thierry
Thierry Florac
Resp. Pôle Architecture Applicative et Mobile
DSI - Dépt. Études et Solutions Tranverses
2, avenue de Saint-Mandé - 75570 Paris cedex 12
Tél : 01 40 19 59 64
www.onf.fr
_______________________________________________
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/
