Replication relies on the transaction log files and when replication needs troubleshooting it is important to understand how these components work together.
A transaction log is written to the disk when new transactions are executed in the server. Transaction logs are sequentially written to the log files in this format:
-rw------- 1 soluser cc 45449216 Mar 9 11:49 sol00001.log
-rw------- 1 soluser cc 14991360 Mar 9 11:50 sol00002.log
-rw------- 1 soluser cc 13713408 Mar 9 11:50 sol00003.log
-rw------- 1 soluser cc 13172736 Mar 9 11:51 sol00004.log
When the transaction log file size reaches a certain limit (specified by Logging.MinSplitSize parameter), in the next checkpoint the server creates a new file and continues writing to the new file. A message is shown in the solmsg.out file in this format:
2023-03-09 11:49:46.385 Log file rotated to 'sol00002.log'
2023-03-09 11:50:19.664 Log file rotated to 'sol00003.log'
2023-03-09 11:50:50.339 Log file rotated to 'sol00004.log'
When the total size of all the log files reaches the limit specified by Logreader.MaxLogSize, the server starts to remove the oldest log files to keep the total size around the specified maximum size. A message is shown in the solmsg.out file in this format:
Removing old log files implies some older transactions are not available for replication any longer. A message that transactions below a certain number are not available for replication is shown in the solmsg.out in this format:
2023-03-09 12:48:28.512 Log catchup oldest position moved to 15650333 for running over maxsize
When a replication START command is executed on the target server it connects to the source server, and tries to catchup transactions executed on the source after replication was stopped from a certain position in the log. If this position is still available in the log, catchup is possible. If it is not, replication falls back to reload.
When replication starts, a message is shown on the source side: