[
https://issues.apache.org/jira/browse/DERBY-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520574
]
Øystein Grøvlen commented on DERBY-2921:
----------------------------------------
If I understand correctly, hard-coding the SerialVersionUUID, will mean that
when one later change the serialization form, one will have to manually update
the SerialVersionUUID. Would not that imply that as long as the format of the
message does not change, running different versions of the master and the slave
will work?
I think the suggested approach is good. It is not necessary to support
protocol upgrades before an on-line upgrade is actually required. At that
time, the upgrade will need to happen in two steps. First, the software is
upgraded and then when all nodes are running the new version, the protocol can
be upgraded. (Maybe the first step could be part of soft upgrade, and the
second hard upgrade.)
Since it is log records that are replicated, I would think that one will also
have to deal with the version level of log records and data.
> 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.
