wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== TSM with DB2 HADR ====

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Storage%20Manager/page/Electronic%20vaulting%20using%20deduplicated%20remote%20copy%20storage%20pools

=== Preparing services ports for DB2 replication ===

The services file can be found in the following locations:

    Linux cue graphicUNIX cue graphic /etc/services
    Windows cue graphic c:\windows\system32\drivers\etc\services

The following example shows HADR ports specified within the services file:
<cli>
# HADR ports assigned by user
ha_myhadr      51012/tcp
ha_myhadr_int  51013/tcp
</cli>

=== Configuring the HADR primary server ===

On the primary server, configure the high availability disaster recovery (HADR) variables and verify your settings.
Before you begin
Complete the installation of IBM® InfoSphere™ Information Server. The installation must be operational before you complete the HADR configuration.

Complete HADR configuration as soon as the InfoSphere Information Server installation is operational.

**Procedure**

1. Log in to the primary server as an administrator.\\
2. Run the following commands to specify the HADR primary server and standby server:
  db2 update db cfg for database using hadr_local_host primary_IP
  db2 update db cfg for database using hadr_remote_host standby_IP

For example:
<cli>
    db2 update db cfg for xmeta using hadr_local_host 192.0.2.6
    db2 update db cfg for xmeta using hadr_remote_host 192.0.2.7
</cli>
3. Run the following commands to specify the HADR primary and standby service names:
  db2 update db cfg for database using hadr_local_svc primary_svc_name
  db2 update db cfg for database using hadr_remote_svc standby_svc_name

In the commands, the service names must match the HADR port names that appear in the services file.
For example:
<cli>
    db2 update db cfg for xmeta using hadr_local_svc ha_myhadr
    db2 update db cfg for xmeta using hadr_remote_svc ha_myhadr_int
</cli>
4. Run the following command to specify the DB2® instance name on the standby server:
  db2 update db cfg for database using hadr_remote_inst DB2_standby_instance

For example:
<cli>
    db2 update db cfg for xmeta using hadr_remote_inst db2inst1
</cli>
5. Run the following command to specify the time (in seconds) that the HADR process waits before considering a communication attempt to have failed:
  db2 update db cfg for database using hadr_timeout timeout

For example:
<cli>
    db2 update db cfg for xmeta using hadr_timeout 120
</cli>
6. Run the following command to specify the HADR synchronization mode:

  db2 update db cfg for database using syncmode mode

For example:
<cli>
    db2 update db cfg for xmeta using syncmode SYNC
</cli>
    When configuring the synchronization mode, choose synchronous mode (SYNC) or near synchronous mode (NEARSYNC). Either mode typically provides adequate response time for InfoSphere Information Server. Avoid choosing asynchronous mode (ASYNC) because ASYNC mode has the highest chance of transaction loss if the primary server fails.
7. Run the following command to specify the time (in seconds) that the HADR process waits before considering a communication attempt to have failed:

  db2 update db cfg for database using hadr_timeout timeout

For example:
<cli>
    db2 update db cfg for xmeta using hadr_timeout 120
</cli>
8. Run the following command to activate the "log index pages created" feature. When logindexbuild is on, index creation, recreation, and reorganization operations are logged. This logging allows indexes to be reconstructed during DB2 roll-forward operations or HADR log replay procedures.

  db2 update db cfg for xmeta using logindexbuild on

9. Run the following command to set up automatic client reroute:

  db2 update alternate server for database database using hostname standby_IP port port

For example:
<cli>
  db2 update alternate server for database xmeta using hostname 192.0.2.7 port 60000
</cli>

10. Run the following command to verify your configuration values:

  db2 get db cfg for database | grep HADR

For example:
<cli>
    db2 get db cfg for xmeta | grep HADR
</cli>

The command displays a report:
<code>
    HADR database role                                 = STANDARD
    HADR local host name             (HADR_LOCAL_HOST) = myprimary.example.com
    HADR local service name           (HADR_LOCAL_SVC) = ha_myhadr
    HADR remote host name           (HADR_REMOTE_HOST) = mystandby.example.com
    HADR remote service name         (HADR_REMOTE_SVC) = ha_myhadr_int
    HADR instance name of remote server  (HADR_REMOTE_INST) = db2inst1
    HADR timeout value                       (HADR_TIMEOUT) = 120
    HADR log write synchronization mode     (HADR_SYNCMODE) = SYNC
</code>

=== Configuring the HADR standby server ===

Back up the database from the primary server and restore it on the standby server. Then set HADR variables on the standby server.
Before you begin
Make sure that neither database has an existing connection with client application. You cannot perform a backup on a database that has an existing connection with its client application.
Procedure

Log in to the primary server as an administrator. \\
Run these commands to back up the database on the primary server:

  mkdir temp_backup_directory
  cd temp_backup_directory
  db2 backup db database

    For example:
<cli>
    mkdir mytempbackup
    cd mytempbackup
    db2 backup db xmeta
</cli>

    Note: You can store more than one database backup in the same temporary directory.
    After the backup completes, a confirmation message is displayed:

    Backup successful. The timestamp for this backup image is :20101101161943

    Transfer the backup files from the primary server to the standby server.
    Log in to the standby server. Use your DB2® user ID.
    Run this command to restore the database on the standby server:

  db2 restore db database from database_backup_directory replace history file

For example:
<cli>
    db2 restore db xmeta from mytemprestore replace history file
</cli>
    On the standby server, run the following commands to specify the HADR primary server and standby server. In the command, specify the standby server for hadr_local_host. Specify the primary server for hadr_remote_host (the opposite of the settings on the primary server).

    db2 update db cfg for database using hadr_local_host standby_IP
    db2 update db cfg for database using hadr_remote_host primary_IP

    For example:
<cli>
    db2 update db cfg for xmeta using hadr_local_host 192.0.2.7
    db2 update db cfg for xmeta using hadr_remote_host 192.0.2.6
</cli>
    On the standby server, run the following commands to specify the HADR primary and standby service names. In the command, specify the standby server port name for hadr_local_svc. Specify the primary server port name for hadr_remote_svc (the opposite of the settings on the primary server).

    db2 update db cfg for database using hadr_local_svc standby_svc_name
    db2 update db cfg for database using hadr_remote_svc primary_svc_name

    For example:
<cli>
    db2 update db cfg for xmeta using hadr_local_svc ha_myhadr_int
    db2 update db cfg for xmeta using hadr_remote_svc ha_myhadr
</cli>
    On the standby server, run the following command to set up automatic client reroute. Specify the primary server IP address and port number in the command:

    db2 update alternate server for database database using hostname primary_IP 
       port port

    For example:
<cli>
    db2 update alternate server for database xmeta using hostname 192.0.2.6 port 60000
</cli>
    On the standby server, run the following command to verify your configuration values:

    db2 get db cfg for database | grep HADR

    For example:
<cli>
# db2 get db cfg for xmeta | grep HADR

    HADR database role                                 = STANDARD
    HADR local host name             (HADR_LOCAL_HOST) = mystandby.example.com
    HADR local service name           (HADR_LOCAL_SVC) = ha_myhadr_int
    HADR remote host name           (HADR_REMOTE_HOST) = myprimary.example.com
    HADR remote service name         (HADR_REMOTE_SVC) = ha_myhadr
    HADR instance name of remote server  (HADR_REMOTE_INST) = db2inst1
    HADR timeout value                       (HADR_TIMEOUT) = 120
    HADR log write synchronization mode     (HADR_SYNCMODE) = SYNC
</cli>


=== Starting HADR ===

Start high availability disaster recovery (HADR) on the standby server, and then on the primary server.
Before you begin
Make sure to configure the HADR variables as described in the previous information. If the parameters are not configured correctly, the HADR servers do not start.
Procedure

    On the standby server, run the following command to deactivate the database:

    db2 deactivate db database

    For example:
<cli>
    db2 deactivate db xmeta

    On the standby server, run the following command to start HADR on the standby server:

    db2 start hadr on db database as standby
</cli>

    For example:
<cli>
    db2 start hadr db xmeta as standby

    The following message is displayed:

    DB2000I  The START HADR ON DATABASE command completed successfully
</cli>

    On the standby server, run the following command to verify the HADR role of the server:

    db2 get snapshot for db on database | grep Role

    For example:
<cli>
    db2 get snapshot for db on xmeta  | grep Role

    The following line is displayed:

        Role                   = Standby
</cli>

On the primary server, run the following command to activate the database:
  db2 activate db database

For example:
<cli>
    db2 activate db xmeta

    On the primary server, run the following command to start HADR on the primary server:

    db2 start hadr on db database as primary
</cli>

    For example:
<cli>
    db2 start hadr db xmeta as primary

    The following message is displayed:

    DB2000I  The START HADR ON DATABASE command completed successfully

    On the primary server, run the following command to verify the HADR role of the server:

    db2 get snapshot for db on database | grep Role

    For example:

    db2 get snapshot for db on xmeta  | grep Role

    The following line is displayed:

        Role                   = Primary

    On each server, run the following command to verify that the databases are synchronized:

    db2 get snapshot for database on database | grep State

    For example:

    db2 get snapshot for database on xmeta  | grep State

    After the standby database makes the connection to the primary database, the state is reported as Peer:

        State                  = Peer
</cli>

=== Validating the HADR configuration ===

After you configure high availability disaster recovery (HADR), validate your configuration and test the takeover function.
Before you begin
Configure HADR on your primary and standby servers, and start HADR on the servers.
About this task
Use the IBM® DB2® Control Center to verify the connection status. Then initiate a takeover and a failback to test the takeover function.
Procedure

    On the primary server, start the IBM DB2 Control Center.
    In the left pane, locate the database.
    Right-click the database name and select High Availability Disaster Recovery > Manage. The Manage High Availability Disaster Recovery (HADR) window is displayed.
    Verify that the Connection status field reads Connected.
    Log in to the primary server as an administrator.
    On the primary server, run the following command to initiate a DB2 HADR takeover:

    db2 takeover hadr on db database

    For example:

    db2 takeover hadr on db xmeta

    When the takeover is complete, the following result is displayed:

      DB2000I The TAKEOVER HADR ON DATABASE command completed successfully.

    Log in to the standby server as an administrator.
    On the standby server, run the following command to determine the status of the database:

    db2 get snapshot for db on database | grep Role

    For example:

    db2 get snapshot for db on xmeta | grep Role

    When the takeover is successful, the following result is displayed for the standby server:

        Role                   = Primary

    Check the IBM WebSphere® Application Server log file SystemOut.log to determine whether the application server successfully connected to the standby database. To locate this file, see IBM WebSphere Application Server system log files.
    If automatic client reroute worked correctly, the log file indicates that WebSphere Application Server first tried to connect to the primary server. When that connection failed, automatic client reroute connected successfully to the standby server. The following log file excerpt shows these events:

    [11/1/10 17:15:39:298 CST] 00000039 ServletWrappe E   SRVE0068E: Uncaught 
    exception thrown in one of the service methods of the servlet: /dbview.jsp. 
    Exceptionthrown : javax.servlet.ServletException: A connection failed but 
    has been re-established. The hostname or IP address is "myprimary.example.com" 
    and the service name or port number is 60000 . Special registers may or may 
    not be re-attempted (Reason code = 1  DB2ConnectionCorrelator: 
    G9056D89.O37F.061101231714

    Log in to the standby server as an administrator.
    On the standby server, run the following command to initiate a DB2 HADR failback:

    db2 takeover hadr on db database

    For example:

    db2 takeover hadr on db xmeta

    When the failback is complete, the following result is displayed:

      DB2000I The TAKEOVER HADR ON DATABASE command completed successfully.

    On the primary server, run the following command to determine the status of the database:

    db2 get snapshot for db on database | grep Role

    For example:
<cli>
    db2 get snapshot for db on xmeta | grep Role

    When the takeover is successful, the following result is displayed for the primary server:

        Role                   = Primary
</cli>

    On each server, run the following command to verify that the databases are synchronized:

    db2 get snapshot for database on database | grep State

    For example:
<cli>
    db2 get snapshot for database on xmeta  | grep State

    After the standby database makes the connection to the primary database, the state is displayed as Peer:

        State                  = Peer
</cli>
wiki

User Tools

Site Tools

Page Tools
