You use the DB2MSCS utility to create the infrastructure for DB2 to support failover on the Windows NT environment using MSCS support. You can use this utility to enable failover in both single-partition and partitioned database environments.
You run the DB2MSCS utility once for each instance on its instance-owning machine. If there is only one DB2 instance running on one machine in the MSCS cluster, this sets up a hot-standby configuration. If you have an instance running on each machine in the MSCS cluster, you would run DB2MSCS once on each instance-owing machine to set up a mutual takeover configuration.
The DB2MSCS utility performs the following steps:
The syntax of the DB2MSCS utility is as follows:
>>-DB2MSCS---+------------------+------------------------------>< '--f:--input_file--'
Where:
The DB2MSCS.CFG file is an ASCII text file that contains parameters that are read by the DB2MSCS utility. You specify each input parameter on separate line using the following format: PARAMETER_KEYWORD=parameter_value. For example:
CLUSTER_NAME=WOLFPACK GROUP_NAME=DB2 Group IP_ADDRESS=9.21.22.89
Two example configuration files are in the /CFG subdirectory of the /SQLLIB directory. The first, DB2MSCS.EE, is an example for single-partition database environments. The second, DB2MSCS.EEE, is an example for partitioned database environments.
The parameters for the DB2MSCS.CFG file are as follows:
This parameter has a global scope, and you specify it only once in the DB2MSCS.CFG file.
This parameter is optional.
Example:
DB2_INSTANCE=DB2
The instance must already exist. For information about creating instances, refer to the DB2 Extended Enterprise Edition for Windows NT Quick Beginnings.
This parameter has a global scope, and you specify it only once in the DB2MSCS.CFG file.
This parameter is only required for DB2 Extended Enterprise Edition instances.
Example:
DB2_LOGON_USERNAME=db2user
This parameter has a global scope, and you specify it only once in the DB2MSCS.CFG file.
This parameter is only required for DB2 Extended Enterprise Edition instances.
Example:
DB2_LOGON_PASSWORD=xxxxxx
Specify this parameter once for each cluster.
This parameter is optional. If not specified, the name of the MSCS cluster on the local machine is used.
Example:
CLUSTER_NAME=WOLFPACK
Specify this parameter once for each group.
This parameter is required.
Example:
GROUP_NAME=DB2 Group
You specify this parameter after the GROUP_NAME parameter so that the DB2 resources are created in the correct MSCS group.
This parameter is only required for DB2 Extended Enterprise Edition instances.
Example:
DB2_NODE=0
This parameter is required for remote TCP/IP connections. You must specify this parameter for the instance-owning machine in a partitioned database enviroment. This parameter is optional in single-partition database environments.
Example:
IP_NAME=IP Address for DB2
Note: | DB2 clients should use the TCP/IP address of this IP resource to catalog the TCP/IP node entry. By using the MSCS IP address, when the database server fails over to the other machine, DB2 clients can still connect to the database server because the IP address is available on the fail-over machine. |
The attributes of the IP resource are as follows:
This parameter is required if the IP_NAME parameter is specified.
Example:
IP_ADDRESS=9.21.22.34
This parameter is required if the IP_NAME parameter is specified.
Example:
IP_SUBNET=255.255.255.0
This parameter is optional.
Example:
IP_NETWORK=Token Ring
This parameter is optional for single-partition database environments. It is required for partitioned database enviroments.
Example:
NETNAME_NAME=Network name for DB2
The attributes of the Network Name resource are as follows:
This parameter is required if NETNAME_NAME parameter is specified.
Example:
NETNAME_VALUE=DB2SRV
This parameter is optional.
Example:
NETNAME_DEPENDENCY=IP Address for DB2
Notes:
Example:
DISK_NAME=Disk E: DISK_NAME=Disk F:
The DB2 instance directory is created on the MSCS disk under the X:\DB2PROFS directory (where X is the MSCS disk drive letter).
Example:
INSTPROF_DISK=Disk E:
When you run the DB2MSCS utility against a single-partition database system, one MSCS group contains DB2 and all the dependent MSCS resources (the IP address, Network Name, and disks). For example, the contents of the DB2MSCS.CFG for a single-partition database system will look like the following:
# # DB2MSCS.CFG for a single-partition database system # DB2_INSTANCE=DB2 CLUSTER_NAME=MSCS GROUP_NAME=DB2 Group IP_NAME=... IP_ADDRESS=... IP_SUBNET=... IP_NETWORK=... NETNAME_NAME=... NETNAME_VALUE=... DISK_NAME=Disk E:
You can set up two single-partition database systems, each on a separate machine, so that if the database system on any one machine fails, it is restarted on the other MSCS node.
To setup failover support for this configuration, you need to run the DB2MSCS utility once on each instance-owning machine. You must tailor the configuration file for each database system.
Assume that the DB2 instances are called DB2A and DB2B. The DB2MSCS.CFG file for the DB2A instance would be as follows:
# # DB2MSCS.CFG for first single-partition database system # DB2_INSTANCE=DB2A CLUSTER_NAME=MSCS GROUP_NAME=DB2A Group IP_NAME=... IP_ADDRESS=... IP_SUBNET=... IP_NETWORK=... NETNAME_NAME=... NETNAME_VALUE=... DISK_NAME=Disk E:
The DB2MSCS.CFG file for the DB2A instance would be as follows:
# # DB2MSCS.CFG for second single-partition database system # DB2_INSTANCE=DB2B CLUSTER_NAME=MSCS GROUP_NAME=DB2B Group IP_NAME=... IP_ADDRESS=... IP_SUBNET=... IP_NETWORK=... NETNAME_NAME=... NETNAME_VALUE=... DISK_NAME=Disk F:
For a full example, see "Example - Setting up Two Single-Partition Instances for Mutual Takeover".
When you run the DB2MSCS utility against a multipartition database system, one MSCS group is created for each physical machine that participates in the system. The DB2MSCS.CFG file must contain multiple sections, and each section must have a different value for the GROUP_NAME parameter and for all the required dependent resources for that group.
In addition, you must specify the DB2_NODE parameter for each database partition server in each MSCS group. If you have multiple logical nodes, each logical node requires a separate DB2_NODE keyword.
For example, assume that you have a multipartition database system that consists of four database partition servers on four machines, and you want to configure two MSCS clusters using mutual takeover configuration. You would set up the DB2MSCS.CFG configuration file as follows:
# # DB2MSCS.CFG for one partitioned database system with # multiple clusters DB2_INSTANCE=DB2MPP DB2_LOGON_USERNAME=db2user DB2_LOGON_PASSWORD=xxxxxx CLUSTER_NAME=MSCS1 # Group 1 GROUP_NAME=DB2 Group 1 DB2_NODE=0 IP_NAME=... ... # Group 2 GROUP_NAME=DB2 Group 2 DB2_NODE=1 IP_NAME=... ... CLUSTER_NAME=MSCS2 # Group 3 GROUP_NAME=DB2 Group 3 DB2_NODE=2 IP_NAME=... ... # Group 4 GROUP_NAME=DB2 Group 4 DB2_NODE=3 IP_NAME=... ...
For a full example, see "Example - Setting up a Four-Node Partitioned Database System for Mutual Takeover".