IBM Books

Administration Guide

Setting Up Failover Support for a Database System

To set up Sun Cluster 2.1, perform the following steps:

  1. Ensure that your system meets the requirements detailed in "Preliminary Requirements".

  2. Ensure that Sun Cluster 2.1 is installed properly.

  3. Create the logical hosts which that will host the database partitions.

  4. Create the logical host filesystems, and filesystems for SMS table spaces.

  5. Install DB2 on each machine in the cluster (you can use cconsole or ctelnet, which come with Sun Cluster 2.1).

  6. For mutual partition failover, set up HA-NFS either locally or remotely on a separate cluster to export the highly available instance's home directory.

  7. On one machine only, create an instance on the HA-NFS filesystem, while ensuring that the user for the instance is created with the same uid on the other machines in the cluster. Also ensure that the groups and services for the instance are also created on the other machines in the cluster.

  8. Run the hadb2eee_addinst script as root to set up your HA instance or configure the instance manually. The hadb2eee_addinst script is provided as an example on how an instance may be set up. The hadb2eee_addinst script does the following:

  9. Run hadb2start to start the high availability environment

Choosing a Failover Configuration

To choose a failover configuration, perform the following steps:

  1. Set up the machines to use either a hot standby or mutual takeover configuration. For a hot standby configuration, use one logical host. For a mutual takeover, use two or more logical hosts.

  2. Decide on the amount of disk space that is required for each logical host and its resources, such as raw devices or SMS table space containers. Whether you use SMS or DMS (raw devices) table spaces, any disks belonging to a logical host must be included in its disk groups.
    Table space considerations: You must decide on the type of table space that you want to use. If you want to use SMS table spaces, you must set them up using disks from the disk groups that belong to a logical host. In addition, you must include the filesystem in the vfstab for the logical host. Refer to the Sun Cluster 2.1 documentation for information about how to add a file system to a logical host.

    There are benefits and costs associated with using either SMS or DMS table spaces. For example, SMS table spaces reside on file systems that must be file-system checked before they are mounted. This can add a considerable amount of overhead when failover occurs, and can result in the Sun Cluster 2.1 software timing out. If you use SMS table spaces, ensure that they are journaled files systems, which require less time to check after a failover.

    DMS table spaces do not have to be file-system checked during failover, which can reduce the failover time for the high availability scripts.

    You should remember that, for both SMS and DMS table spaces, committed transactions that are written to the logs will be applied to the database during crash recovery after the database server fails over.

Preliminary Requirements

Any logical host that you want in a cluster must have the following directories available:

Is the name of the logical host that runs the partition

Is where the home directories reside

Is where the SMS table spaces reside for the database partitions

For example:


Where log0 is the logical host and db2eee is the highly available instance.

Scripts and Programs

All of the following scripts are in the directory /opt/IBMdb2/V5.0/ha/UDB-EEE_SC2.x/bin. Included are:

The sample instance setup script

Registers DB2 Extended Enterprise Edition for high availability

Script that starts partitions for a logical host. This script is run automatically by Sun Cluster 2.1. You should not run this script manually.

Script that stops partitions for a logical host. This script is run automatically by Sun Cluster 2.1. You should not run this script manually.

Unregisters DB2 Extended Enterprise Edition for high availability

Shows the current status of DB2 Extended Enterprise Edition

Starts DB2 in the highly available environment.

Stops DB2 in the highly available environment.

The hadb2eee_startnet and hadb2eee_stopnet scripts are used during a failover. The hadb2eee_startnet script starts partitions on a physical machine, while hadb2eee_stopnet stops partitions on a physical machine. Both the start and stop scripts read the /var/db2/v5/db2tabeee configuration file to find out which DB2 instances are highly available. See "Enabling Failover for an Instance" for information about this file.

Creating a DB2 Instance

For information about creating an instance, refer to the DB2 Extended Enterprise Edition for UNIX Quick Beginnings .

Registering the DB2 Resource with Sun Cluster 2.1

If you are using local HA-NFS for your cluster, you must register and set up HA-NFS before HA DB2 EEE. The hadb2eee_reg script may look something like this:

# Make sure you register hanfs with every logical node even though only
# one will use it. This is to fix a dependency issue with SC2.x.
DEPONNFS="-d nfs"
# Register HA-NFS
#hareg -s -r nfs
#hareg -y nfs
hareg -r hadb2eee -b /opt/IBMdb2/V5.0/ha/UDB-EEE_SC2.x/bin/ -m START=hadb2eee_st
if [[ STARTUP -eq 1 ]]
  hareg -y hadb2eee


Is the timeout for the Sun Cluster agent to start and stop DB2.

Specifies whether to start the high availability environment after registering HA DB2 EEE.

Set this to an empty string if you are using a remote HA-NFS server. If you are using a local HA-NFS server, ensure that this is set to -d nfs, and that the lines that register HA-NFS are uncommented.

Enabling Failover for an Instance

To enable an instance for failover, you create an entry for it in the /var/db2/v5/db2tabeee file. This file must be kept consistent across all the machines in the cluster. Entries in this file are in the form:



Is the type of instance. The value can be one of the following:

Is the user name of the instance owner.

Is the logical host which is hosting the HA-NFS filesystem.

Specifies whether the instance is highly available (ON) or not (OFF).

The directory on the HA-NFS host to mount.

The local mount point for the HA-NFS.

An example might be:

   DATA db2eee sphere ON /log0/home /export/ha_home

In this example, the instance owner's home directory should be placed under /export/ha_home.

Binding Database Partition Servers to a Logical Host

You use the file called $INSTHOME/sqllib/hadb2-eee.cfg to bind database partitions to a logical host. Bind, in this context, means that the file ensures that the partitions follow the logical hosts around the cluster, starting on the machine in the cluster that hosts the logical host. Entries in this file are in the form:

   NODE: log0  0
   NODE: log0 10
   NODE: log0 12
   NODE: log1 33
   NODE: log1 45
   NODE: log1 59

In this example, logical host log0 is responsible for partitions 0, 10, and 12, while logical host log1 is responsible for partitions 33, 45, and 59. These logical hosts are responsible for both starting and stopping the partitions during a failover situation.
Note:There must be a one-to-one relationship between the partitions in this file and the db2nodes.cfg file.

How Failover Processing Works

When a failover occurs, the hadb2eee_startnet and hadb2eee_stopnet programs read the /var/db2/v5/db2tabeee file to find out which DB2 instances are highly available. Then for each highly available instance, they read the configuration file $INSTHOME/sqllib/hadb2-eee.cfg, which binds partitions to logical hosts.

Information about the failover process is sent to the syslog using the facility set to LOG_USER and the priority set to LOG_ERR.

Setting Up a Hot Standby Configuration

To set up a hot standby configuration, bind all of the partitions to one logical host that is hosted by one of the servers in the cluster. When you finish, the $INSTHOME/sqllib/hadb2-eee.cfg file should resemble the following:

   NODE: log0  0
   NODE: log0 10
   NODE: log0 12
   NODE: log0 33
   NODE: log0 45
   NODE: log0 59

If the logical host log0 fails over, all the database partitions associated with it will fail over as well.

Setting Up a Mutual Takeover Configuration

To set up a mutual takeover configuration, bind the partitions to two or more logical hosts. When you finish, the $INSTHOME/sqllib/hadb2-eee.cfg file should resemble the following:

   NODE: log0  0
   NODE: log0 10
   NODE: log0 12
   NODE: log0 33
   NODE: log1 45
   NODE: log1 59

You do not need to set up a completely symmetric configuration. As the example shows, the logical host log0 supports more partitions than the logical host log1 (partitions 0, 10, 12 and 33 for logical host log0 versus partitions 45 and 59 for logical host log1). Because you do not have to implement a symmetric configuration, a mutual takeover configuration provides an amount of flexibility that will support any situation.

Starting and Stopping DB2

To start DB2 in a failover environment, use the hadb2start command. This command both enables the failover environment, and starts DB2.

If you want to stop DB2, use the hadb2stop command. This command both disables the failover environment and stops DB2.
Note:If you do not issue hadb2stop and you use db2stop, Sun Cluster 2.1 may assume that the DB2 instance needs to be failed over.

Running Scripts During a Failover

The /var/db2/v5/failover.eee script runs automatically when a failover occurs. You can use this script to send email (for example, to notify support staff) of the failover situation. You should keep the commands in this script to a minimum, because it runs before DB2 is started. Depending on whether DB2 is starting or stopping, the following scripts will also run (if they are available) for each instance.
Note:You must create the $INSTHOME/sqllib/ha directory and create these scripts to be executables. You should ensure that you have backup copies of these scripts.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]