Replication Agent - Improved calculation and persistence of replication reader transaction log requirements
Additional improvements were made to calculation and persistence of Replication Agent transaction log:
The Replication Agent's call to set the checkpoint position in its log tran list failed with a KDUP_ERR (meaning that an entry for that log already existed, which is not expected). This possibility has been corrected.
In some cases the Replication Agent did not know to inform the source server of logs that it needed to keep. For example, when the log scan started before the first checkpoint in a log and there was an active transaction that existed entirely in that log, the Replication Agent thought there was no need to keep previous logs (because there were no pending transactions for previous logs).
The source server deleted logs required by replication readers after automatic recovery. The following problems were corrected:
The calculation of which logs to keep when the source server started had the sense of the log number comparison reversed so logs needed by replication would not be kept even though the replication minimum log number state variable was set to the correct value.
If the server was terminated and restarted after automatic recovery with no additional checkpoint activity in the logs, the old log number was not preserved, causing transaction logs to be orphaned (a cosmetic issue) and causing the replication log requirement check to be skipped.
When c-treeACE Server keeps more than the minimum number of logs (4) at startup due to replication requirements, the count of active logs was incorrect.
When a Replication Agent sets its log position it temporarily sets its required log to -1 and if the setting of the position fails, it sets its required log to zero. The original log requirement is now maintained when setting the log position. If the setting of the log position is successful, the new minimum log number is set; otherwise the original log number is maintained.
When a replication reader registers its log requirement, we now write a checkpoint to the transaction logs so that the log requirement is immediately made persistent.
When more than one Replication Agent was starting its scan at the same time, some of them failed to open the previous log with error 96. This happened because we used an exclusive mode to open the previous log.
Two options were added to the ctrepd utility:
-nominlog disables log persistence on the source server. If this option is used, the source server determines the current log requirement based on which log is being read by the utility. When the option is not used (the default), ctrepd receives REPL_CHKPNT entries, and so this option is useful for seeing those entries.
-unqid:<id> specifies the replication unique ID to use when using the -minlog option. This is useful if you are running more than one ctrepd utility on the same source server at the same time.
We added the command getlogtail to the repadm utility. This option displays replication agent exception log entries starting with the last record in the exception log when repadm is started.
NOTE: The replication agent now stores its current minimum required log in the REPLSTATEDT.FCS record on the target server. This required adding data to the end of the variable-length record. The replication agent automatically converts an existing REPLSTATEDT.FCS file to the new format (adding a new DODA) when it starts.
