Standby Server Failover

There are two basic approaches for protecting and replicating data The first is what is called "Planned Outage" and is used in planning for upgrades to existing servers, hardware upgrades, or migration of the database software and database files to another server. The second approach, which is called "Unplanned Outage", should be used in the event that the database server becomes unavailable and the data must be brought up at another location. Planned Outage requires a one-time set of procedures for migrating the database server and all of its associated files to another Target server with as little interruption as possible to database users. Unplanned Outage is designed to minimize the impact of a complete outage on the primary database server. In an outage scenario, the primary database server may be totally unavailable and potentially unrecoverable. This solution provides for an alternate target server to be available and up-to-date with the latest copy of the database software installed and the current database and associated files available to bring online in the event that the primary server is completely unavailable.

If a planned or unplanned outage on the primary server requires you to take the primary database out of service for an extended period of time, you can "Failover" to a target database by performing recovery on the target database which will bring it up-to-date with the latest backup set (if necessary) and bring the database to a recoverable by performing a role change of the standby target server. The failover process is mostly a manual process and must be initiated by an end-user. A future version of Peer DRS will provide functionality to help automate this task.

Depending on your environment and configuration, you will either be failing over an entire database server and all databases residing on that instance, or just individual databases.

The failover process will differ slightly based on which database platform is in place (e.g. MS SQL Server, MS Exchange Server, etc); however, in general, the following tasks must be performed in order to bring the standby server online:

1.	Perform one last incremental backup for the replication job(s) you are interested in failing-over (if possible).

For each primary database you plan to failover, identify the target database you would like to failover to, and perform "database recovery from latest backup set" using the Target Database Operations menu item. Doing so will disable all job schedules of the replication job by setting it to manual mode, and will also disable the target's restore job.

3.	Where applicable, perform a database role change to target database server and bring the target database online. This may not be necessary if step 2 succeeded. See the Replication Modules section for additional information specific to your database platform.

Where applicable, transfer any logins that exist on the primary server to the standby server. Only the logins that must have access to the target database must be transferred. You can setup Peer DRS to replicate the login database as a separate replication job to eliminate this step (e.g. MS SQL Server master database). This step might be further complicated if logins with the same name exist on both servers. The Exchange equivalent would be to reconnect user mailboxes in Active Directory to the target standby server Exchange mailboxes.

5.	Make appropriate DNS or NIC configuration changes to point the previous primary database server IP address to the target database, or make changes to your application(s) to point to the target database server's IP address.

See the Replication Modules section for information specific to your database platform.

If you did not originally configure a standby target database for the primary database job and only copied database files to the Shared Backup Folder, or created a File Copy Only target, you can still failover to a specific target database by running Peer DRS and adding the target database to the primary database replication job. After adding the target, you will need to run Perform database recovery from latest backup set on the target, which will bring the target up-to-date and in a ready to use state. This "on-demand" Target capability is useful in situations where you do not want to have additional copies of the database server software running on the targets due to extra licensing fees. In this case, it is recommended that you run Peer DRS on a different machine than the primary server so that you can have Peer DRS perform "on-demand" target recovery in case the primary server is no longer available. For the same aforementioned reasons, and whenever possible, we also recommend that the Shared Backup Folder be located on a server different than the primary database.