Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <11838727.1184065684922.JavaMail.jira@brutus>
Date: Tue, 10 Jul 2007 04:08:04 -0700 (PDT)
From: =?utf-8?Q?J=C3=B8rgen_L=C3=B8land_=28JIRA=29?= <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2872) Add Replication functionality to
 Derby
In-Reply-To: <16039538.1182851726399.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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

J=C3=B8rgen L=C3=B8land commented on DERBY-2872:
--------------------------------------

>I'm going to be giving a lightning talk at OSCON on the state of Derby and=
 I want to know what if anything I can say about this feature. It sounds as=
 though some increment of functionality will be delivered in the 10.4 timef=
rame. Will this functionality be complete enough that someone can use it? I=
f so, can you characterize the kind of application that will benefit from t=
he 10.4 increment?

The intention is definitely to have working replication functionality in 10=
.4. Exactly what will be implemented and how depends heavily on what the co=
mmunity wants, so the guesses below may have to be changed. Also, if more p=
eople want to contribute to this task, more functionality will make it into=
 10.4 :-)

I think it is very likely that in 10.4, replication will work. Some manual =
steps will probably be required, e.g. to start the fail-over logic. The rep=
lication functionality will be usable by all applications that want higher =
availability than a single (point of failure) server can provide. However, =
having to manually start fail-over may be unacceptable (take too much time)=
 for applications with the highest availability requirements. Furthermore, =
the application should not contain super-secret data since security issues =
are likely to not make it into this release. But again, the priorities may =
change as community discussions progress.

> 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=C3=B8rgen L=C3=B8land
>            Assignee: J=C3=B8rgen L=C3=B8land
>         Attachments: proof_of_concept_master.diff, proof_of_concept_maste=
r.stat, proof_of_concept_slave.diff, proof_of_concept_slave.stat, replicati=
on_funcspec.html, replication_funcspec_v2.html, replication_funcspec_v3.htm=
l, replication_script.txt
>
>
> It would be nice to have replication functionality to Derby; many potenti=
al Derby users seem to want this. The attached functional specification lis=
ts some initial thoughts for how this feature may work.
> Dag Wanvik had a look at this functionality some months ago. He wrote a p=
roof of concept patch that enables replication by copying (using file syste=
m copy) and redoing the existing Derby transaction log to the slave (unfort=
unately, 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 threa=
ds, including these:
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/%3c426=
E04C1.1070904@yahoo.de%3e
> http://www.nabble.com/Does-Derby-support-Transaction-Logging---t2626667.h=
tml

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.