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