<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 18, 2023 at 6:37 PM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On Tue, Jan 17, 2023 at 6:49 PM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>> wrote:<br>
> <br>
>> Hi Usama,<br>
>><br>
>> Thank you for investigating the issue.<br>
>><br>
>> > Hi Ishii San<br>
>> ><br>
>> > Thanks for figuring out the issue.<br>
>> > I think removing the code in question altogether could mark the remote<br>
>> node<br>
>> > as dead too early at startup and can delay the watchdog cluster<br>
>> > stabilization<br>
>> > when there is a few seconds delay between the node startup.<br>
>> > So IMHO the way to solve this is to wait for twice the wd_interval or<br>
>> > wd_heartbeat_deadtime (depending on the configuration) if<br>
>> > is_wd_lifecheck_ready()<br>
>> > reports a failure.<br>
>> ><br>
>> > What do you think of the attached patch?<br>
>><br>
>> Probably I am missing something but I wonder why the watchdog leader<br>
>> node's lifecheck does not notice that node 1 watchdog will never send<br>
>> hearbeat signal. In the pgpool0 log:<br>
>><br>
>> 2023-01-14 00:27:15: watchdog pid 26708: LOG:  read from socket failed,<br>
>> remote end closed the connection<br>
>> 2023-01-14 00:27:15: watchdog pid 26708: LOG:  client socket of<br>
>> localhost:50004 Linux abf1b59af489 is closed<br>
>> 2023-01-14 00:27:15: watchdog pid 26708: LOG:  remote node<br>
>> "localhost:50004 Linux abf1b59af489" is shutting down<br>
>> 2023-01-14 00:27:15: watchdog pid 26708: LOG:  removing watchdog node<br>
>> "localhost:50004 Linux abf1b59af489" from the standby list<br>
>><br>
>> It seems the leader watchdog alreay noticed that node 1 was down.<br>
>><br>
> <br>
> When the watchdog fails to communicate with a remote node despite retries,<br>
> it marks the node status to lost/down. As for the lifecheck<br>
> process, it only informs the node-down status to the watchdog process when<br>
> the heartbeat breaks after at least one successful heartbeat cycle<br>
> is completed.<br>
<br>
I see.<br>
<br>
I would like to confirm if my understanding is correct.<br>
<br>
There are 3 nodes configured. Node 0 and 1 started but node 2 did not<br>
start.  In this case I think lifecheck does not start on node 0 and<br>
node 1 because lifecheck process is waiting for node 2 comes up.<br></blockquote><div><br></div><div>Apparently that is the behavior, and that is wrong.</div><div><br></div><div>Regards</div><div>Muhammad Usama</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best reagards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS LLC<br>
English: <a href="http://www.sraoss.co.jp/index_en/" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en/</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
</blockquote></div></div>