[
https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571021#action_12571021
]
Henri van de Scheur commented on DERBY-2872:
--------------------------------------------
I have a few comments/questions to the Functional Specification for Derby
Replication - rev. 9.0.
Great to see a chapter 'Handling Failure Scenarios', but as stated here, there
are numerous failure scenarios which can be encountered. As a follow-up, I
would like to raise the following questions/comments:
1. Would be nice to also describe a scenario where the slave Derby instance
crashes
2. Please confirm the following statement: 'Since the slave database is in
recovery-mode, no data in the slave database can be changed at all by any
means'. If this wouldn't be the case, a lot of consistency-problems and
scenarios should be taken into account.
3. Is the relation Master-Slave really an N:M-relation and if so, are N and/or
M somehow limited?
4. Master has still connection with Slave, but for some reason the Slave does
not process the received logrecords: will this be seen as 'unexpected failure'?
5. Network issue: what to do in case of missing packages?
6. Network issue: will a multipath-configuration be supported? This will lead
to a Slave receiving records in a wrong sequence
7. Network issue: multiple-network-interfaces: question as for 6). In addition:
special scenario(s) if one such interface is dropped?
8. If 1 Master replicates to 2 different Slaves and one of these Slaves has a
lower 'bandwidth' to receive/process the logs, will this one then determine the
total (replication)transactional processes, thus also limit sending to the
other Slave?
9. If Derby instance I1 contains database D1 as Master, database D2 as Slave,
instance I2 contains the same but with opposite roles: isn't there a big risk
for a 'dead' race in case of problems with main memory log buffer?
Thanks!
> 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.
