[
https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555938#action_12555938
]
Jørgen Løland commented on DERBY-2872:
--------------------------------------
Hi Kim,
I'll try to sort out the ambiguities in the func spec:
> 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?
In the first implementation of replication, the master database
must be booted (also implies created) before startMaster is
specified. This may be improved in Derby 10.5.
> 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.
Just to be clear - you can replicate a database that's been
around for a long time.
> 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.)
Looking at Connection URL Attributes in the reference manual, the
replication attributes can be combined with 'user' and 'password'
only. Username and password attributes are required if
authentication/authorization is turned on.
The replication attributes start*, stop* and failover can not be
used at the same time, whereas slavehost/slaveport can be used in
combination with these as specified in the funcspec.
> Is it correct that to start replication, all you need to do is
> specify the startMaster/slavehost/[slaveport] attributes on the
> master database? It appears from the description that this
> command gets things going on both the master and the slave
> without your having to explicitly run startSlave on the slave
> system. It appears that something like this happens when you stop
> the master, so I'm assuming it happens when you start it too.
I can see why you would assume this, but it is not correct. I
will update the funcspec soon to clearify this. The answer: No,
you have to run startSlave on the slave host in addition to
startMaster on the master host.
Regarding lost connection: there are no commands to fix a lost
connection between the master and slave. The replication
functionality will try to reestablish the connection
internally (no user interaction), but may eventually have to give
up. If replication is stopped because of a lost connection (or
any other reason, like issuing a stopMaster command), replication
must be started over again from scratch.
> Another question: at several points the spec says that the
> slave "redoes" the transaction log sent by the master. What does
> that mean exactly? Does it perform the operations that are
> recorded in the transaction log?
Correct - the slave applies the operations found in the log.
Once again, thanks for documenting replication!
> 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.
