Data is the blood of a modern, on demand business; the system that stores and moves that data around -- servers, networks, databases -- is the heart. But both are inert components without the heartbeat -- having reliable, readily available access to that data, access with minimum downtime.

Introduction

The first installment of this series, High-availability middleware on Linux, Part 1: Heartbeat and Apache Web server, introduced high availability (HA) concepts and how to install and configure heartbeat. This part, the final installment of the series, covers the HA implementation for DB2 UDB 8.1 in a cold standby configuration using heartbeat.

In this implementation, heartbeat detects a failure with the primary and initiates failover by:

• Stopping the DB2 processes on the primary
• Releasing the shared disk on the primary
• Removing the service IP address on the primary
• Adding the service IP address to the standby
• Mounting the shared disk on the standby
• Restarting the DB2 processes on the standby machine

To get the most from this article, you need a basic understanding of DB2 UDB and high availability clusters. The first article in this series explains what it means for software to be highly available and how to install and set up heartbeat software from the High-Availability Linux project on a two-node system.

Back to top

DB2 UDB and HA basics

Any DB2 UDB that is to be used in a heartbeat cluster needs to have its data on shared disks so that it can be accessed by a surviving node in the event of a node failure. A node running a database instance must also maintain a number of files on internal disks. These files include those that relate to all the database instances on the node.

Files related to a database instance are therefore divided between internal and shared disks. Figure 1 details this organization of filesystem for DB2, described in our test setup for instance db2inst1 and database hadb.

In this setup:

• The machine ha1 will serve as a primary DB2 UDB database machine.
• The machine ha2 will serve as a backup for node ha1.
• Each node will have its own local copy of DB2 UDB 8.1 installed.
• The database hadb-specific directories (db2inst1/NODE0000/SQL00001 and db2inst1/NODE0000/sqldbdir) will be kept on the shared filesystem (/ha).

Back to top

Installing the database

Follow the steps in this section to install DB2 UDB 8.1 on both the primary and the backup node. For more information, refer to the DB2 Information Center (see Resources):

1. Log in as root.
   
   
2. Extract the DB2 UDB 8.1 installation image using these commands:
   
   

   rm -rf /tmp/db28.1-install mkdir /tmp/db28.1-install tar xf C48THML.tar -C /tmp/db28.1-install

   
   
   
   Here C48THML.tar is the installation tar file.
   
   
3. Set the kernel level: export LD_ASSUME_KERNEL=2.4.19.
   
   
4. Do not use the IBM Developer Kit for Linux, Java 2 Technology Edition provided in the DB2 Installation disk. Replace the JDK that comes with DB2 with the IBM 1.4.2 JDK.
   
   

   cd /tmp/db28.1-install/009_ESE_LNX_32_NLV mv ./db2/linux/java ./db2/linux/java.db2 ln -s /opt/IBMJava2-142 ./db2/linux/java

   
   
   
   
5. Launch the DB2 setup wizard using this command: ./db2setup.

Use the following information in the wizard screens:

• For Product to install use DB2 UDB Enterprise Server Edition.
• For Group and User IDs, the values of the numerical group ID (gid) and the user ID (uid) fields must match on both machines. We will use the IDs show in Table 1 below.
• For Partition, select single-partition instance.
• For DB2 Instance Name, select db2inst1.

Back to top

Creating a highly available database

Follow these steps to create the highly available database, hadb:

1. Log on as user db2inst1 on both the primary (ha1) and backup (ha2) nodes: su - db2inst1.
   
   
2. Ensure that DB2(R) instances are not started at boot time by using the db2iauto utility as follows (as user db2inst1) on both nodes ha1 and ha2:
   
   

   cd sqllib/bin ./db2iauto -off db2inst1

   
   
   
   
3. Modify the /etc/inittab file to run DB2 HA correctly. Comment out the line that starts DB2 on system startup as follows on both nodes ha1 and ha: #fmc:2345:respawn:/opt/IBM/db2/V8.1/bin/db2fmcd #DB2 Fault Monitor Coordinator.
   
   
4. Start DB2 on the primary node ha1: db2start.
   
   
5. Mount the filesystem /ha on the backup (ha1) using this command (as user root): mount /ha.
   
   
6. Create a database hadb using this command on node ha1: db2 create database hadb on /ha.
   
   
7. Make sure you are able to connect to the database hadb using this command on node ha1: db2 connect to hadb. If successful, disconnect using this command: db2 connect reset.
   
   
8. Stop DB2 using db2stop on node ha1.
   
   
9. Mount the filesystem /ha on the backup (ha2) using mount /ha as user root.
   
   
10. Start DB2 on the primary node ha2 with db2start.
    
    
11. As user db2inst1, execute the following command on node ha2 in order to catalog the database hadb: db2 catalog database hadb on /ha.
    
    
12. Make sure you are able to connect to the database hadb by using db2 connect to hadb on node ha2. If successful, disconnect using db2 connect reset.
    
    
13. Stop DB2 using the db2stop on node ha2.

Back to top

Configuring heartbeat to manage DB2

Now configure the /etc/ha.d/haresources file (on both the primary and backup machine nodes) to include the script that manages the DB2 processes. This script comes with heartbeat.

The relevant portion of the modified file is shown here:

ha1.haw2.ibm.com 9.22.7.46
      Filesystem::hanfs.haw2.ibm.com:/ha::/ha::nfs::rw,hard db2::db2inst1

This line dictates that on startup of heartbeat, ha1 serves the cluster IP address, mounts the shared filesystem, and starts the database server as well. On shutdown, heartbeat first stops the database server, then un-mounts the shared filesystem, and finally gives up the IP.

Back to top

Testing DB2 UDB failover

This section shows you how to test the high availability of the DB2 database, hadb. This is perhaps the most involved process described in this article, so watch the details.

1. Start the heartbeat service on the primary and then on the backup node. Use the command /etc/rc.d/init.d/heartbeat start as user root.

   After heartbeat starts successfully, you should see a new interface with the IP address that you configured in the ha.cf file. Once you've started heartbeat, take a peek at your log file (default is /var/log/ha-log) on the primary, and make sure that it is doing the IP takeover and then starting DB2. Use the ps command to make sure DB2 processes are running on the primary node. Heartbeat will not start any of the above processes on the backup. This happens only after the primary fails.

2. Check the database status on ha1 node as user db2inst1: db2 -tf /ha/hahbcode/db2/listdb.sql. The output of this command for our run should be the following:
   
   

   Active Databases Database name = HADB Applications connected currently = 0 Database path = /ha/db2inst1/NODE0000/SQL00001/

   
   
   
   
3. Create a test table (hadb.TestHATable) on ha1 node as user db2inst1, like so: db2 -tf /ha/hahbcode/db2/createdb.sql.
   
   
4. Now, insert a row of data in the test table on ha1 node as user db2inst1: db2 -tf /ha/hahbcode/db2/insertdb.sql.
   
   
5. Inspect the contents of the test table on ha1 node as user db2inst1: db2 -tf /ha/hahbcode/db2/selectdb.sql. You should be able to see the row of data that you inserted in the previous step. The output for our run is:
   
   

   [db2inst1@ha1 db2inst1]$ db2 -tf /ha/hahbcode/db2/selectdb.sql Database Connection Information Database server = DB2/LINUX 8.1.0 SQL authorization ID = DB2INST1 Local database alias = HADB COL1 COL2 ----------- ------------ 10 Hello 1 record(s) selected. DB20000I The SQL command completed successfully.

   
   
   
   
6. To simulate failover, we simply stop heartbeat on the primary system as user root: /etc/rc.d/init.d/heartbeat stop. You should see all the services come up on the backup machine in under a minute. You can verify that DB2 is running on the backup by checking the /var/log/ha-log file and using the ps command on the backup machine.
   
   
7. Check the database status on ha2 node as user db2inst1: db2 -tf /ha/hahbcode/db2/listdb.sql. The output of this command for our run is:
   
   

   Active Databases Database name = HADB Applications connected currently = 0 Database path = /ha/db2inst1/NODE0000/SQL00001/

   
   
   
   
8. Inspect the contents of the test table (hadb.TestHATable) on ha2 node as user db2inst1: db2 -tf /ha/hahbcode/db2/selectdb.sql. You should be able to see the row of data that you inserted while DB2 was running on node ha1. The output for our run is:
   
   

   [db2inst1@ha2 db2inst1]$ db2 -tf /ha/hahbcode/db2/selectdb.sql Database Connection Information Database server = DB2/LINUX 8.1.0 SQL authorization ID = DB2INST1 Local database alias = HADB COL1 COL2 ----------- ------------ 10 Hello 1 record(s) selected. DB20000I The SQL command completed successfully.

   
   
   
   This shows that the data has survived the failover from the primary to backup.
   
   
9. Insert a row of data in the test table on ha2 node as user db2inst1: db2 -tf /ha/hahbcode/db2/insertdb.sql.
   
   
10. You can start the primary node by simply starting heartbeat on the primary system as user root: /etc/rc.d/init.d/heartbeat start. You should see all the services come up on the primary machine in under a minute. You can verify that DB2 is running on the primary by checking the /var/log/ha-log file and using the ps command on the backup machine.
    
    
11. Inspect the contents of the test table on ha1 node as user db2inst1: db2 -tf /ha/hahbcode/db2/selectdb.sql. You should be able to see two rows of data. The output for our run is:
    
    

    [db2inst1@ha1 db2inst1]$ db2 -tf /ha/hahbcode/db2/selectdb.sql Database Connection Information Database server = DB2/LINUX 8.1.0 SQL authorization ID = DB2INST1 Local database alias = HADB COL1 COL2 ----------- ------------ 10 Hello 10 Hello 2 record(s) selected. DB20000I The SQL command completed successfully.

    
    

    This shows that the data has survived failover from the backup to the primary.

Back to top

Conclusion

Critical database applications demand a robust strategy for the preventing data loss and guaranteeing high availability of your data store. DB2 UDB makes it easy to manage large databases with excellent availability characteristics.

In this article you've seen how to easily and cost effectively implement HA for DB2 UD databases using open source software and inexpensive hardware.

Back to top

Download

Information about download methods

Resources

• Read the other articles in this series:
  • "High-availability middleware on Linux, Part 1: Heartbeat and Apache Web server"
  • "High-availability middleware on Linux, Part 2: WebSphere MQ"
  • "High-availability middleware on Linux, Part 3: IBM LoadLeveler"
  • "High-availability middleware on Linux, Part 4: IBM WebSphere Application Server"
  
  
  
• Check out the High-Availability Linux project Web site for more information on heartbeat, including downloads and heartbeat success stories.
  
  
• Download a trial version of IBM DB2 Universal Database Enterprise Server Edition V8.2 for Linux.
  
  
• Learn about High Availability Disaster Recovery (HADR), a new feature in DB2 UDB V8.2 that provides a high-availability solution for protection against both partial and complete site failures.
  
  
• "Planning for Availability in the Enterprise" (developerWorks, December 2003) discusses availability and how to plan for and maintain it in an enterprise middleware environment.
  
  
• Browse other documentation on high-availability resources from IBM.
  
  
• And while you're at it, check out these cluster and HA solutions from IBM.
  
  
• Find more resources for Linux developers in the developerWorks Linux zone.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• Build your next Linux development project with IBM trial software, available for download directly from developerWorks.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• DB2 UDB and HA basics
• Installing the database
• Creating a highly available database
• Configuring heartbeat to manage DB2
• Testing DB2 UDB failover
• Conclusion
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: DB2 Enterprise
• Demo: Create an electronic form solution with DB2 pureXML and Lotus Forms
• Community: DB2
• Buy: DB2 Enterprise

Dig deeper into Linux on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers