• 2 replies
  • Latest Post - ‏2012-02-14T13:04:05Z by jmblaise
2 Posts

Pinned topic Request=Lock Control=SuspendedPropagated not lifted ...

‏2012-02-14T10:08:40Z |

I am using TSA 3.2.1 FP3 and DB2 9.7 FP5 on Linux. HADR + TSA are working originally fine. tstdb21c2 is originally the primary.

I did the following test:
  • interrupt the network on tstdb21c2 (ifdown eth1).
  • tstdb21c1 becomes the primary
  • tstdb21c2 correctly reboots, and becomes the standby, however, the HADR resource is not restarted automatically. I therefore did a DB2 ACTIVATE DB <DB>.

My problem: when doing an lssam, I am still in Lock + SuspendedPropagated status when I would expect this to be solve. From a DB2 HADR point of view, I am in peer status so everything is fine.

Online IBM.ResourceGroup:db2_o7d1_o7d1_O7D1-rg Request=Lock Control=SuspendedPropagated Nominal=Online
|- Online IBM.Application:db2_o7d1_o7d1_O7D1-rs Control=SuspendedPropagated
|- Online IBM.Application:db2_o7d1_o7d1_O7D1-rs:tstdb21c1
'- Offline IBM.Application:db2_o7d1_o7d1_O7D1-rs:tstdb21c2
'- Online IBM.ServiceIP:db2ip_10_240_129_209-rs Control=SuspendedPropagated
|- Online IBM.ServiceIP:db2ip_10_240_129_209-rs:tstdb21c1
'- Offline IBM.ServiceIP:db2ip_10_240_129_209-rs:tstdb21c2
Online IBM.ResourceGroup:db2_o7d1_tstdb21c1_0-rg Nominal=Online
'- Online IBM.Application:db2_o7d1_tstdb21c1_0-rs
'- Online IBM.Application:db2_o7d1_tstdb21c1_0-rs:tstdb21c1
Online IBM.ResourceGroup:db2_o7d1_tstdb21c2_0-rg Nominal=Online
'- Online IBM.Application:db2_o7d1_tstdb21c2_0-rs
'- Online IBM.Application:db2_o7d1_tstdb21c2_0-rs:tstdb21c2
Online IBM.Equivalency:db2_o7d1_o7d1_O7D1-rg_group-equ
|- Online IBM.PeerNode:tstdb21c2:tstdb21c2
'- Online IBM.PeerNode:tstdb21c1:tstdb21c1
Online IBM.Equivalency:db2_o7d1_tstdb21c1_0-rg_group-equ
'- Online IBM.PeerNode:tstdb21c1:tstdb21c1
Online IBM.Equivalency:db2_o7d1_tstdb21c2_0-rg_group-equ
'- Online IBM.PeerNode:tstdb21c2:tstdb21c2
Online IBM.Equivalency:db2_public_network_0
|- Online IBM.NetworkInterface:eth1:tstdb21c1
'- Online IBM.NetworkInterface:eth1:tstdb21c2

Any thoughts ?

Regards, JMB
Updated on 2012-02-14T13:04:05Z at 2012-02-14T13:04:05Z by jmblaise
  • Enrico_Joedecke
    121 Posts

    Re: Request=Lock Control=SuspendedPropagated not lifted ...


    with DB2 V9.7 the 'lock' / 'unlock' is initiated with an API call from the DB2 itself (with older DB2 releases, the lock/unlock commands were included within the policy commands - hadr_monitor.ksh).

    Given this I suggest to check the db2 logs for further information (e.g. db2diag.log).

    Enrico Joedecke
  • jmblaise
    2 Posts

    Re: Request=Lock Control=SuspendedPropagated not lifted ...

    Hi Enrico,

    Thanks ! From the db2diag.log, it appears that the old primary, became a standby and cannot reconciliate with the new primary. Therefore I have to reconstruct the standby.

    This is strange, because the 2 servers where in peer when I put down eth1, so I will try redo this test to understand further this issue.