DB2 HADR and ACR problem V9.5 on Redhat

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • tensi4u
    New Member
    • Nov 2007
    • 11

    DB2 HADR and ACR problem V9.5 on Redhat

    Hi,
    I'm running two db2s v9.5 (64bit) on Redhat (64bit). I thought I finished to set up HADR and ACR successfully with CLP, the status looked good Peer, Sync, Connected, etc,. from the get snapshot command.
    * I did it all with CLP, so I'm not useing DAS.

    -- First
    But, it doesn't seem HADR does work automatically in case of the event of failover, due to the test I killed the db2sysc process on primary. The primary was killed normally but the standby (it should be new primary) remained as "standby" in the "Remote catchup pending" status. In addition, I changed the option of db2iauto into "off" in order not to come up automatically due to split-brain.

    As I know, HADR would change the role smoothly when the "failover" occurs. Do I misunderstand about the HADR's feature?

    -- Second
    I would like to use ACR. I set alternate server on both side, primary and standby. Whenever killed db2 process (db2sysc), I received the SQL30081N error message. The client has the tcpip and db nodes of primary only. How can I verify ACR is working properly? Did I do something wrong or miss something?

    Thank you in advance.
  • docdiesel
    Recognized Expert Contributor
    • Aug 2007
    • 297

    #2
    Hi,

    HADR does not include an automatic failover or, to use HADR dictionary, takeover. You'll have to do it manually or use a cluster/heartbeat software to automate the takeover (e.g. Tivoli Systems Automation).

    Manual takeover may be done with the command

    Code:
    TAKEOVER HADR ON DATABASE mydbname [BY FORCE]
    Use the option BY FORCE only if you're sure the primary is as dead as a doornail and you want a quick takeover NOW.

    Don't use it if the primary is still alive and you want them to exchange roles e.g. for maintenance. This will tell the primary to become secondary and vice versa.

    Can't help you with ACR there, I'm sorry.

    Regards,

    Bernd


    P.S.: You'll find more info about the HADR takeover procedure here.
    Last edited by docdiesel; Feb 18 '08, 09:56 PM. Reason: Added Link to IBM doku

    Comment

    • tensi4u
      New Member
      • Nov 2007
      • 11

      #3
      Thanks Bernd, I didn't know that and found some documents related to that. It looks like it needs for me to do more jobs on this. :)

      Then, how do you handle existed or new user connections (requests) in case of the event of a failover without ACR?

      Thanks.

      Comment

      • docdiesel
        Recognized Expert Contributor
        • Aug 2007
        • 297

        #4
        Originally posted by tensi4u
        Thanks Bernd, I didn't know that and found some documents related to that. It looks like it needs for me to do more jobs on this. :)

        Then, how do you handle existed or new user connections (requests) in case of the event of a failover without ACR?

        Thanks.
        Morning,

        you'll need a v8 or newer DB2 client for accessing the database. When connecting, the client learns that the target database is a HADR one and already gets told the data (name, address, port etc.) of the takeover server/database - just in case. If the client fails retrieving data from the primary, it's assuming it dropped dead and tries to use the secondary (which hopefully already took over).

        If you switch primary/secondary for maintenance, the formerly primary will tell the client to use the other one.

        Perhaps I should add that if the client is a web application server using JDBC to connect to the database, you should catalog the remote database with the local client on the web app server and point the JNDI to that local catalog entry, not directly to the remote db.

        Regards,

        Bernd

        Comment

        Working...