During normal operations, the OpenEdge Replication agent is performing a continuous roll forward. All database activity performed on the source database is applied to the target database in this manner. The OpenEdge Replication agent receives an AI block from the OpenEdge Replication server and applies the AI transaction log records to the target database. This process continues until the source or target database is shut down.
This continuous roll forward is shown in the following figure.
Figure 10. Continuous roll forward on agent
For the most part, the OpenEdge Replication agent performs no specific action for individual transaction log records other than applying them to the target database, as the figure above shows. However, there are exceptions. The OpenEdge Replication agent does special processing for the following transaction log records:
Checkpoint
AI extent switch
Transaction end
Both a checkpoint and an AI extent switch cause the OpenEdge Replication agent to inform the OpenEdge Replication server that a synchronization point, commonly known as a sync point, has been encountered. A sync point instructs the OpenEdge Replication server that this is the point to begin synchronization during database startup or failure recovery.
When synchronous replication is in effect, any process ending a transaction by either committing or rolling back will block or wait until the transaction end is processed by the OpenEdge Replication agent. After the OpenEdge Replication agent applies the transaction end, it informs the OpenEdge Replication server; and the OpenEdge Replication server unblocks the waiting process.
The sync point and all other information needed for synchronization are stored in a file called db-name.repl.recovery, where db-name is the name of your source or target database. Do not edit this file. You must delete this file whenever you restore the source or target database, or when you re-enable OpenEdge Replication.
In the event of an unexpected OpenEdge Replication agent failure, dynamic transaction backout does not occur and the target database is left in an inconsistent state. This could cause ABL or SQL processes accessing the database to end abnormally. After the target database is restarted and synchronization is performed, all target database access should proceed normally.
Checkpoint