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