Dual writes would require you to have both a 0.6 and 0.7 client in the same
code base unless you have some sort of intermediate file or queue or something.
Since 0.6 and 0.7 use the same names in their thrift files this won't work,
thus my suggestion of adding a second service to the 0.6 and 0.7 thrift
files called Cassandra6 and having the server support 2 versions of thrift.

That would require a bit of work on the cassandra developers and is probably
no where on their radar, so we need other solutions.

-Anthony

On Fri, Jan 21, 2011 at 09:42:28AM +0000, Dave Gardner wrote:
> What about executing writes against both clusters during the changeover?
> Interested in this topic because we're currently thinking about the same
> thing - how to upgrade to 0.7 without any interruption.
> 
> Dave
> 
> On 21 January 2011 09:20, Daniel Josefsson <jid...@gmail.com> wrote:
> 
> > No, what I'm thinking of is having two clusters (0.6 and 0.7) running on
> > different ports so they can't find each other. Or isn't that configurable?
> >
> > Then, when I have the two clusters, I could upgrade all of the clients to
> > run against the new cluster, and finally upgrade the rest of the Cassandra
> > nodes.
> >
> > I don't know how the new cluster would cope with having new data in the old
> > cluster when they are upgraded though.
> >
> > /Daniel
> >
> > 2011/1/20 Aaron Morton <aa...@thelastpickle.com>
> >
> > I'm not sure if your suggesting running a mixed mode cluster there, but
> >> AFAIK the changes to the internode protocol prohibit this. The nodes will
> >> probable see each either via gossip, but the way the messages define their
> >> purpose (their verb handler) has been changed.
> >>
> >> Out of interest which is more painful, stopping the cluster and upgrading
> >> it or upgrading your client code?
> >>
> >> Aaron
> >>
> >> On 21/01/2011, at 12:35 AM, Daniel Josefsson <jid...@gmail.com> wrote:
> >>
> >> In our case our replication factor is more than half the number of nodes
> >> in the cluster.
> >>
> >> Would it be possible to do the following:
> >>
> >>    - Upgrade half of them
> >>    - Change Thrift Port and inter-server port (is this the storage_port?)
> >>    - Start them up
> >>    - Upgrade clients one by one
> >>    - Upgrade the the rest of the servers
> >>
> >> Or might we get some kind of data collision when still writing to the old
> >> cluster as the new storage is being used?
> >>
> >> /Daniel
> >>
> >>
> >

-- 
------------------------------------------------------------------------
Anthony Molinaro                           <antho...@alumni.caltech.edu>

Reply via email to