[
https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555632#action_12555632
]
Kim Haase commented on DERBY-2872:
----------------------------------
I have a question about the startMaster attribute. Can it can be used *when* a
database is created (that is, in conjunction with the create=true attribute),
or must it be used *after* the database has been created?
The spec (v8) is not absolutely clear on this, because it says both
"a master database must be created before it can be replicated."
and
"...replication does not need to be specified when the database is created;
it can be initiated at any time after the database is created."
The first part of the second sentence implies that replication *could* be
started when the database is created -- that is, in conjunction with
create=true. But maybe it means only that you don't have to start it
*immediately* after creating the database -- you can replicate a database
that's been around for a long time.
One of the sections in the reference topics on connection attributes is
"Combining with other attributes", so it would be helpful to have this
information -- and any other information you have on which attribute
combinations are allowed and which are not. For example, I'm sure you can
combine these with the username and password attributes, and I'm sure you can't
specify two of the replication commands at the same time. About others, I'm not
certain.)
> 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.
