db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri van de Scheur (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2872) Add Replication functionality to Derby
Date Fri, 22 Feb 2008 09:44:19 GMT

    [ 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/%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.


Mime
View raw message