Fail Over to a Log Shipping Secondary (SQL Server)
Topic Status: Some information in this topic is preview and subject to change in future releases. Preview information describes new features or changes to existing features in Microsoft SQL Server 2016 Community Technology Preview 2 (CTP2).
Failing over to a log shipping secondary is useful if the primary server instance fails or requires maintenance.
Typically, the primary and secondary databases are unsynchronized, because the primary database continues to be updated after its latest backup job. Also, in some cases, recent transaction log backups have not been copied to the secondary server instances, or some copied log backups might still not have been applied to the secondary database. We recommend that you begin by synchronizing all of the secondary databases with the primary database, if possible.
For information about log shipping jobs, see About Log Shipping (SQL Server).
To fail over to a secondary database:
Copy any uncopied backup files from the backup share to the copy destination folder of each secondary server.
Apply any unapplied transaction log backups in sequence to each secondary database. For more information, see Apply Transaction Log Backups (SQL Server).
If the primary database is accessible, back up the active transaction log and apply the log backup to the secondary databases.
If the original primary server instance is not damaged, back up the tail of the transaction log of the primary database using WITH NORECOVERY. This leaves the database in the restoring state and therefore unavailable to users. Eventually you will be able to roll this database forward by applying transaction log backups from the replacement primary database.
For more information, see Transaction Log Backups (SQL Server).
After the secondary servers are synchronized, you can fail over to whichever one you prefer by recovering its secondary database and redirecting clients to that server instance. Recovering puts the database into a consistent state and brings it online.
When you make a secondary database available, you should ensure that its metadata is consistent with the metadata of the original primary database. For more information, see Manage Metadata When Making a Database Available on Another Server Instance (SQL Server).
After you have recovered a secondary database, you can reconfigure it to act as a primary database for other secondary databases.
If no other secondary database is available, see Configure Log Shipping (SQL Server).