Yes, it should be possible to try. We have not yet quite decided which way to go, think operations won't be happy with upgrading both server and client at the same time.
Either we upgrade to 0.7.0 (currently does not look very likely), or we go to 0.6.9 and patch with TTL. I'm not too sure what a possible future upgrade would look like if we use the TTL patch, though. /Daniel 2011/1/21 Aaron Morton <aa...@thelastpickle.com> > Yup, you can use diff ports and you can give them different cluster names > and different seed lists. > > After you upgrade the second cluster partition the data should repair > across, either via RR or the HHs that were stored while the first partition > was down. Easiest thing would be to run node tool repair. Then a clean up to > remove any leftover data. > > AFAIK file formats are compatible. But drain the nodes before upgrading to > clear the log. > > Can you test this on a non production system? > > Aaron > (we really need to write some upgrade docs:)) > > On 21/01/2011, at 10:42 PM, Dave Gardner <dave.gard...@imagini.net> 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> > 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>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> >>> 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 >>> >>> >> >
