[ClusterLabs] Antw: Re: Antw: [EXT] Cluster timeout

[Ulrich Windl]

>>> FLORAC Thierry <thierry.florac at onf.fr> schrieb am 09.03.2022 um 16:56 in
Nachricht
<PR2P264MB07678DBB0517CB8C7695627CF50A9 at PR2P264MB0767.FRAP264.PROD.OUTLOOK.COM>:

>>>> FLORAC Thierry <thierry.florac at onf.fr> schrieb am 09.03.2022 um 11:46 in
> Nachricht
>
<PR2P264MB076751671FC57F33B995F851F50A9 at PR2P264MB0767.FRAP264.PROD.OUTLOOK.CO

> M>:
> 
>> 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!
> 
> Could it be you run without fencing? Maybe show some logs!
> 
> Logs are quite verbose and not very easy to understand...
> What log would you need?

Those showing what happens when the network goes down, and what happens when
the network comes up.
Usually the DC writes some good "action summaries" (typically after
"pacemaker-controld[7236]:  notice: State transition S_IDLE ->
S_POLICY_ENGINE"). Those would be helpful.

> 
>> 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 <https://www.onf.f<https://www.onf.fr>r