IBM Books

Administration Guide

Setting up Failover Support for a Database System

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

  1. "Choosing a Failover Configuration".

  2. "Creating a DB2 Instance".

  3. "Registering the DB2 Resource with Sun Cluster".

  4. "Enable Failover for an Instance".

  5. "Starting and Stopping DB2".

If you want to remove failover support for DB2, see "Unregistering DB2 for Failover".

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 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 sets.
    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 them 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. This can reduce the failover time for the high availability scripts, but you should remember that committed transactions that are written to the logs will be applied to the database during crash recovery after the database server fails over.

Creating a DB2 Instance

To create the instance, use the db2icrt command, which is located in the DB2DIR/instance directory, where DB2DIR is /opt/IBMdb2/V5.0. Before creating a DB2 instance, ensure that DB2 is installed on each machine in the cluster.

You only create a DB2 instance on the logical host in the cluster where you created the subdirectories /logical_host_name/home and /logical_host_name/disks. The syntax of the db2icrt command is:
Creating an instance
 where:

-h | -?
Display a help menu for this command.

-d
Sets the debug mode that you can use for problem determination.

-a AuthType
Is an optional parameter that specifies the authentication type for the instance. Valid authentication types are SERVER, CLIENT, and DCS. If the -a parameter is not specified, the authentication type defaults to SERVER, if a DB2 server is installed. Otherwise, the AuthTypeis set to CLIENT.

Notes:

  1. All databases in the instance have the same authentication type.

  2. DCE authentication is not valid for this command; however, you can enable DCE authentication for an instance. For more information, refer to the Administration Guide.

-u FencedID
Is the user under which the fenced UDFs and stored procedures will execute. This is not required if you install the DB2 Client Application Enabler or the DB2 Software Developer's Kit. For other products, this is a required parameter.
Note:FencedID may not be root or bin.

InstName
Is the login name of the instance owner.

When you create an instance, ensure that its primary and secondary groups are different from the Administration Server's primary (SYSADM) group. When you create an instance on the same machine as the Administration Server, its SYSADM group is automatically added to the secondary group list of the Administration Server so that you can use the Control Center to perform administration tasks on that instance.

To create an instance for a DB2 server, you can use the following command: 

  db2icrt -u db2fenc1 db2inst1

When an instance is created, its name is also added to the list of instances on the system.

The db2icrt command creates the INSTHOME/sqllib directory, where INSTHOME is the home directory of the instance owner.
Note:To avoid a potential loss of data if an instance is deleted, you should not create user files or directories under the INSTHOME/sqllib directory, other than those created by DB2. The exeption is if your system supports fenced user defined functions and fenced stored procedures. In this situtaion, put the fenced applications in the INSTHOME/sqllib/function directory.

Registering the DB2 Resource with Sun Cluster

Use the db2hareg script as an example of how to register DB2 with Sun Cluster. The script is located in the /opt/IBMdb2/V5.0/ha/UDB-EE_SC2.x/bin directory. The db2hareg script is as follows: 

   #!/bin/ksh
 
   hareg -r db2hareg -b /opt/IBMdb2/V5.0/ha/UDB-EE_SC2.x/bin -m
   START_NET=hadb2ee_startnet,STOP_NET=hadb2ee_stopnet,ABORT_NET=hadb2ee_abortnet -t
   START_NET=600,STOP_NET=600
   -h log0
   hareg -y hadb2ee

In the sample, log0 is the logical host. Replace log0 with the logical host that is to host the DB2 services.

You should run the db2hareg script (or an equivalent script) once for the cluster, and you must ensure that the script is the same on both machines in the cluster. You run the script as root. The script both registers DB2 for failover support, and enables the following scripts for the cluster:

Enable Failover for an Instance

To enable an instance for failover, you create an entry for it in the /var/db2/v5/db2tabee file. The file must exist on each machine in the cluster. The file takes entries of the form: 

   TYPE INSTANCE LOGICAL_HOST ON/OFF

Where:

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

INSTANCE
Is the user name of the instance owner.

LOGICAL_HOST
Is the logical host on which the DB2 instance runs.

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

Starting and Stopping DB2

To start DB2 in a failover environment, use the hareg -y hadb2ee command. This command both enables the failover environment, and starts DB2.

If you want to stop DB2, first issue the hareg -n hadb2ee command to disable the failover environment. Then issue the db2stop command to stop DB2.
Note:If you do not issue hareg -n hadb2ee first, 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.ee 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:

You can use pre_db2startee to prevent resource contention by adjusting database manager and database configuration parameters that may consume substantial amounts of resource (for example, sheapthres). The following is an example: 

  #!/bin/ksh
 
  #Very simple example
 
  LOGHOSTS=$1
 
  if ^^ $LOGHOSTS -eq 1 нн
  then
    db2 update dbm cfg using SHEAPTHRES 40000
  else
    db2 update dbm cfg using SHEAPTHRES 20000
  fi

Unregistering DB2 for Failover

To unregister DB2 for failover, run the hadb2ee.unreg script. This script deregisters DB2 with Sun Cluster 2.1.

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

[ DB2 List of Books | Search the DB2 Books ]