In mutual takeover mode, one processor can failover the single-partition database instance, or the partitions of a partitioned database, while running another instance or other partitions of a partitioned database configuration. As with the hot standby configuration, the installation path, the instance directory, and the database must be accessible to each processor that may be involved in failover processing. The installation and instance paths can either be on a shared file system, or mirrored on separate file systems.
When using the mutual takeover strategy for instance failover, the instances must be defined in such a manner that both instances can be run simultaneously on the same processor. For detailed information about the actual installation requirements, and about instance creation, refer to HACMP for AIX, Version 4.2: Installation Guide, SC23-1940.
Each of the following examples has a sample script that is stored (on DB2 for AIX installations) in sqllib/samples/hacmp.
The following mutual instance failover scenario consists of an HACMP system with two processors known as "node10" and "node20".
Figure 45. Example of a Mutual Instance Failover Configuration
Two instances, "db2inst1" and "db2inst2", are created from a single installation path on a shared file system. Instance "db2inst1" is created on /u/db2inst1, and instance "db2inst2" is created on /u/db2inst2. Both of these paths are on a shared file system that is accessible to both processors. Each instance has a single database, with a unique path, that is also on a shared resource accessible to both processors.
Both instances are accessed via remote clients over the TCP/IP protocol: "db2inst1" uses the service name "db2inst1_port" (port number 5500), and "db2inst2" uses the service name "db2inst2_port" (port number 5550). Remote clients accessing the "db2inst1" instance have this instance cataloged in their node directory using "node10" as the host name. Remote clients accessing the "db2inst2" instance have this instance cataloged in their node directory using "node20" as the host name. Under normal operating conditions, "db2inst1" is running on "node10", and "db2inst2" is running on "node20". If "node10" were to fail, the failover script will start "db2inst1" on "node20", and the external IP address associated with "node10" will be switched over to "node20". Once the instance has been started by the failover script, and the database has been restarted, the remote clients can connect to the database within this instance as if it were running on "node10".
Sample script:
hacmp-s4.sh
Mutual failover of partitions in a partitioned database server environment requires that the failover of the partition occur as a logical node on the failover processor. For example, if we have two partitions of a partitioned database server running on separate processors of a two-processor HACMP cluster configured for mutual takeover, the partitions must failover as logical nodes. The default partition at each node must be defined as logical node 0, meaning that when a partition fails over from one processor to another, it will start as a logical node having no direct remote communication protocol listeners. Such a partition cannot be used as a coordinator node.
One other important consideration when configuring a system for mutual partition takeover pertains to the local partition database path. When a database is created in a partitioned database environment, it is created on a root path that is not shared across the partitioned database servers. For example, consider the following command:
CREATE DATABASE db_a1 ON /dbpath
This command is run under instance "db2inst", and creates the database db_a1 on /dbpath. Each database partition is created on its local file system under /dbpath/db2inst/nodexxxx, where xxxx represents the node number. HACMP failover will attempt to mount the /dbpath file system, which is already being used by the other processor. Therefore, the failover script must mount the file system under a different logical point, and set up a symbolic link from that file system to the appropriate /dpath/db2inst/nodexxxx path.
Following is a portion of the db2nodes.cfg file, both before and after the failover. In this example, node number 2 is running on processor 1 of the HACMP machine, which has both a host name and a net name of "node201". Node number 3 is running on processor 2 of the HACMP machine, which has both a host name and a net name of "node202".
Before:
1 node101 0 node101
2 node201 0 node201 <= HACMP
3 node202 0 node202 <= HACMP
4 node301 0 node301
db2start nodenum 2 restart hostname node202 port 1 netname node202
After:
1 node101 0 node101
2 node202 1 node202 <= HACMP
3 node202 0 node202 <= HACMP
4 node301 0 node301
After the failover, any remote clients trying to directly access node number 2 as the coordinator will have to recatalog the node entry for the database to point to the failover node. Using a mutual failover scenario for coordinator nodes is not recommended. If you require redundancy for your coordinator node, use the hot standby configuration.
Sample script:
hacmp-s5.sh