[
https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539429
]
Daniel John Debrunner commented on DERBY-2872:
----------------------------------------------
The startslave command's syntax does not include a -slavehost option, but the
comments seem to indicate one is available.
Do stopslave and startfailover need options to define the slavehost and port,
otherwise how do they communicate with the slave?
How do startmaster and stopmaster connect to the master database?
It's unclear exactly what the startmaster and stopmaster do, especially wrt to
the state of the database. Can a database be booted and active when startmaster
is called, or does startmaster boot the database? Similar for stopmaster, does
it shutdown the database?
Is there any reason to put these replications commands on the class/command
used to control the network server? They don't fit naturally there, why not a
replication specific class/command? From the functional spec I can't see any
requirement that the master or slave are running the network server, so I
assume I can have replication working with embedded only systems.
How big is this main-memory log buffer, can it be configured?
extract - "the response time of transactions may increase for as long as log
shipment has trouble keeping up with the amount of generated log records."
Could you explain this more, I don't see the connection between the log buffer
filling up and response times of other transactions. The spec says the
replication is asynchronous, so won't user transactions still be only limited
by the speed at which the transaction log is written to disk?
The spec seems to imply that the slave can connect with the master, but the
startmaster command doesn't specify its own hostname or portnumber so how is
this connection made?
Why if the master loses its connection to the slave will the replication stop,
while if the slave loses its connection to the master it keeps retrying? It
seems that any temporary glitch in the network connectivity has a huge chance
of rendering the replication useless. I can't see the logic behind this, what's
stopping the master from keeping retrying. The log buffer being full shouldn't
matter should it, the log records are still on disk, or is it that this scheme
never reads the transaction log from disk, only from memory as log records are
created?
>From reading between the lines, I think this scheme requires that the master
>database stay booted while replicating, if so I think that's a key piece of
>information that should be clearly stated in the functional spec. If not, then
>I think that the how to shutdown a master database and restart
>replication(without the initial copy) should be documented.
> Add Replication functionality to Derby
> --------------------------------------
>
> Key: DERBY-2872
> URL: https://issues.apache.org/jira/browse/DERBY-2872
> Project: Derby
> Issue Type: New Feature
> Components: Miscellaneous
> 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_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.
