You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Jørgen Løland (JIRA)" <ji...@apache.org> on 2007/07/02 11:21:04 UTC

[jira] Updated: (DERBY-2872) Add Replication functionality to Derby

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

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

    Attachment: proof_of_concept_master.stat
                proof_of_concept_master.diff

A proof of concept patch is attached. It demonstrates that shipping derby log records from the master to the slave and redoing them at the slave, as described in the functional specification, works.

The patch modifies classes in the LogFactory service in rawstore so that the derby log records are sent from the master to the slave and written to the log file on the slave. When the slave is rebooted, the operations that were performed on the master are reflected at the slave as well.

I have tried a few combinations of insert/update/delete/create table operations with only one transaction at a time on the master. The test cases have run successfull, meaning that the slave state has been equal to the master.

The patch has many shortcomings that need to be addressed. Some important ones are 

* the slave has to be rebooted before the shipped log is applied
* initially, the master database has to be copied to the slave location using file system copy
* replication is started for all databases controlled by the derby instances in question 
* log shipping is done in a blocking way, one log record at a time
* RMI is used to ship the log records

Attachements:
proof_of_concept_master* - patch for the Derby that will have the master role. ant all fails (toursdb); workaround: use ant engine instead
proof_of_concept_slave* - patch for the Derby that will have the slave role
replication_script.txt - a few insert/update/delete/create scenarios that have successfully demonstrated the concept.

> Add Replication functionality to Derby
> --------------------------------------
>
>                 Key: DERBY-2872
>                 URL: https://issues.apache.org/jira/browse/DERBY-2872
>             Project: Derby
>          Issue Type: New Feature
>          Components: Miscellaneous
>    Affects Versions: 10.4.0.0
>            Reporter: Jørgen Løland
>         Attachments: proof_of_concept_master.diff, proof_of_concept_master.stat, proof_of_concept_slave.diff, proof_of_concept_slave.stat, replication_funcspec.html, replication_script.txt
>
>
> It would be nice to have replication functionality to Derby; many potential Derby users seem to want this. The attached functional specification lists some initial thoughts for how this feature may work.
> Dag Wanvik had a look at this functionality some months ago. He wrote a proof of concept patch that enables replication by copying (using file system copy) and redoing the existing Derby transaction log to the slave (unfortunately, I can not find the mail thread now).
> DERBY-2852 contains a patch that enables replication by sending dedicated logical log records to the slave through a network connection and redoing these.
> Replication has been requested and discussed previously in multiple threads, including these:
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/%3c426E04C1.1070904@yahoo.de%3e
> http://www.nabble.com/Does-Derby-support-Transaction-Logging---t2626667.html

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