High Availability in DB2 Nishant Sinha

Overview ➲ Importance of High Availability ➲ High Availability Strategies ➲ High Availability with DB2 Server Automatic Client Re route Server Lists DB2 Fault Monitor Facility HADR DB2 HA Log Shipping Log Mirroring ➲ GDPC High Availability / Disaster recovery

Importance of High Availability ➲ It is a measure of successful user applications ➲ Solution should be designed to withstand outages. Planned outages the impact of maintenance activities on the availability of the database to user applications must be minimized. Unplanned outages Shield user applications from the failure Respond to the failure to contain its effect Recover from the failure to return the system to normal operations

High availability strategies ➲ Strategies for improving the availability of your database solution include: Redundancy System monitoring Load balancing Fail over Maximizing performance Minimizing the impact of maintenance

High availability with DB2 server ➲ Automatic Client Re route ➲ Server lists ➲ DB2 Fault Monitor ➲ HADR ➲ DB2 Automated HA ➲ Through Log Shipping ➲ Log Mirroring ➲ Online Split Mirror

Automatic Client Re route ➲ redirects client applications from a failed server to an alternate server ➲ works in conjunction with HADR and the DB2 pureScale Feature ➲ The UPDATE ALTERNATE SERVER FOR DATABASE command is used to define the alternate server location on a particular database. ➲ the alternate server location information is returned to the IBM data server client as part of the connection process. ➲ Some limitations Cannot use ACR with ROS in HADR Only supported with TCP/IP Even if the original server is back up, the new connections would still go to the alternate server DB2 version on both the servers must be same.

Server lists ➲ used by IBM® Data Server drivers and clients for workload balancing (WLB) and automatic client reroute (ACR) operation. ➲ contains a list of addresses and the relative priority of those addresses ➲ Each entry in the server list contains: Host list Port Priority

DB2 fault monitor facilities for Linux and UNIX ➲ keeps IBM® DB2 server databases up and running by monitoring DB2 database manager instances, and restarting any instance that exits prematurely. ➲ The fault monitor coordinator (FMC) is the process of the fault monitor facility that is started at the UNIX boot sequence ➲ Each fault monitor will, in turn, be responsible for monitoring one DB2 instance ➲ If HA clustering product such as TSA is being used, fault monitor facility must remain off.

High Availability Disaster Recovery ➲ provides a high availability solution for both partial and complete site failures ➲ protects against data loss by replicating data changes from a source database, called the primary database, to one or more target databases, called the standby databases. ➲ Standby databases are synchronized with the primary database through log data that is generated on the primary and shipped to the standbys ➲ Peer window ensures zero data loss ➲ Support for multiple standbys ➲ Reads on Standby

DB2 High Availability Feature ➲ enables integration between IBM® DB2 server and cluster managing software. ➲ composed of the following elements: IBM Tivoli® System Automation for Multiplatforms (SA MP) is bundled with DB2 server on AIX® and Linux as part of the DB2 High Availability Feature DB2 high availability instance configuration utility (db2haicu) is a text-based utility that you can use to configure and administer your highly available databases in a clustered environment.

Log shipping ➲ process of copying whole log files to a standby machine ➲ A scheduled job on the standby issues the ROLLFORWARD DATABASE command at a specified interval ➲ The standby database is continuously rolling forward through the log files that are produced by the production machine ➲ When the production machine fails, The remaining logs are transferred over to the standby machine. The standby database rolls forward to the end of the logs and stops. The clients reconnect to the standby database, which is now the new primary, and resume operations.

Log Mirroring ➲ supports log mirroring at the database level ➲ helps protect a database from accidental deletion of an active log ➲ mirrorlogpath configuration parameter to specify a secondary path ➲ write an identical second copy of log files to a different path. ➲ recommended that you place the secondary log path on a physically separate disk

Suspended IO and Online split Mirror ➲ split mirrored copies of the primary database without taking the database offline ➲ mirroring is the process of writing data to two separate hard disks at the same time ➲ Splitting a mirror is the process of separating the two copies. ➲ use DB2 server suspended I/O functionality to split the primary and secondary mirrored copies of the database without taking the database offline ➲ The db2inidb command initializes the split mirror so that it can be used: As a clone database As a standby database As a backup image

GDPC HA and DR ➲ provide high availability and disaster recovery failover when a cluster member goes down. ➲ can automatically and transparently recover from the same hardware or software failures as a single-site DB2 pureScale cluster ➲ The estimated time for a GDPC to recover from software faults is comparable to the recovery time for software faults in a single-site DB2 pureScale cluster ➲ Ensure that sufficient space is available for critical file systems such as /var and /tmp ➲ GPFS™ storage replication is a key component of GDPC,