[ClusterLabs] Issues with DB2 HADR Resource Agent

Dileep V Nair dilenair at in.ibm.com
Thu Feb 1 05:24:22 EST 2018

Thanks Ondrej for the response. I have set the PEER_WINDOW to 1000 which I
guess is a reasonable value. What I am noticing is it does not wait for the
PEER_WINDOW. Before that itself the DB goes into a REMOTE_CATCHUP_PENDING
state and Pacemaker give an Error saying a DB in

 Dileep V Nair                                                                     
 Senior AIX Administrator                                                          
 Cloud Managed Services Delivery (MSD), India                                      
 IBM Cloud                                                                         
 E-mail: dilenair at in.ibm.com                         Outer Ring Road, Embassy Manya 
                                                               Bangalore, KA 560045 

From:	Ondrej Famera <ofamera at redhat.com>
To:	Dileep V Nair <dilenair at in.ibm.com>
Cc:	Cluster Labs - All topics related to open-source clustering
            welcomed <users at clusterlabs.org>
Date:	02/01/2018 02:48 PM
Subject:	Re: [ClusterLabs] Issues with DB2 HADR Resource Agent

On 02/01/2018 05:57 PM, Dileep V Nair wrote:
> Now the second issue I am facing is that when I crash the node were DB
> is primary, the STANDBY DB is not getting promoted to PRIMARY. I could
> fix that by adding below lines in db2_promote()
> 773 *)
> 774 # must take over forced
> 775 force="by force"
> 776
> 777 ;;
> But I am not sure of the implications that this can cause.
> Can someone suggest whether what I am doing is correct OR will this lead
> to any Data loss.

Hi Dileep,

As for the 'by force' implications you may check the documentation on
what it brings. In short: the data can get corrupted.


The original 'by force peer window only' is limiting the takeover to
period when DB2 is within PEER_WINDOW which gives a bit more safety.
(the table in link above also explains how much safer it is)

Instead of changing the resource agent I would rather suggest checking
the PEER_WINDOW and HADR_TIMEOUT variables in DB2. They determine how
long it is possible to do takeover 'by force peer window only'.

Ondrej Faměra
@Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180201/1231f1bf/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180201/1231f1bf/attachment-0002.gif>

More information about the Users mailing list