Open topic with navigation

Failing over SQL jobs

When a failover condition has been met, failover will be triggered automatically if you disabled the wait for user option during your failover configuration. If the wait for user before failover option is enabled, you will be notified in the console when a failover condition has been met. At that time, you will need to trigger it manually from the console when you are ready.

1. On the Manage Jobs page, highlight the job that you want to failover and click Failover or Cutover in the toolbar.
2. Select the type of failover to perform.
• Failover to live data—Select this option to initiate a full, live failover using the current data on the target. The application services will be stopped on the source (if it is online), and they will be started on the target. DNS records will be updated, if applicable. Application requests destined for the source server or its IP addresses are routed to the target.

• Perform test failover—Select this option to perform a test failover using the current data on the target for standalone environments. This option is not applicable to clustered environments.This option will allow you to confirm SQL on the target is viable for failover. This process will pause the target (the entire target is not paused, just Double-Take replication), take a snapshot of the target (so that you can revert back to the pre-test state after the test is complete), and then start the application services on the target. Success and failure messages will be available in the job log. (Note the application services are still running on the source during the test.) Once the application services are running on the target, you can perform any testing desired on the target server.

  The following caveats apply to performing a test failover for SQL.

  • Make sure you have enough space on your target to contain the snapshot.
  • If you have scheduled Double-Take snapshots, they will continue to be created during the test, however, you should not use any of these snapshots from this time period because the target data may not be in a good state.
  • If you are using Windows 2008 R2 and Double-Take snapshots, any snapshots that you take before testing failover will be unusable for an actual failover. To work around this issue, take another snapshot immediately after the test. Once the additional, post-testing snapshot is taken, all of the previous snapshots will be usable for future failovers. This issue is fixed in the Windows 2008 R2 Service Pack 1 release. If you install that release, you will not have to worry about the extra snapshot after the test.

   

• Failover to a snapshot—Select this option to initiate a full, live failover without using the current data on the target. Instead, select a snapshot and the data on the target will be reverted to that snapshot. This option will not be available if there are no snapshots on the target or if the target does not support snapshots. This option is also not applicable to clustered environments. To help you understand what snapshots are available, the Type indicates the kind of snapshot.
  • Scheduled—This snapshot was taken as part of a periodic snapshot. 
  • Deferred—This snapshot was taken as part of a periodic snapshot, although it did not occur at the specified interval because the job between the source and target was not in a good state
  • Manual—This snapshot was taken manually by a user.
3. Select how you want to handle the data in the target queue. You may want to check the amount of data in queue on the target by reviewing the Statistics or Performance Monitor.
• Apply data in target queues before failover or cutover—All of the data in the target queue will be applied before failover begins. The advantage to this option is that all of the data that the target has received will be applied before failover begins. The disadvantage to this option is depending on the amount of data in queue, the amount of time to apply all of the data could be lengthy.
• Discard data in the target queues and failover or cutover immediately—All of the data in the target queue will be discarded and failover will begin immediately. The advantage to this option is that failover will occur immediately. The disadvantage is that any data in the target queue will be lost.
• Revert to last good snapshot if target data state is bad—If the target data is in a bad state, Double-Take will automatically revert to the last good Double-Take snapshot before failover begins. If the target data is in a good state, Double-Take will not revert the target data. Instead, Double-Take will apply the data in the target queue and then failover. The advantage to this option is that good data on the target is guaranteed to be used. The disadvantage is that if the target data state is bad, you will lose any data between the last good snapshot and the failure.
4. When you are ready to begin failover, click Failover.
5. If you performed a test failover, you can undo it by selecting Undo Failover in the toolbar. The application services will be stopped on the target, the pre-test snapshot that was taken will be reverted, and the target will be resumed.

Related Topics