db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2872) Add Replication functionality to Derby
Date Mon, 09 Jul 2007 09:10:05 GMT

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

V.Narayanan commented on DERBY-2872:

>Looks like you have addressed issue (1). I see in your comments above, 
>that you are in agreement about how to address issue (2), but I don't 
>see this reflected in the new spec itself

Under the section Interacting with the replication feature the spec says 
how to Start Master, Start Slave, failover and stop replication.

Below the table is mentioned the following

"These commands apply only to the database specified, and 
only the database owner will be allowed to execute them."

>I'm getting the impression that the answer to (3) and (4) is that the 
>first rev of replication won't handle these issues; instead, they will 
>be addressed in a later rev. Is that right? 

I found some answers from Jorgen's comment

"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."

I interpret it that a manual startup is planned for now. Is a auto startup on the cards?

>A heads-up about the user/password options on the new server commands. There has been

>some discussion about authenticating server shutdown operations and general agreement

>that the current situation is confusing. DERBY-2109 intends to add credentials to the

>server shutdown command. I think that the same api should be used to specify username

>and password for all of our server commands--whatever that api turns out to be.

Thank you for this pointer. I guess taking the same lines as 2109 is the thing to do here.

>Do we need a symmetric masterurl option for the startslave command?
>How does the slave know that it is receiving records from the correct master? 

The slave basically starts a server to receive records from the master
and the master connects to it to send the records. Even if we were to use the
url to ensure that the slave is receiving records from the correct master
there could be two senders on the same machine url. Guess we wouldn't need
the slaveurl.

But we need to do  

java org.apache.derby.drda.NetworkServerControl replication -startslave 
-db=<dbname> -port=<port> -user=<name> -pass=<pass>

for each database that want replicated. So we could as well mention the master
url also. But I am not sure how we would use this.

>What happens if two masters try to replicate to the same slave?

I guess you mean what happens if they try to connect using the same

This would be an issue I guess because the slave would assume
both to be legitimate unless we send the database name each time. 

But what would happen if both use the same database also.

Can this be eliminated by having a handshake phase before the actual
log transfer occurs. So if the same url is being used for a second handshake
we would reject this unless this is a reconnect attempt after the master has

>Is the startmaster command restricted to a server running on the same 
>machine as the master database? Similarly, is the startslave command restricted to a 
>server on the slave database machine? What about failover and stop?

I think issuing the startslave on a machine would just mean that
the server is started on the machine that the NetworkServerControl class
since we would depend on this to start the agent Jorgen has mentioned in
his comments. I guess the same applies to the other commands. I concluded this
also because in the proof of concept code attached the RMI code that tranafers the
log records is called from inside FileLoggerPrimary which writes into the log on
the disk as well as through the network. Wouldn't this class take care of the
case when the server is not running on the same machine as the slave database for

>If you have stopped replication, can you resume it later on?

If stopping replication means that we will not archive logs anymore
I guess this will not be possible. If the logs are still archived we
can transmit from the log after replication has been stopped and the slave
can still redo from there and replication from continue. That is we should
not call SYSCS_UTIL.SYSCS_DISABLE_LOG_ARCHIVE_MODE system procedure after
stopping replication. Guess the user should be able to decide this.

Does this mean that the stopping API has to be modified?

>What is the sequence of these commands? Do you first issue a startmaster and then issue
a startslave? 

Since the startslave starts a listener this should be done first before

>What happens if the commands occur out of sequence?

Since we mention the slaveurl to the startmaster command this will fail
saying that the slave was not found at the url mentioned.

>It would be nice to understand how we insulate replication from man-in-the-middle attacks--
>even if we don't implement these protections in this first version. 

I guess you want the interfaces to be designed in such a way that will enable
security to be plugged in at a later time. I think this is a very good suggestion.

>What happens if someone tries to connect to an active slave? What happens if someone 
>tries to shutdown an active slave without first stopping replication at the master's end?

A connect attempt from the master would fail and the master would report that the
connection has been terminated due to the slave not being able to be reached or that a
slave could not be found. Would this case be different from trying to connect to a
Derby NetworkServer when it has been shutdown?

>What happens if the slave is shut down and then, later on, someone tries to boot the slave

>as an embedded database? 

Should this be similar to creating a database using the NetworkServer shutting it down
and later trying to connect to it in the embedded mode?

> 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: 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_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