Set the Replication State of Subscribers

The state of a subscriber replication agent is described by its master database. When recovering a failed subscriber database, you must reset the replication state of the subscriber database with respect to the master database it communicates with in a replication scheme.

You can reset the state of a subscriber database from either the command line or your program:

From the command line, use ttRepAdmin -state to direct a master database to reset the replication state of one of its subscriber databases.
From ttIsql, call the ttRepSubscriberStateSet built-in procedure to direct a master database to reset the replication state of one or all of its subscriber databases.

See Show State of Replication Agents.

A master database can set a subscriber database to either the start, pause, or stop states. The database state appears as an integer value in the STATE column in the TTREP.REPPEERS table, as shown in Table 11-1.

Table 11-1 Database States

State	Description
`start` `STATE` value: 0	Replication updates are collected and transmitted to the subscriber database as soon as possible. If replication for the subscriber database is not operational, the updates are saved in the transaction log files until they can be sent.
`pause` `STATE` value: 1	Replication updates are retained in the log with no attempt to transmit them. Transmission begins when the state is changed to `start`.
`stop` `STATE` value: 2	Replication updates are discarded without being sent to the subscriber database. Placing a subscriber database in the `stop` state discards any pending updates from the master's transaction log. WARNING: If you are planning on restarting this subscriber, updates are not stored between the stop and the restart. Therefore, when you restart, the subscriber does not contain all of the updates from the master. If you are planning to restart, pause the subscriber instead of stopping it.
`failed` `STATE` value: 4	Replication to a subscriber is considered failed because the threshold limit (log data) has been exceeded. This state is set by the system is a transitional state before the system sets the state to `stop`. Applications that connect to a `failed` database receive a warning. See General Failover and Recovery Procedures.

When a master database sets one of its subscribers to the start state, updates for the subscriber are retained in the master's log. When a subscriber is in the stop state, updates intended for it are discarded.

When a subscriber is in the pause state, updates for it are retained in the master's log, but are not transmitted to the subscriber database. When a master transitions a subscriber from pause to start, the backlog of updates stored in the master's log is transmitted to the subscriber. (There is an exception to this, which is described in Managing Database Failover and Recovery.) If a master database is unable to establish a connection to a stated subscriber, the master periodically attempts to establish a connection until successful.

To use ttRepAdmin from the command line to set the subscriber state. This example directs the masterds master database to set the state of the subscriberds subscriber database to stop:

ttRepAdmin -dsn masterds -receiver -name subscriberds -state stop

Note:

If you have multiple subscribers with the same name on different hosts, use the -host option of the ttRepAdmin utility to identify the host for the subscriber that you want to modify.

On the master database, call the ttRepSubscriberStateSet built-in procedure to set the state of the subscriber database (subscriberds ON system1) in the repscheme replication scheme to stop:

CALL ttRepSubscriberStateSet('repscheme', 'repl',
          'subscriberds', 'system1', 2);

Only ttRepSubscriberStateSet can be used to set all of the subscribers of a master to a particular state.The ttRepAdmin utility does not have any equivalent functionality.