Skip to main content

Replication state persistence

If the Replication Agent process terminates abnormally, it is desirable for the agent to resume replicating transactions from where it left off in the source server transaction logs. A persistent state is needed to maintain this information. This persistence requires that the Replication Agent always knows the last transaction it has committed to the target FairCom server.

To enable this persistent state, a special table is stored on the target server for this purpose, and for each transaction the Replication Agent commits it updates a replication state record on the target server in that same transaction. This way, the Replication Agent can always read its latest state from the target server, even if the Replication Agent process terminates, or should it lose its connection to the target server, or the target server terminates and restarts.

When multiple Replication Agents are connected to a single target server, it is necessary to maintain state information unique to each replication instance. To do this, a configurable unique ID can be assigned to each agent. The Replication Agent unique ID is a string with a maximum of 32 characters. The Replication Agent’s configuration file (ctreplagent.cfg) can specify the unique ID using the unique_id configuration option.

Example 1. unique_id
unique_id myreplagent

Note

If not specified, unique_id defaults to REPLAGENT.



Target server files

Once the replication has started and successfully connected to both the source and target servers, it will create a set of files on the target server which contains information about the current state and position of replication within the source transaction logs. This allows the Replication Agent to pick up from a previous session should a network connection fail, or the agent is paused for administrative purposes.

The files on the target server include:

  • REPLSTATEDT.FCS

    REPLSTATEDT.FCS is a variable-length data file that contains one record for each Replication Agent that has registered itself with the target server. The records are indexed by the Replication Agent unique ID.

  • REPLSTATEIX.FCS

When the Replication Agent starts, it reads its unique ID from the ctreplagent.cfg configuration file, connects to the target server, creates REPLSTATEDT.FCS if it does not exist, and then reads its Replication Agent state record.

The Replication Agent opens the file ctreplagent_<agentid>.ini if it exists and reads the saved replication state (log read position and last commit log position). The state from ctreplagent_<agentid>.ini is used if that file exists; otherwise, the state from the Replication Agent state record is used. If neither exists, the Replication Agent commences its scan from log 1 position 0.

Note

If log 1 no longer exists — for example, if the transaction files were not removed along with the removal of the REPLAGENT.FCS file), then error 96 (LOPN_ERR, Log file/Start file open error) is possible. In this case, existing transaction logs will need to be removed, or a ctreplagent_<agentid>.ini file needs to be created with correct log and position information.

When committing a transaction on the target server, the Replication Agent writes its current state to the replication state record before it commits the transaction.

Note

The Replication Agent reads its replication state record when it connects to the target server, and the Replication Agent keeps that record locked until it disconnects from the target server.

Delete replication state information

When using the FairCom DB replication feature, you might want to completely turn off replication, or remove the existing replication definitions and create completely new replication definitions.  If you are using a replication agent that is embedded in a server, you can typically use an administrative tool to drop the replication plan, which removes the replication state from the systems. But if that is not an option, or the drop plan fails or cannot be done because a server is offline, some replication state information might be left behind.  Use Delete all replication state information from the primary server: and Delete all replication state information from the secondary server: to manually clear all the replication state information from the database server systems.

Primary server

Delete all replication state information from the primary server:

  1. Delete the REPLSYNCDT1.FCS, REPLSYNCIX1.FCS, REPLSYNCDT2.FCS, and REPLSYNCIX2.FCS files.

  2. If ctstat -var on the primary server shows that the log ship thread has a minimum log requirement, use the following command to remove the log ship thread's minimum log requirement from the primary server.

    ctrepd 0 1 -setlog:0 -unqid:LOGSHIP_NAME -s PRIMARY_SERVER_NAME

    Note

    LOGSHIP_NAME, in this example, is the log ship thread's unique id (LOGSHIP_0.0.0.1).

  3. Delete the directory replmanager_local_replplan (this contains state information that was read from the Memphis database).

Secondary server

Delete all replication state information from the secondary server:

  1. Delete REPLSTATEDT.FCS and REPLSTATEIX.FCS files from the secondary server.

  2. Delete the REPLSTATEIX_<agentid>.FCS index.

  3. Delete the LOGSHIP_NAME_logs directory.

  4. Delete the directory replmanager_local_replplan (this contains state information that was read from the Memphis database).