Recovery from RSSD Failure

If you cannot recover the most recent database state of the RSSD, recovering from an RSSD failure is a complex process. In this case, you must load the RSSD from old database dumps and transaction log dumps.

Note: It is not possible to migrate an RSSD database across platforms using commands such as, cross-platform dump and load, or bcp. To migrate, you must rebuild the replication system on the new platform.

The procedure for recovering an RSSD is similar to that for recovering a primary database. However, it requires more steps, since the RSSD holds information about the replication system itself. RSSD system tables are closely associated with the state of the stable queues and of other RSSDs in the replication system.

If a Replication Server RSSD has failed, you first need to determine the extent of recovery required. To do this, perform one or more of the following actions:

When the RSSD becomes available, log in to the Replication Server and execute admin who_is_down. Some Replication Server threads may have shut down during the RSSD period of inactivity.
- If an SQM thread for an inbound or outbound queue or an RSI outbound queue is down, restart the Replication Server.
- If a DSI thread is down, resume the connection to the associated database.
- If an RSI thread is down, resume the route to the destination database.
Check all connecting RepAgents to see if they are running with the sp_help_rep_agent system procedure. (RepAgents may have shut down in response to errors resulting from RSSD shutdown.) Restart them if necessary.
If you cannot recover the RSSD’s most recent database state, you must load it from old database dumps and transaction log dumps.

Procedures to Recover an RSSD from Dumps
The procedure you use to recover an RSSD depends on how much RSSD activity there has been since the last RSSD dump. There are four increasingly severe levels of RSSD failure, with corresponding recovery requirements.
Using the Basic RSSD Recovery Procedure
Restore the RSSD if you have executed no DDL commands since the last RSSD dump. DDL commands in RCL include those for creating, altering, or deleting routes, replication definitions, subscriptions, function strings, functions, function-string classes, or error classes.
Using the Subscription Comparison Procedure
Follow this RSSD recovery procedure if you have executed some DDL commands since the last transaction dump but you have not created any new subscriptions or routes.
Using the Subscription Re-Creation Procedure
Restore an RSSD that requires that lost subscriptions be re-created if you have created new subscriptions or other DDL since the last transaction dump, and you have not created new routes.
Using the Deintegration and Reintegration Procedure
If you created routes since the last time the RSSD was dumped, you are required to follow the deintegration and reintegration procedure.

Parent topic: Replication System Recovery

Related reference

Procedures to Recover an RSSD from Dumps