[
https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571330#action_12571330
]
Henri van de Scheur commented on DERBY-2872:
--------------------------------------------
Thanks a lot Jørgen for your quick and descriptive replies!
I regard all of my questions answered, apart from the last one, but that was
more due to a bad formulated question. I will try to explain it through an
example.
Especially the fact having '1 Master, 1 Slave', reduces a lot of possible
failure scenarios and makes it a lot easier. I just hadn't interpreted the spec
this way.
Limited network communication to only 1 single socket, also limits possible
failure scenarios.
So to question 9.
Let's say that Instance I1 is not able to send log for database D1 to the slave
in Instance I2 at the required pace. I1 will then try to increase the speed of
log shipment. The latter might lead to reduced capacity in receiving log from
Instance I2 and database D2. This then might lead to increasing speed of log
shipment from instance I2, again leading to the same symptom: reduced capacity
of receiving log shipments from Instance I1, etc.....
I hope this example makes my point more clear. But I guess response times will
increase avoiding this situation.
> 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_funcspec_v9.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.
