[
https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568577#action_12568577
]
Jørgen Løland commented on DERBY-2872:
--------------------------------------
Code freeze for 10.4 is getting closer by the minute. It would be good to
evaluate the funcspec at this point and be explicit about which replication
features will make it into this release and which will be delayed for the next.
As I see it, the following will have to be delayed until 10.5:
* CLI for NetworkServerControl (this has already been mentioned in the funcspec)
* Depending on ETA of DERBY-2109, the system privilege for replication may or
may not make it into 10.4
* Copy the database from the master to the slave inside Derby by using the
master-slave network connection. Instead, a file system copy of the database to
the slave location will be required before replication can be started. This has
the implication that startup of replication requires these steps:
1) boot database 'x' on master
2) freeze 'x' (force log and data to disk and block write operations)
3) copy 'x' to slave location using file system copy
4) connect to 'x' with startSlave option on Derby serving slave
5) connect to 'x' with startMaster option on Derby serving master (includes
unfreeze of 'x')
...as opposed to only doing the originally intended steps 4 and 5. FWIW,
startup of replication in MySQL requires a similar file system copy of the
database.
Of course, both these issues can be addressed in 10.4 if someone volunteers to
work on them.
I will update the funcspec with this information in a few days unless I hear
objections.
> Add Replication functionality to Derby
> --------------------------------------
>
> Key: DERBY-2872
> URL: https://issues.apache.org/jira/browse/DERBY-2872
> Project: Derby
> Issue Type: New Feature
> Components: Replication
> Affects Versions: 10.4.0.0
> Reporter: Jørgen Løland
> Assignee: Jørgen Løland
> Attachments: master_classes_1.pdf, poc_master_v2.diff,
> poc_master_v2.stat, poc_master_v2b.diff, poc_slave_v2.diff,
> poc_slave_v2.stat, poc_slave_v2b.diff, poc_slave_v2c.diff,
> proof-of-concept_v2b-howto.txt, proof_of_concept_master.diff,
> proof_of_concept_master.stat, proof_of_concept_slave.diff,
> proof_of_concept_slave.stat, replication_funcspec.html,
> replication_funcspec_v2.html, replication_funcspec_v3.html,
> replication_funcspec_v4.html, replication_funcspec_v5.html,
> replication_funcspec_v6.html, replication_funcspec_v7.html,
> replication_funcspec_v8.html, replication_script.txt, slave_classes_1.pdf
>
>
> 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/[EMAIL
> PROTECTED]
> 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.
