<html><body><p><font size="2">Hello Ondrej,</font><br><br><font size="2"> I am still having issues with my DB2 HADR on Pacemaker. When I do a db2_kill on Primary for testing, initially it does a restart of DB2 on the same node. But if I let it run for some days and then try the same test, it goes into fencing and then reboots the Primary Node. </font><br><br><font size="2" face="Arial"> I am not sure how exactly it should behave in case my DB2 crashes on Primary. </font><br><br><font size="2" face="Arial"> Also if I crash the Node 1 (the node itself, not only DB2), it promotes Node 2 to Primary, but once the Pacemaker is started again on Node 1, the DB on Node 1 is also promoted to Primary. Is that expected behaviour ?<br></font><table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="650" valign="bottom"><font size="2" face="Arial">Regards,</font><br><br><b><font color="#888888" face="Arial">Dileep V Nair</font></b><font size="2" face="Arial"><br>Senior AIX Administrator<br>Cloud Managed Services Delivery (MSD), India<br>IBM Cloud</font></td></tr></table>
<table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="650" colspan="2" valign="middle"><hr width="100%" size="2" align="left"></td></tr>
<tr valign="top"><td width="401"><b><font size="1" color="#466BB0" face="Arial">E-mail:</font></b><font size="1" color="#5F5F5F" face="Arial"> </font><a href="mailto:dilenair@in.ibm.com" target="_blank"><u><font size="1" color="#5F5F5F" face="Arial">dilenair@in.ibm.com</font></u></a></td><td width="249"><div align="right"><font size="1" color="#5F5F5F" face="Arial">Outer Ring Road, Embassy Manya<br>Bangalore, KA 560045<br>India</font></div></td></tr></table><br><br><img width="16" height="16" src="cid:1__=EABB08AADFDD456B8f9e8a93df938690918cEAB@" border="0" alt="Inactive hide details for Ondrej Famera ---02/12/2018 11:46:01 AM---On 02/01/2018 07:24 PM, Dileep V Nair wrote: > Thanks Ondre"><font size="2" color="#424282">Ondrej Famera ---02/12/2018 11:46:01 AM---On 02/01/2018 07:24 PM, Dileep V Nair wrote: > Thanks Ondrej for the response. I have set the PEER_W</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Ondrej Famera <ofamera@redhat.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Dileep V Nair <dilenair@in.ibm.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Cluster Labs - All topics related to open-source clustering welcomed <users@clusterlabs.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">02/12/2018 11:46 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [ClusterLabs] Issues with DB2 HADR Resource Agent</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">On 02/01/2018 07:24 PM, Dileep V Nair wrote:<br>> Thanks Ondrej for the response. I have set the PEER_WINDOWto 1000 which<br>> I guess is a reasonable value. What I am noticing is it does not wait<br>> for the PEER_WINDOW. Before that itself the DB goes into a<br>> REMOTE_CATCHUP_PENDING state and Pacemaker give an Error saying a DB in<br>> STANDBY/REMOTE_CATCHUP_PENDING/DISCONNECTED can never be promoted.<br>> <br>> <br>> Regards,<br>> <br>> *Dileep V Nair*<br><br>Hi Dileep,<br><br>sorry for later response. The DB2 should not get into the<br>'REMOTE_CATCHUP' phase or the DB2 resource agent will indeed not<br>promote. From my experience it usually gets into that state when the DB2<br>on standby was restarted during or after PEER_WINDOW timeout.<br><br>When the primary DB2 fails then standby should end up in some state that<br>would match the one on line 770 of DB2 resource agent and the promote<br>operation is attempted.<br><br> 770 STANDBY/*PEER/DISCONNECTED|Standby/DisconnectedPeer)<br><br></font></tt><tt><font size="2"><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ClusterLabs_resource-2Dagents_blob_master_heartbeat_db2-23L770&d=DwIDBA&c=jf_iaSHvJObTbx-siA1ZOg&r=syjI0TzCX7--Qy0vFS1xy17vob_50Cur84Jg-YprJuw&m=dhvUwjWghTBfDEHmzU3P5eaU9Ce3DkCRdRPNd71L1bU&s=3vPiNA4KGdZzc0xJOYv5hMCObjWdlxZDO_bLb86YaGM&e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ClusterLabs_resource-2Dagents_blob_master_heartbeat_db2-23L770&d=DwIDBA&c=jf_iaSHvJObTbx-siA1ZOg&r=syjI0TzCX7--Qy0vFS1xy17vob_50Cur84Jg-YprJuw&m=dhvUwjWghTBfDEHmzU3P5eaU9Ce3DkCRdRPNd71L1bU&s=3vPiNA4KGdZzc0xJOYv5hMCObjWdlxZDO_bLb86YaGM&e=</a></font></tt><tt><font size="2"><br><br>The DB2 on standby can get restarted when the 'promote' operation times<br>out, so you can try increasing the 'promote' timeout to something higher<br>if this was the case.<br><br>So if you see that DB2 was restarted after Primary failed, increase the<br>promote timeout. If DB2 was not restarted then question is why DB2 has<br>decided to change the status in this way.<br><br>Let me know if above helped.<br><br>-- <br>Ondrej Faměra<br>@Red Hat<br><br></font></tt><br><br><BR>
</body></html>