KB labels


Ticket Product Version

Ticket Category

Ticket Assignee


Hot Fixes

Published Fixes
Your Arcserve Support User Profile
First Name:
Last Name:
email:
Phone:
Company:*
Customer Type:
Language:

Country:
Region:

Time zone:
Follow

arcserve-KB : How Does the CA XOsoft Assured Recovery Feature Work

Last Update: 2015-12-15 22:20:24 UTC
Document ID:    TEC479019
Tech Document
Title:  How Does the CA XOsoft Assured Recovery Feature Work?

Description:

Assured Recovery is the testing tool within CA-XOSOFT that allows you to periodically test the integrity of the data on the Replica server. The following is a description of the Assured Recovery testing process.

Solution:

Assured Recovery is feature in CA XOsoft Replication and High Availability scenarios that can be used to test the integrity of the data on the Replica server. This tool allows you to keep the Master server running and users are allowed to continue working on the Master server while the data integrity on the Replica is verified.

When you start CA XOSOFT scenario, CA XOSOFT automatically dismounts the DB's on the Replica instance and stops all the application services (e.g. MS Exchange, MS SQL, Oracle, etc.). This is because during both CA-XOSOFT synchronization and replication, the data changes are being applied directly to the data files on the Replica server. If the DB's were mounted, as in when the application services are running, then the DB files would be considered 'open files'. This is the case if the files are open on the inactive server as well. If CA-XOSOFT were to attempt to commit changes to an open file, there would be an 'open file contention issue', which would inadvertently corrupt the file as a result. This would lead to database corruption on the Replica server.

If you wanted to periodically test the integrity of the Replica data, you would traditionally need to do one of the following:

  1. Actually perform a test switchover.

    OR
  2. Stop the replication scenario and manually verifying data integrity on the Replica server.

Manually performing a switchover would potentially introduce downtime if you to attempt a switchover during business hours and the process failed. Typically switchover tests are scheduled to be performed during a scheduled down time such during off hours at night or on a weekend. Frequently, this planned testing needs to be scheduled well ahead of time. In the case of a 24 x 7 business, there aren't typically opportunities for planned downtime. Any opportunities need to be planned far ahead of time and tend to have fairly short windows of opportunity.

If you were to manually start the applications services and mount DB's on the replica WHILE the scenario was running, then you would again encounter an issue where you would corrupt the DB files on the Replica. This would require that you stop the replication scenario before starting the services on the Replica and mounting the DB's, as described in option #2 (above). However, this would also leave you exposed due to a lack of replication. To ensure that the changes which were generated on the Master while the scenario was stopped are copied to the Replica you would need to resynchronize. Even if there were no changes made, the act of mounting a DB on a new host will modify that DB slightly. If you were to dismount the DB and resume replication without synchronizing, you would again corrupt the replica DB.

  • When an Assured Recovery test is run, the users remain active on the Master server, and continue committing changes to the active DB. CA XOSOFT continues running so as changes are committed to the DB, CA-XOSOFT continues to create replication journal files. When an Assured Recovery test is run, the replication journal files continue to be sent to the Replica server.

When the replication journal files arrive at a replica server they are normally applied to the corresponding data files on the Replica. However, during an Assured Recovery test, as the replication journal files arrive on the Replica, they are redirected to a separate directory and stored in that directory in sequential order until the Assured recovery testing process is completed.

During the Assured Recovery testing process, Assured Recovery will:

  1. Begin caching replication files arriving on the replica in the CA XOsoft spool directory
  2. Start the services on the Replica server and allow the DB's to mount.
  3. Determine whether the services started successfully and the DB's mounted successfully and whether the application is reporting any problems with the state of the replica instance.

    • Because CA XOSOFT is application aware for SQL, Exchange, Oracle, and IIS, CA XOSOFT will be able to
  4. When the test is completed the DB's are dismounted and the services are stopped.
  5. Assured Recovery then uses the built-in Data Rewind technology to rewind the Replica DB to a point in time prior to the DB being mounted.

    • This prevents a need to resynchronize the databases because now the DB's on the Replica are now in the same state they were in just prior to the initiation of the Assured Recovery test.
  6. The replication journal files being stored on the Replica server can now be applied to the corresponding data files.
  7. Any new replication journal files are no longer being redirected as they arrive on the Replica server. Instead they resume being committed to the data files.

    • Had the test been successful, then you'd know that the data would be intact and accessible for users in the event of a restore or a switchover.
    • If the test failed then there is a problem with the integrity of the Replica data, but now you can address the problem ahead of time because users are still up and running on the Master server.

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments