<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 6, 2023 at 8:46 AM Sergey Cherukhin <<a href="mailto:sergey.cherukhin@gmail.com">sergey.cherukhin@gmail.com</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"><div dir="ltr"><div dir="ltr">Hello!</div><div dir="ltr"><br></div><div dir="ltr">I used Microsoft Outlook to send this message and it was sent in the wrong format. I'm sorry. I won't do it again.<br> <br>I use Postgresql+Pacemaker+Corosync cluster with 2 Postgresql instances in synchronous replication mode. Parameter “rep_mode” is set to "sync", and when I shut down the replica normal way, the primary node  switches to the async mode. But when I  shut down the replica by powering it off to emulate power unit failure, primary remains in sync mode and clients hang on INSERT operations  until "pcs resource cleanup" is performed.  I created an alert agent to run "pcs resource cleanup" when any node is lost, but this approach doesn’t work.<br> <br>What should I do to be sure the primary node will switch to async mode if the replica becomes lost for any cause?</div></div></blockquote><div><br></div><div>One idea might be running (a) small daemon(s) colocated with the Postgresql instance(s) that uses pacemaker-tooling to check</div><div>for the state of the partner-node and if it isn't there switches to async mode. You can solve this as a small custom Resource-Agent.</div><div>Actually it wouldn't even be necessary to have a persistently running process - could be done in the monitoring as well.</div><div>Of course you could enhance monitoring of Postgresql Resource-Agent as that it supports this switching.</div><div>As this would be quite a generic change it would probably be interesting for the community as well.</div><div><br></div><div>On the other hand I would have considered this issue so generic that it is hard to believe that there is no ready made / tested</div><div>solution around already.</div><div><br></div><div>To get it more reactive (without setting the monitoring-interval to incredibly low values) using an alert-agent (as you already tried)</div><div>but maybe directly switching to async-mode might be worthwhile trying.</div><div>Did you investigate what did actually go wrong when you made experiments with the alert-agent? Interesting that the</div><div>resource cleanup that obviously works from the cmdline doesn't do the trick when run as alert-agent - maybe an selinux issue ...</div><div><br></div><div>Regards,</div><div>Klaus </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"> <br> <br>Best regards,<br>Sergey Cherukhin<br> <br></div></div>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
</blockquote></div></div>