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-2921) Replication: Add a network service that connects the master and slave Derby instances
Date Wed, 08 Aug 2007 23:11:01 GMT

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

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 release, not the machine
which runs Derby in production. The serialVersionUUID can change from release to release even
if there are no changes to replication. 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 releases, we may need to make changes
to the structure of the ReplicationMessage 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 try to retrofit upgrade into version 2 of a product.

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

ReplicationClosure -- This is the  set of all Derby instances which are linked 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 upgraded 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 ReplicationClosure?

Consider the following problem: A 10.5 master replicates to a 10.5 slave. Later on, the 10.5
master is hard-upgraded to 10.6. Quite likely, hard-upgrade 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 classpath, 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 ReplicationClosure 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 upgrade all Derby installations in the ReplicationClosure at the same time. The functional
spec needs to spell out what the behavior is. Then I can reason about whether this patch fits
into the spec'd model.

Thanks.



> Replication: Add a network service that connects the master and slave Derby 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ørgen Løland
>            Assignee: V.Narayanan
>         Attachments: Replication_Network_v1.diff, Replication_Network_v1.stat
>
>
> A network connection is required between the master and slave Derby instances of a replicated
database. The connection will be used to send many kinds of messages, including:
> * log records
> * the database (when replication is started)
> * master -> slave commands (like "stop replication")

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