To set up Sun Cluster 2.1, perform the following steps:
To choose a failover configuration, perform the following steps:
|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
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.
Any logical host that you want in a cluster must have the following directories available:
/log0 /log0/home/db2eee /log0/disks/db2eee
Where log0 is the logical host and db2eee is the highly available instance.
All of the following scripts are in the directory /opt/IBMdb2/V5.0/ha/UDB-EEE_SC2.x/bin. Included are:
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.
For information about creating an instance, refer to the DB2 Extended Enterprise Edition for UNIX Quick Beginnings .
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. # TIMEOUT=600 STARTUP=1 #DEPONNFS= 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 art,START_NET=hadb2eee_startnet,STOP_NET=hadb2eee_stopnet,ABORT_NET=hadb2eee_abo rtnet -t START_NET=$TIMEOUT,STOP_NET=$TIMEOUT $DEPONNFS if [[ STARTUP -eq 1 ]] then hareg -y hadb2eee fi
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:
TYPE INSTANCE NFS_HOST ON HA-NFS_DIR LOCAL_MOUNT_POINT
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.
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.|
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.
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.
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.
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.|
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.|
This file takes as an argument the number of logical hosts that are currently running on the failover machine. If this script exists, it runs immediately before the db2start command.
This file takes as an argument the number of logical hosts that are currently running on the failover machine. If this script exists, it runs immediately before the db2stop command.
|Note:||This script may not be run if the machine crashes.|
This file runs just after a failover and is used to such tasks as restart databases.
[ DB2 List of Books | Search the DB2 Books ]