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 |
---|---|
|
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. |
|
Replication updates are retained in the log with no attempt to transmit them. Transmission begins when the state is changed to |
|
Replication updates are discarded without being sent to the subscriber database. Placing a subscriber database in the 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. |
|
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 |
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.