It is not difficult to create an efficient DB2 cluster service by using MSC correctly!

This article mainly explains how to use MSC to create an efficient DB2 cluster service. The following article mainly describes how to use MSC to create an efficient DB2 cluster service, the following is a detailed description of the relevant content, hoping to help you in this regard.

Working overtime on weekends, I learned that I was helping people build a Windows failover cluster. Although the main focus is on middleware, Windows has been studying for a year after all. Besides, I have worked on the MSC cluster in WebSphere and WebLogic, so I thought it was just a piece of cake, in the end, I couldn't think of it from AM to AM.

Working overtime on weekends, I learned that I was helping people build a Windows failover cluster. Although the main focus is on middleware, Windows has been studying for a year after all. Besides, I have worked on the MSC cluster in WebSphere and WebLogic, so I thought it was just a piece of cake, in the end, I couldn't think of it from AM to AM.

First, we adopt Oracle in Windows: both hosts enable database instances, and databases are stored in shared storage. By adding a common DB2 service to cluster resources, so as to achieve the Failover of database services.

It should be said that there is no problem in thinking, but there is a problem in implementation, that is, when a user connects, stopping the DB2 service will fail, and the second stop will be able to stop, in this way, it will be a problem to manually transfer the cluster. So we thought about how to execute the command to interrupt all database links before the database service is stopped ...... Meditation, multiple attempts, and so on.

At last, I went to IBM developerworks to find a document to find out that there was no need to worry about this. I only needed one copy of the instance, and the DB2 cluster service had prepared the DB2msce tool for you long ago. I only needed to write a copy of db2msc. cfg configuration file:

DB2_INSTANCE = DB2 // specify the name of the instance to be converted

DB2_LOGON_USERNAME = dbdomain/DB2admin // specify the domain user account used to log on to the instance

DB2_LOGON_PASSWORD = 0000 // specify the password of the user account used to log on to the instance domain

CLUSTER_NAME = MYCLUSTER // specify the cluster name

GROUP_NAME = DB2 Group A // specify the Group name used for this instance

DB2NODE = 0 // specify the DB2 node number corresponding to the group of resources

IP_NAME = MscsA // specify the name of the IP address resource used for this instance

IP_ADDRESS = 192.168.192.31 // IP address attribute of the specified IP address resource

IP_SUBNET = 255.255.255.0 // specify the subnet mask of the IP address resource

IP_NETWORK = Public Network // Network connection bound to the specified IP address resource

NETNAME_NAME = MscsAName // specify the name of the network name Resource

NETNAME_VALUE = DataCenter // specify the machine name attribute of the network name Resource

NETNAME_DEPENDENCY = MscsA // specify the name of the IP address resource corresponding to the Network Resource Name

DISK_NAME = disk e: // specify the DISK resources required by the node.

INSTPROF_DISK = E: // specify the disk resource where the node directory is located. You can enter the NAME option in the preceding configuration file, which is simple and clear. IP_ADDRESS is the floating IP address of the DB2 service, IP_NETWORK should be the NIC name that provides the Internet Service of the cluster. The three NETNAME options can be left blank and will not affect the use (because they are all connected by IP addresses ).

Run db2msc-f: db2msc. cfg command (note that F does not refer to the drive letter. cfg stored in the same directory of db2msc), you will see that A resource Group: DB2 Group A is automatically added to the DB2 cluster service, and A DB2 type service named DB2 is added, this service type is not available before.