HP NonStop RDF, Руководство по управлению

Страница: 147 / 478

in order to resume business operations on your backup system. Do it when you can schedule
down time or do it during periods of low activity. Since a lot can change over the course of
a year, it is a standard disaster recovery practice that you perform this exercise at least once
a year. The age old adage is "practice makes perfect", and this certainly applies here. An
annual test run can mean a considerable difference between a lengthy RTO versus a rapid
RTO. The latter is always the goal, so one test a year is a small price to pay for the assurance
that you have everything you need and that your switch from the primary to the backup
goes as smoothly as possible. Secondly, practicing the movement of business operations
from your primary system to your backup promotes faster and smoother switchover
operations when you need to take down your primary system to perform software or
hardware upgrades.
NOTE:
A common myth in the data replication arena is "an Active-Active environment is
what I want, then my takeover and switchover testing is easy", and a myth this is. For most
NonStop users, the hardest part of switching from the primary to the backup is dealing with
the communications switching. Active-Active requires dealing with the same issues up front
in order to set up an Active-Active environment in the first place, and a switchover operation
involves the same issues for being able to route all work to one side or the other.
Some suggestions for how to set up your test are as follows:
• Down CPUs 0 and 1 on your primary system to simulate an unplanned outage
• Execute the RDF Takeover operation
• Execute the various scripts you have to resume business operations on your backup
system
• Test your applications against your backup database
• When you have finished your testing, clean up the backup database
• Either make your backup system your new primary, or switch business operations back
to your original primary system.
13. Suggestions for cleaning up your backup database after a test.
a. If your database is small, you might just resynchronize it from your primary system.
b. If synchronization is not an option, then you can use the TMF Recover Files to Time
facility by observing the following steps:
–
After completion of the RDF takeover operation and before starting your testing,
create an audited Enscribe file and take note of the system time.
– Perform your test, including running your applications with test data.
– Verify that all is running correctly
– Stop your applications
– If your testing involved unaudited files, restore these to their pre-test state.
– Execute a TMF Recover Files to Time operation, specifying the timestamp obtained
above after creating the Enscribe file.
– If you had brought your primary system down after stopping your applications,
then you are ready to reinitialize RDF and restart it to run from primary to backup
– If you had practiced an actual unplanned takeover while your applications were
running, then read the subsequent section on Restoring the Primary System.
Restoring the Primary System
After you initiate a takeover, it is possible that the last committed transactions on the primary
system did not make it to the backup system (meaning that the backup and primary databases
are not synchronized). When the failed primary system is restored to operable condition you
have two methods of resynchronizing your primary database with your backup database where
your applications are now running. One method is online, and the other is offline.
Takeover Operations 147