TSM with DB2 HADR
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:
# HADR ports assigned by user ha_myhadr 51012/tcp ha_myhadr_int 51013/tcp
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:
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
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:
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
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:
db2 update db cfg for xmeta using hadr_remote_inst db2inst15. 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:
db2 update db cfg for xmeta using hadr_timeout 1206. Run the following command to specify the HADR synchronization mode:
db2 update db cfg for database using syncmode mode
For example:
db2 update db cfg for xmeta using syncmode SYNC
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:
db2 update db cfg for xmeta using hadr_timeout 1208. 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:
db2 update alternate server for database xmeta using hostname 192.0.2.7 port 60000
10. Run the following command to verify your configuration values:
db2 get db cfg for database | grep HADR
For example:
db2 get db cfg for xmeta | grep HADR
The command displays a report:
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
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:
mkdir mytempbackup cd mytempbackup db2 backup db xmeta
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:
db2 restore db xmeta from mytemprestore replace history file
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:
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
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:
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
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:
db2 update alternate server for database xmeta using hostname 192.0.2.6 port 60000
On the standby server, run the following command to verify your configuration values:
db2 get db cfg for database | grep HADR
For example:
# 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
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:
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
For example:
db2 start hadr db xmeta as standby The following message is displayed: DB2000I The START HADR ON DATABASE command completed successfully
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:
db2 get snapshot for db on xmeta | grep Role The following line is displayed: Role = Standby
On the primary server, run the following command to activate the database:
db2 activate db database
For example:
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
For example:
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
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:
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
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 displayed as Peer: State = Peer
