The default configuration for LPS-SQL protects only the master database on the primary server, and the Continuous Data Protection (CDP) feature is turned off. This means that out of the box, LPS-SQL is configured to protect only the system databases, so you need to tell LPS-SQL which other databases you want to protect. This is a much better default than a “protect all,” especially when large databases might be present in the instance. Using the Web and Java-based administrative interface from a Windows XP system, I enabled protection for several of the server’s databases.
I also configured an application running on another system to use the DNS host name I had defined for the switchable IP address assigned to the protected SQL server server, which provided a stream of data for testing. I performed a manual failover, then a manual failback. Next, I turned off the active server, forcing a failover. In each case, the failover completed quickly and in a minute or so my application was again accessing the database at its new location.
During my initial configuration of LPS-SQL, I also enabled Rewind—LPS-SQL’s CDP feature. Since LPS-SQL monitors protected data at the volume level, you configure Rewind at the volume level, by providing a location on a non-replicated volume for the Rewind log file, and by enabling Rewind on each active and standby server that contains a replicated instance of the volume resource on which you might want to perform a rewind. Note that because LPS-SQL monitors and logs I/O activity at the level of a volume rather than a database, LPS-SQL isn’t aware of SQL Server transactions and doesn’t make use of SQL Server transaction logs when rewinding data.
To return data to an earlier state, you perform the data rewind on a standby server. LPS-SQL pauses mirroring to the standby server, and offers the option to pause application activity on the active server. When you’ve rewound the data to the desired state, you can either manually restore the affected data to the active SQL Server server or have LPS-SQL switch over to the standby server that now holds the valid data, making it the active server.
I tested the data-rewind feature by generating application activity over about half an hour, then restored the volume to an earlier state using the Rewind wizard within the LPS-SQL console. LPS-SQL provided me with about two dozen time-stamped rewind points for the interval.
The Rewind wizard doesn’t display all available rewind points. Because LPS-SQL records every write in the rewind log, the number of potential rewind points can be quite large. Instead, LPS-SQL allows you to manually enter a specific date and time you wish to rewind to; and to create a bookmark within the rewind log for specific points in time that simplify selection of that rewind point. I think I would prefer an option to filter and search through all the timestamps in the rewind log.
I selected an early point and allowed the recovery to finish. To check the data, I needed to start the SQL Server service on the standby server. (As I stated earlier, LPS-SQL pauses replication and mirroring to the standby server where you are performing the rewind.) I then was able to examine the data using SQL Server Management Studio.
To test the iterative rewind option, I decided to move the recovery point forward in time—LPS-SQL lets you move forward and backward within recovery points until you are satisfied with the state of the data. When the second rewind completed, I declared the data good, and took the LPS-SQL option to switch application processing over to the standby server. The switchover was completed in about a minute.
How Granular Are Your Data-Rewind Needs?
LifeKeeper’s support for failover to remote systems and its ability to incorporate a variety of hardware configurations into the same cluster makes it a very flexible product to work with. Overall, the failover and rewind operations worked well, and I liked the ease of configuration and the ease with which the data-rewind feature worked.
The documentation is well organized, though at present it doesn’t integrate the data replication and high availability components as well as it might. It also doesn’t always provide the depth of explanation you might want.
If you're looking for a product that presents very granular data-rewind points, perhaps LPS-SQL might not appeal to you. However, if you're looking for an easy-to-implement, high availability product with a decent—not great—data-rewind feature, I suggest you bring LPS-SQL in for a test.
Prev. page
