H A D R
High Availability Disaster Recovery
Demystified in IBM DB2 8.2
(Level 200 Session)
By
Anil Mahadev
Database Technologist and DB2 User
Introduction:
HADR stands for High Availability Disaster Recovery, a new technique introduced in IBM DB2 8.2.
This is a technology so good, that it was save DBAs time and effort to take care of High Availability their databases in an event of timed or untimed Downtime.
HADR Replicates data from a primary database (also known as the source) to a secondary database (also known as the target).
This ensures a reliable way for taking effective measures in keeping the database up and running.
Let us discuss what you need in order to implement HADR in your organization using IBM DB2 8.2.
System Requirements:
A basic P4 Machine with 512 MB RAM and about 20 GB HDD, a pointing device,
A keyboard and a monitor.
Software Requirements
1) Windows 2000 and above.
2) A personal copy of DB2 UDB 8.2 for Windows. Please note since this is not a development environment, we may need to use the DB2 Enterprise Server Edition.
Please note: HADR is a licensed feature and does not come as part of DB2 Express or Personal Editions.
It is provided by the
3) You may download a free trial from IBM’s Website or Order the IBM Software Evaluation Kit.
Now that we have our machines setup for HADR; let me explain a few points before actually showing you the power of HADR.
Steps needed to setup HADR in DB2.
Setup
During this phase, we will have to recognize both our Primary and Secondary Database Servers.
Note: The primary database here refers to the DB2 instances present on the local or remote machine and secondary vice-versa.
To successfully implement HADR on your local machines;
Follow these steps.
Install two instances
of DB2 on your machine. One could be a personal edition and an
Using the
But
It is the most important phase; one cannot afford to go wrong, as critical data would be at risk.
After determining our primary and secondary servers, take a backup of the primary database and restore it to the secondary database.
Once this is done, we can be rest assured our replication will be successful.
After this HADR will be started on both the Primary and
Secondary databases
The secondary database now enters, what is known as a CATCH-UP Phase.
This means, whenever data transactions occur after the backup was being made to the primary database, gets reflected automatically the secondary database.
After this phase is complete, the secondary database’s state is now in PEER.
This means that whatever changes have been made to the primary database gets reflected in the secondary database.
I will now show you, on how to setup HADR on your computers.
To display the HADR Dialog, Click on the Tools of the Control
center and choose Wizards.
Under Wizards Choose à Set Up High Availability Disaster Recovery (HADR) Databases. And you will be presented with a screen as shown in Fig 1.1
Figure 1.1
3) Next we need to specify our primary database, in order to, successfully replicate data to the standby database. By default CIRCULAR LOGGING is enabled, you will need to enable log shipping by clicking on Configure and then follow the instructions.
Once the log shipping has been enabled to ARCHIVE MODE, you will see two check marks, meaning your primary database is now ready. The dialog is shown below.
Figure 1.2
4) Once we have our primary database setup, we need to tell DB2 about our standby database instance. It is done automatically once you select the respective System Name and Instance Name as shown in figure 1.3. Click Next to continue.
Figure 1.3
Once we specify our standby database, we will have to mention, where the primary database backup will be kept.
To do this we will have to select a backup image that we have taken previously.
I have taken a backup previously, so that is why it is displaying
me two backup locations. If you don’t have a backup of the primary
database, you can do so immediately using the
The backup selection is shown in figure 1.4 below. Please choose Select a backup image , in case the backup is ready, or choose Backup Primary database to create a new backup.
Figure 1.4
Now that we have backed up our database, we will have to restore it to the standby database in order for replication to take place.
Automatically as shown in figure 1.5, the restore command is created for us, thanks to DB2J.
Figure 1.5
Here comes the good stuff J !!! . In this screen as shown in figure 1.6, we need to specify the TCP/IP parameters of both the primary and secondary HADR databases.
Please note the following:
Your Primary HADR Instance: Will have 55001 as the port.
Your Standby HADR Instance: Will have 55002 as the port.
Remember both the ports are designated by DB2.
Once the above two are set, we have made both the instances talk together.
And both the settings are shown in fig 1.6.
Figure 1.6
In this next section, we shall have to configure our DB2 Database Instance ports.
By default, the primary instance port will be 50001 and the standby instance will be 50000 as shown in Fig 1.7. This will enable the Client Re-route to the standby server from the primary server, when the take over takes place.
Client Re-route: Client Re-route is the process of automatically accepting client requests from the primary database to the secondary database.
The re-route takes place when HADR is enabled and the Takeover HADR Command is issued.
Please Note: HADR Instances are different from DB2 Database Instances.
Figure 1.7
We now move on to the section of Synchronization mode, between the primary and secondary databases, when a HADR command is being issued.
There are three modes of Synchronization.
They are:
1. Synchronous: This mode guarantees no loss of
data and supports fail-back.
2. Near Synchronous: This mode guarantees no loss
of data for a single point disaster, which means that, if we are running two
database servers from one location only. And fail-back is supported. This is
the
3. Asynchronous: In this mode, log data of the primary database does reach the standby database. This is mode is least preferred as DBAs do not get the info about the loss of data. And fail-over is not supported.
The details of the above scenarios are shown in figure 1.8. We shall be using the default mode, near synchronous. Click next to continue.
Figure 1.8
The final screen of setting up HADR is the summary window. All we have to do now is make sure that Start HADR option is checked and Click Finish as shown in Figure 1.9.
Note: This will be the last screen, you may review your choices, once again before clicking non Finish.
Figure 1.9
After you have clicked Finish, you will get a dialog as shown below in figure 1.10
Remember to enable Federated Database support for both your primary and secondary databases, so that you will receive no errors.
Figure 1.10
This next screen will show you the local database (on my local machine. This is my DB2 Instance). The Sample database is the primary database as shown in figure 1.11.
Figure 1.11
The next screen shows us the remote copy of our sample database (also on my local machine. This is my second DB2 Instance) as shown in figure 1.12.
Figure 1.12
This completes the section on Setting –up HADR. We now need to perform the Take Over between the Primary and Secondary Database.
Rolling Upgrade
There comes a time when we DBAs have to patch our databases on a regular basis to keep the database up and running and without having to bring down the server.
With DB2’s HADR capabilities, we can perform a Rolling Upgrade, that is, applying patches to the primary database, issuing the HADR Take Over command, and make the secondary database in a peer state, as that of the primary.
One can exchange roles gracefully without having to worry.
With the
To manage HADR à Click on the SAMPLE Database and Choose HADR (I am shortening it) and choose Manage.
As shown in Figure 1.13
Figure 1.13
As shown in the figure 1.14 below, we can see the default HADR Dialog.
In this screen we can configure both the primary and standby databases.
The database colored in blue is the primary database and the one colored in red is the standby database.
When you click on the Takeover HADR Command button, it will display a message stating that that the switch has been made. I will explain this in the next section.
Figure 1.14
Emergency Take Over
In corporations today, there tend to be planned or unplanned outages.
This could be due to a power failure etc.
When this happens, DB2’s HADR capability is there to help.
One must make sure that the Takeover now, the standby database, to the, primary database is made possible as transactions will be affected.
To overcome this, make sure your primary database is shutdown and then issue the Takeover HADR Command to prevent two primary databases from co-existing.
In figure 1.15, shows us when, our primary and standby databases are within, their default roles.
Figure 1.15
This completes the Executive Failover topic of HADR.
Demonstration of HADR using the Switch Roles Option, part of the Rolling Upgrade topic.
From this point on I will show you on how to perform a Rolling Upgrade in DB2 UDB 8.2 using the HADR Feature.
Now that we are in the HADR Screen, perform the following steps.
The Takeover HADR command will ask us on what to do? For this article I have covered Switch roles option for better understanding.
After clicking on the Takeover HADR Button, we are presented with the following screen as shown in figure 1.16.
Click on the Switch roles option and click OK. After that you will be presented with a message stating the Takeover HADR Command was
successful.
As you can see, my Primary Database is AMINCà DB2 and the role to be switched will be AMINCàDB22.
Figure 1.16
After the Takeover is done. You will be presented with the new dialog as shown in figure 1.17.
The primary database is now the standby database. And the standby database in now the primary database.
Congratulations J You have successfully implemented HADR!!! On your machine, DB2 Rocks J
Figure 1.17
This completes our comprehensive tour of HADR and how to implement HADR using IBM DB2 8.2.
As many of us entry level DBAs and intermediate DBAs will have the competitive advantage and will know on how to implement a Disaster Recovery Solution using IBM DB2 8.2 HADR feature.
We would like to thank IBM for implementing such a wonderful feature and hope new features will add value to IBM DB2J.
HADR does not end here. Practice, Practice and more Practice!!! .
That’s how we learn on how to implement various features in DB2.
Don’t get it right the first time, try and try again!!! I am sure you will succeed.
Please do drop me a line and let me know your feedback on the article, or
anything in general with respect to databases.
Please feel free to mail me your comments and valuable inputs on how I can write better in DB2.
Anil Mahadev
And please mention in the Subject Line as “Article on HADR Demystified”
IBM DB2 UDB Logois
Copyright of IBM (International Business Machines) Corporation,