db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2872) Add Replication functionality to Derby
Date Fri, 06 Jul 2007 16:19:04 GMT

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

Rick Hillegas commented on DERBY-2872:
--------------------------------------

Thanks for rev 2 of the spec, Jørgen.

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. 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 have some more comments:

5) 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.

6) I think it would be clearer if the url option were called slaveurl. 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? What  happens if two masters try to replicate to the same
slave?

7) 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?

8) I am confused about the startslave command. Does this create a new database? If so, how
are the credentials enforced in the case that credentials are stored in the database? If not,
what happens if there is already a database by that name? Is the database destroyed and replaced
after authentication?

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

10)  What is the sequence of these commands? Do you first issue a startmaster and then issue
a startslave? What happens if the commands occur out of sequence? Similarly for 

11) 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.

12) 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?

13) What happens if the slave is shut down and then, later on, someone tries to boot the slave
as an embedded database?

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


Mime
View raw message