db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-2872) Add Replication functionality to Derby
Date Tue, 03 Jul 2007 08:22:04 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509788

Jørgen Løland commented on DERBY-2872:

Thanks for your comments, Rick. I will attach a new func spec in a few days. 

> 1) How does the customer turn replication on and off? For instance, is this done by calling
a system procedure?

The slave is kept in recovery mode until it becomes a master (see answer to 3 and 4). This
means that calling connect on the slave will never return a connection, and stored procedures
can therefore not be used on the slave.

The user interaction required to start a master and a slave should be as similar as possible.
Adding a few commands to NetworkServerControl seems like a viable solution:

* The command used to start the slave role for 'x' should make Derby listen on a specified
port for a connection with the master of 'x'.

* The command used to start the master role for 'x' should make Derby connect to a URL, and
start replication of DB 'x' once a connection is established.

Similar commands to stop replication, make slave become master etc are also needed.

> 2) Who has permission to turn replication on and off? E.g., the database owner?

I think DB owner sounds reasonable.

> 3) After failover, when the slave is promoted to be the new master, presumably the customer
will want replication to resume. What is the customer experience here? Does replication automatically
begin to some default database? Alternatively, is a notification sent to some registered listener
who can then restart replication?
> 4) Similarly, what's the customer experience when the slave fails? Does replication begin
from the master to a new default database? Is a notification sent to a listener who can then
restart replication?

Basically, the two derby instances forming a replication pair can be in the following states:

m1: connect (including create DB)
m2: run in normal Derby mode
m3: become master (set up nw communication, ship DB to slave)
m4: run in master mode, which is similar to m2 for normal users
m5a: slave fails? go to m2
m5b: master (this Derby instance) fails? done

s1: start (listen on a port for connections, receive a DB over nw)
s2: slave is kept in recovery mode, which lets us forward recover received log records for
"free". Receives log records from master and performs forward recovery on these
s3a: master fails? complete the booting and go to m2
s3a: slave (this Derby instance) fails? done

Hence, the behavior is the same regardless of whether the "old slave" or "old master" is the
instance that is still alive when one of the instances failed. In both cases, new replication
must be started manually on the surviving Derby instance. So far, I have not considered restarting
replication automatically after an instance has failed.

(Note that the presented states are not accurate enough to describe everything that happens.
For example, if the connection between the master and slave fails temporarily when the pair
is in state m4/s2, the pair will try to reconnect for some time.)

> 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
>         Attachments: proof_of_concept_master.diff, proof_of_concept_master.stat, proof_of_concept_slave.diff,
proof_of_concept_slave.stat, replication_funcspec.html, replication_script.txt
> 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