db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-2921) Replication: Add a network service that connects the master and slave Derby instances
Date Mon, 20 Aug 2007 10:15:31 GMT

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

Øystein Grøvlen commented on DERBY-2921:
----------------------------------------

Rick Hillegas (JIRA) wrote:
> Øystein> 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'm not following you. How would you handle the problem described in
> my comment on August 8: The master hard-uprades and the
> transactional work done as part of hard upgrade is replayed into the
> down-rev slave database. Now the slave database thinks that it is at
> a higher rev than the actual Derby code on the slave machine. What
> will happen if you have to failover to this inconsistent slave?

I agree that hard upgrade is a challenge.  However, we need to
distinguish between software version and database version here.  The
requirement will be that the database is not upgraded to a version
that is higher than the software versions of any of the two Derby
instances hosting the master and the slave.  The master and the slave
does not have to have the exact same version number.  This also means
that it will be possible to do an on-line upgrade of the software by
restarting the nodes one at a time.

It does not seem to me that it will be possible to upgrade the version
of the database on-line.  In order to upgrade, one will have to shut
down and restart the master.  During this process one can not do
fail-over to the slave since the old master will have to remain master
when it is booted in order to do the hard upgrade operation.  This
will create a (small) window of unavailability while the hard upgrade
is performed.

What I suggest is that the version of the replication protocol is
decided by the database version.  That is, before hard upgrade is
done, new software will still use the old protocol.  This means that
if a Derby instance is master for two databases, it may use different
different protocol versions to talk to the slaves, depending on the
version of the database.  This way, I do not think we need to be
concerned about ReplicationClosure.


> 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