db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland (JIRA) <j...@apache.org>
Subject [jira] Updated: (DERBY-4197) Simplify initialization of replication
Date Wed, 29 Apr 2009 12:31:31 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jørgen Løland updated DERBY-4197:
---------------------------------

    Summary: Simplify initialization of replication  (was: Simplify initiation of replication)

> Simplify initialization of replication
> --------------------------------------
>
>                 Key: DERBY-4197
>                 URL: https://issues.apache.org/jira/browse/DERBY-4197
>             Project: Derby
>          Issue Type: New Feature
>          Components: Replication
>    Affects Versions: 10.6.0.0
>            Reporter: Jørgen Løland
>            Priority: Minor
>
> 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. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message