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 Mon, 12 Nov 2007 14:48:50 GMT

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

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

While working on DERBY-3189, I realized that the functional specification is not 100% clear
when it comes to security measures for replication.

I plan to update the funcspec with the following information in a few days unless there are
comments:

Master side:
* Authentication is turned on: Normal Derby connection policy - the user and password must
be valid.
* Authorization is turned on: The user must be valid and be the database owner of the database
that will be replicated.
* System privileges (DERBY-2109) is turned on: The user must be valid and have the "replication"
system privilege.

Slave side - start slave:
As for master, but with the two-phase strategy used for encryption of databases. This means
first booting the slave database for authentication and authorization, shut the slave database
down and reboot it in slave mode.

Slave side - stop slave and failover: 
Cannot get the authentication service from the slave database since it is not fully booted
yet. Can authenticate users on system level only. Authorization cannot be checked. If system
privileges is turned on, the user must have the "replication" system privilege. 

Since we are not able to check authorization while in slave mode, stop slave and failover
commands will only be accepted from the master while the master-slave connection is working.
If the slave-master connection is down, any authenticated/properly system-privileged user
can issue the commands on the Derby serving the slave 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: 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_funcspec_v7.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/%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