Using Log Shipping or Database Mirroring with Notification Services
If you do not need the fast and automatic failover provided by failover clustering, but want high availability for your notification applications, you can maintain a standby server that you can bring online after failures or during server maintenance. The standby server contains a copy of each database used by the instance of Notification Services.
To automatically maintain a standby database server, you can use log shipping or database mirroring.
Using Log Shipping
Log shipping allows you to maintain a warm standby server for a particular database by automatically sending transaction log backups from that database (known as the primary database) to a secondary database on another server (known as the secondary server). At the secondary server, these transaction log backups are restored to the secondary database, keeping it in close synchronization with the primary database.
When you use log shipping with Notification Services databases, we strongly recommend using the same database for instance and application data. You can specify a database name in the instance configuration and each application definition. If you use separate databases for the instance and its applications, make sure that each database uses the same log shipping schedule so that the standby databases are updated at the same time. If the databases are updated at different times, application errors may occur. For example, you might have subscriptions in the application database for subscribers that do not exist in the instance database.
If you bring the secondary server online, you need to reregister and update the instance of Notification Services:
- You must reregister the instance to modify the database server specified for the instance of Notification Services. Make sure you do this on all servers where the instance is registered, including servers that run engine components, subscription management interfaces, and non-hosted event providers.
- You must change the SQL Server system value in the instance configuration, and possibly the system name values in the application definitions, and then update the instance of Notification Services to apply the changes.
For more information about using log shipping, see Log Shipping.
To switch an instance of Notification Services to a standby server
Using Database Mirroring
Database mirroring provides an alternative or supplement to failover clustering or log shipping. Database mirroring maintains a standby server that acts as either a hot standby server, which supports rapid failover with no loss of committed transactions, or a warm standby server. With a hot standby server, after a production server fails, the standby server becomes the production server. Client applications can then recover quickly by reconnecting to the new production server.
Notification Services engine and client components do not automatically switch to standby servers. However, you can use database mirroring much like you use log shipping. When the standby server comes online, you can update your instance of Notification Services to use the new server.
For more information about database mirroring, see Database Mirroring.
To switch an instance of Notification Services to a standby server
Standby Server Recommendations
Follow these recommendations for using log shipping or database mirroring with common Notification Services configurations.
- If you have a single-server deployment of Notification Services (where the Notification Services engine and the databases are on the same server), you should mirror the directory structure that contains the instance's operational files on the secondary server. Having all files in place simplifies switching to the secondary server.
- To make switching to the secondary server even easier, you can prepare the instance configuration and application definitions with the secondary server name, and then register the instance of Notification Services in advance. Then, when you switch to the secondary server, you can simply update the instance of Notification Services and start the instance.
- If the Notification Services engine runs on a separate server from the database server, you can maintain secondary server versions of the instance configuration and application definitions. These secondary server versions contain the secondary server names for the database server and, if necessary, non-hosted event providers, generators, and distributors. After you bring the secondary database server online, update the instance of Notification Services using the secondary-server copies of the instance configuration and application definitions.
See Also
Other Resources
Log Shipping
Database Mirroring
Maintaining High Availability
Administering Notification Services