Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1073797.1186614661319.JavaMail.jira@brutus>
Date: Wed, 8 Aug 2007 16:11:01 -0700 (PDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2921) Replication: Add a network service
 that connects the master and slave Derby instances
In-Reply-To: <5170718.1184151365366.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-2921?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518573 ]=20

Rick Hillegas commented on DERBY-2921:
--------------------------------------

Thanks for looking into this issue, Narayanan. Some more discussion follows=
.

The machine issue has to do with the machine that compiles the Derby releas=
e, not the machine which runs Derby in production. The serialVersionUUID ca=
n change from release to release even if there are no changes to replicatio=
n. This depends on who steps up to be release manager and what environment =
they use to build the release. Of course, hard-coding the serialVersionUUID=
 patches around this problem.

However, hard-coding the serialVersionUUID will not solve the larger issue =
of how replication will behave in a mixed-release environment. Between rele=
ases, we may need to make changes to the structure of the ReplicationMessag=
e or the log record. In my experience, version upgrade needs to be designed=
 into the first release of a feature. It is generally a disaster when you t=
ry to retrofit upgrade into version 2 of a product.

But there are much larger issues here than serialization. For the sake of f=
raming this issue, I introduce the following definition:

ReplicationClosure -- This is the  set of all Derby instances which are lin=
ked by replication. You compute the ReplicationClosure by starting with one=
 of the systems, then add all systems that it replicates to and from. Then =
you repeat for each of those added systems, etc..

1) Are we requiring that all Derby instances in a ReplicationClosure be at =
the same rev level?

2) If not, what happens when one system in the ReplicationClosure is upgrad=
ed to a new rev of Derby independently of the others?

3) On the other hand, if the answer to (1) is "yes", then what is our plan =
for propagating Derby (and application) upgrades across the ReplicationClos=
ure?

Consider the following problem: A 10.5 master replicates to a 10.5 slave. L=
ater on, the 10.5 master is hard-upgraded to 10.6. Quite likely, hard-upgra=
de will do transactional work which must be replayed at the slave. But now,=
 what is the state of the slave? It has a 10.5 version of Derby on its clas=
spath, but the actual tables think they are at rev level 10.6. Fail-over is=
 not going to work well.

I suspect that where you want to end up is that all systems in the Replicat=
ionClosure must be at the same Derby rev level. You need to have some plan =
for propagating new Derby releases across the ReplicationClosure. Maybe the=
 answer is this: Replication fails if the master and slave are at different=
 Derby rev levels and it is the System Administrator's responsibility to up=
grade all Derby installations in the ReplicationClosure at the same time. T=
he functional spec needs to spell out what the behavior is. Then I can reas=
on about whether this patch fits into the spec'd model.

Thanks.


> Replication: Add a network service that connects the master and slave Der=
by instances
> -------------------------------------------------------------------------=
------------
>
>                 Key: DERBY-2921
>                 URL: https://issues.apache.org/jira/browse/DERBY-2921
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Services
>    Affects Versions: 10.4.0.0
>            Reporter: J=C3=B8rgen L=C3=B8land
>            Assignee: V.Narayanan
>         Attachments: Replication_Network_v1.diff, Replication_Network_v1.=
stat
>
>
> A network connection is required between the master and slave Derby insta=
nces of a replicated database. The connection will be used to send many kin=
ds of messages, including:
> * log records
> * the database (when replication is started)
> * master -> slave commands (like "stop replication")

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