Results 1 to 7 of 7
  1. #1
    Join Date
    Dec 2012
    Posts
    3

    How to achieve DB2 continous availibility

    Hi Im putting together a document which should outline options for DB2 AESE continous availibility.

    Currently we have some stuff on 8.2 which atm cannot be upgraded; and we have other stuff on DB2 9.7 which does have the option to be upgraded.

    We have two main sites which we would like to ensure complete synchronicity; the two sites are over 700km apart at approx 14ms round trip latency.

    What options are available to ensure continuous availibility?

  2. #2
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,428
    I guess it depends on what you mean by "continuous availability". There are many ways to skin this cat, including:
    - storage replication with OS active-passive clustering;
    - DB2 HADR;
    - DB2 Q Replication;
    - InfoSphere Change Data Capture;
    - log shipping.
    ---
    "It does not work" is not a valid problem statement.

  3. #3
    Join Date
    Dec 2012
    Posts
    3
    Quote Originally Posted by n_i View Post
    I guess it depends on what you mean by "continuous availability". There are many ways to skin this cat, including:
    - storage replication with OS active-passive clustering;
    - DB2 HADR;
    - DB2 Q Replication;
    - InfoSphere Change Data Capture;
    - log shipping.
    In the attachment I have outlined the existing set-up.
    Machine's 1 and 2 exist. 3 and 4 are what we want.

    Is it possible to do 'sync' from machine 1 to 2,3,4 without 'any' data loss whatsoever in the event of machine 1 failure using HADR on DB2 9.7 ?

    This is what i mean by continuous availibility:
    Continuous availability (CA) is defined as high availability extended to 365 days a year, 24 hours a day. CA combines the characteristics of continuous operations and high availability, to mask or eliminate all planned (scheduled) and unplanned (unscheduled) outages from the end user.
    Attached Thumbnails Attached Thumbnails config.jpg  

  4. #4
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,428
    Firstly, DB2 9.7 only supports one standby instance. You'll need to upgrade to DB2 10.1 to have 3 standby instances.

    Secondly, "no data loss whatsoever" implies that you would want to use SYNC or NEARSYNC mode, not ASYNC, which with 14 ms network latency will surely affect performance on the primary database.
    ---
    "It does not work" is not a valid problem statement.

  5. #5
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,428
    If you have money to spare, you can also take a look at this:

    Configuring geographically dispersed DB2 pureScale clusters
    ---
    "It does not work" is not a valid problem statement.

  6. #6
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,428
    About multiple standbys:

    "All of the HADR sync modes are supported on the principal standby, but the auxiliary standbys can only be in SUPERASYNC mode."

    HADR multiple standby databases
    ---
    "It does not work" is not a valid problem statement.

  7. #7
    Join Date
    Dec 2012
    Posts
    3
    Quote Originally Posted by n_i View Post
    About multiple standbys:

    "All of the HADR sync modes are supported on the principal standby, but the auxiliary standbys can only be in SUPERASYNC mode."

    HADR multiple standby databases
    I appreciate your help. This is the most likely scenario we will go with. We were hoping for a remote SYNC, however without a Dark Fiber setup it will not be possible. Local continuous availability with HADR for remote site's seems to be the best option for our situation.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •