Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <15384139.1185180511294.JavaMail.jira@brutus>
Date: Mon, 23 Jul 2007 01:48:31 -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_12514590 ]=20

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

>2. I guess you will add a connection attribute that is used to get the
>   a database booted in "slave mode". I think this should be
>   specified in the functional spec. Even if people will normally not
>   use that directly, it will be part of the public API, and I think
>   it should be specified in a funcspec.=20

Something like this?=20

ij> connect 'jdbc:derby:db;replicationslave;...';

If so, I do not think we should add this connection attribute. The reason i=
s that the replication idea is to prevent the slave from completing the dat=
abase booting; it is supposed to stay in recovery and redo log records as t=
hey arrive until stop or failover is requested. Since the slave gets stuck =
in recovery, the statement above would never return a connection - it would=
 just hang. As far as I know, this also means that the connection can not b=
e used to stop replication or perform failover either.

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