I didn't quite follow all of this, and admit i am not up on replication. It would be nice if this process was the exact code as the normal checkpoint processing. So a checkpoint would be triggered and then after it had done it's work it would do the appropriate cleanup. If you do the cleanup too soon then redo recovery of the slave won't work - is that expected to work or at that point to you just restart from scratch from master.
The existing code that replay's multiple checkpoints may be wierd as it may assume that this is recovery of a backed up database that is meant to keep all of it's log files. Make sure to not break that. Is there a concept of a "fully" recoverable slave, ie. one that is supposed to keep all of it's log files so that it is recoverable in case of a data crash. As I said may not be necessary as there is always the master. Just good to know what is expected. Jørgen Løland (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland reassigned DERBY-3562: ------------------------------------ Assignee: Jørgen LølandNumber of log files (and log dir size) on the slave increases continuously -------------------------------------------------------------------------- Key: DERBY-3562 URL: https://issues.apache.org/jira/browse/DERBY-3562 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.4.0.0, 10.5.0.0 Environment: - Reporter: Ole Solberg Assignee: Jørgen Løland Attachments: master_slave-db_size-6.jpg I did a simple test inserting tuples in a table during replication:The attached file 'master_slave-db_size-6.jpg' shows that the size of the log directory (and number of files in the log directory) increases continuously during replication, while on master the size (and number of files) never exceeds ~12Mb (12 files?) in this scenario. The seg0 directory on the slave stays at the same size as the master seg0 directory.
