I have written quite a few articles on TSA, but thus far, they’ve been strongly focused on the basic how-to. I think this is because so many of us start with the how of a technical topic. As my knowledge has advanced, I have developed more advanced presentations on TSAMP, but I need to also bring that content into the blog.
Objects that db2haicu creates
When you run db2haicu, it is creating a whole host of objects and relationships at the TSAMP level. It can take a while to understand what all of these mean. I found this awesome article that defines a lot of the objects. It also goes into greater detail on a number of things that may be useful if you’re trying to increase your TSAMP knowledge.
The following diagram represents the objects that db2haicu creates:
In this image, the grey rectangles labeled Node1 and Node2 represent the two servers – the primary and the standby. The largest green rounded rectangle is the TSAMP domain that is created. db2haicu asks us for the name, and we make up the name for it. The other objects and elements are created within this domain.
There is then a DB2 instance resource group created for each node and an instance resource within each resource group. These are active and considered up on both the primary and standby servers at once, just like the DB2 instance exists and is active on both servers at once – you can log in and start, stop, and configure it at any time on either server.
An additional resource group is created for the database. Within that database resource group a database resource and a VIP resource (assuming you’re using one) are created. They can only be active on one node at a time and are always offline on the other node.
Differences with Multiple Databases
With the previous diagram in mind, let’s look at what happens if we add in another database on the same DB2 instance:
A whole additional database resource group, and therefore another VIP is added. Yes, that’s right – if you have more than one database, you will have more than one VIP. This means that if the two databases both happen to have their primaries on the same server, either VIP will work, but in case of a failover for only one database, each database will only be accessible at their own VIP. This is the supported and recommended method by IBM. I would like to see instructions on how to instead create a relationship that would force the databases to failover together, allowing me to use only one VIP, but I can certainly see cases where this configuration is the way to go, and clients that would absolutely need it this way.
I faced before a situation where not all databases were not failed over together. Do you follow any best practice/rule of thumb in your environments? Maybe a next post topic to explore? 🙂
Databases are not failed over together by default. You would have to create a relationship to make that happen. I don’t have the syntax for how to make that happen, but it would be a TSAMP command and not a db2 command.
Ember, the granularity of failover is at the *database level*. i.e. db2haicu is hooked into the runtime for HADR failover (TAKEOVER, TAKEOVER BY FORCE, etc.), and these HADR state change commands are at the granulaity of the *database*. Hence, anything that ties together multiple databases is problematic (i.e. a shared VIP). The granularity of HADR TAKEOVER is then multiple databases. Anyhow, there’s no real reason to use VIPs anymore (it isn’t the 1980’s anymore), just use ACR. Cheers,
I have found a number of applications don’t play nice with ACR and have to be manually configured to be aware of the standby, including those like WebSphere Commerce that use JDBC type 4 drivers. A virtual IP is much easier for many of my clients than ACR.