<div dir="ltr"><div dir="ltr">On Tue, Jan 24, 2023 at 8:41 AM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Under some circumstances the faulty node can cause disruption of service.<br>
> This is especially the case when a link between nodes is unreliable. For<br>
> example, we've seen problems when one of the interlinks is not working<br>
> (i.e. node 1 and node 2 cannot communicate with each other, but can both<br>
> communicate with node 0). Such a scenario can cause various different<br>
> failures. Temporarily taking a node out of the cluster allows for the<br>
> administrators to troubleshoot the issue without having to worry about<br>
> causing interference on the service.<br>
<br>
The problem description is too vague. Please provide concrete example<br>
of the problem.<br></blockquote><div><br></div><div>I understand. I think the case below is much more concrete: a server is being decommissioned to be replaced by a new server. First adding the new server and then removing the old one.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Another case we've seen is where one of the nodes needs to be migrated to a<br>
> different site. If it is not possible to perform a live migration of the<br>
> VM, the second best alternative is to first add a new node to the cluster<br>
> and then remove the old one. The same steps need be performed when a vm<br>
> host has had a catastrophic hardware failure and a node is lost<br>
> permanently. Our entire software stack, with the exception of pgpool,<br>
> supports performing these kinds of modifications without introducing any<br>
> downtime.<br>
<br>
Pgpool-II consists of many child process. Each process handles a user<br>
session and multiple backends. There are tons of places in the child<br>
process something like:<br>
<br>
for (i = 0; i < number_of_backends ; i++)<br>
{<br>
        do something...<br>
}<br>
<br>
If the backend configuration has been changed in the middle of the<br>
loop, the code will produce unpredictable errors. To prevent that, we<br>
need to handle the loop as a critical section, which requires a<br>
locking. This will cause serious performance degradation due to the lock<br>
contention.<br></blockquote><div><br></div><div>I understand, and I don't mind having to restart a single pgpool instance to fully reload the configuration. However, in the current situation, this causes miscommunication between the restarted node and the other nodes that still run the old configuration. The only way to fix that, is to stop all pgpool instances and then start them again, but that will cause a major disruption of service.</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">
Note that adding new backend is possible without restarting<br>
pgpool,i.e. by reloading the configuration file. For example if you<br>
have 3 backends (0, 1 and 2) and want to remove backend 1,<br>
<br>< cut steps for adding a new backend ><br>
7) optionaly you can remove backend 1 configuration<br>
   parameters. "status" columbn of show pool_nodes will be "unused" after<br>
   restarting pgpool.</blockquote><div><br></div><div>We've tried leaving holes in the numbering initially, but something didn't work out as expected. Unfortunately, I don't remember the exact problem. Maybe it had to do with each node also running a pgpool instance and gaps were not allowed in the watchdog config (like hostname0)? I'll try a build without the renumbering and report back with the findings. If we can indeed leave gaps in the backend numbering, that would probably fix the issue for us. I'm not yet sure what to do with the watchdogs though.</div><div><br></div><div>Best regards,</div><div>Emond</div></div></div>