Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
10.6.1.0
-
None
-
None
Description
Starting Derby replication is brittle; you need to perform multiple steps in exact order. Furthermore, the steps involves freezing the database on the master Derby instance the time it takes to copy the database to the slave node.
A much simpler way to start replication would be:
1) Make an online backup of the database on the master Derby instance. Enable log archiving.
2) Copy the backup to the slave node while the master Derby instance continues to handle transactions
3) Boot the slave database in slave mode.
4) Master sends all log written since the backup was made, or from a specified log instant (a number that can be specified as an option to either the startSlave or startMaster command?).
The main implementation effort is in step 4, because this step requires the master derby instance to read and send log records that are on disk. This differs from the current replication code that captures log records on the master as they are about to be written to disk (i.e., replication does not read files).
Since the master instance is supposed to continue transaction processing, it will write to the latest log file while the replication thread will have to read log files (including the currently open one). The Derby code that reads log files is written to handle a single thread (the recovery thread) only in the current implementation.