db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2872) Add Replication functionality to Derby
Date Thu, 01 Nov 2007 18:19:51 GMT

    [ 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:
>            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
> 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.

View raw message