As far as I can tell, it is impossible to run a 0.6 client against a 0.7 server because the method signatures were changed in a non-backwards compatible way. Compare
https://svn.apache.org/viewvc/cassandra/branches/cassandra-0.6/interface/cassandra.thrift?revision=964293&view=markup to https://svn.apache.org/viewvc/cassandra/branches/cassandra-0.7/interface/cassandra.thrift?revision=1027174&view=markup In 0.6 you have ColumnOrSuperColumn get(1:required string keyspace, 2:required string key, 3:required ColumnPath column_path, 4:required ConsistencyLevel consistency_level=ONE) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutException te), In 0.7 you have ColumnOrSuperColumn get(1:required binary key, 2:required ColumnPath column_path, 3:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE) throws (1:InvalidRequestException ire, 2:NotFoundException nfe, 3:UnavailableException ue, 4:TimedOutExceptionte), With the added bonus that now you need to call set_keyspace, so what used to be one thrift call is now 2. I never quite understood the rational behind splitting the keyspace selection out, as most application's I've developed which use Cassandra use keyspace another layer of segmentation, so almost every one of them accesses multiple keyspaces. So selecting one means your pooling of connections has to be more complex. But I'm sure there was some reason. Anyway, as far as I know there is no way to do a rolling upgrade from 0.6 to 0.7, its a stop the world upgrade. This may be mitigated by the use of a client library which might hide some of the thrift calls, but if you have your own thrift client, you sort of have to shutdown everything and restart. This is definitely a problem for our usage, so I will not even consider a 0.6 to 0.7 upgrade until I have a chance to figure out some way I can do it without taking our business down (which is a definite no-go, downtime is lost revenue). Of course the fact that 18 months have passed since we put Cassandra into production and that 0.6 to 0.7 will be so painful has lead be to re-evaluate our use of Cassandra, and take a look at what other NoSQL solutions have been doing (because upgrading to a different system is less painful because they coexist with Cassandra during the transition, makes me think Cassandra should add a version to the service definition in the thrift file, just having "service Cassandra6" and "service Cassandra7" would I believe allow the two to coexisting in a client). Anyway, if you do figure out a way to migrate without downtime please share. -Anthony On Wed, Jan 19, 2011 at 09:29:37PM +0000, Aaron Morton wrote: > Unfortunately there are changes to the inter-node protocol which which make > it impossible to run a mixed cluster. > > The TTL feature is one of the things that mean you also have to upgrade the > client. The Columns returned and accepted by Cassandra will now expect to > have a TTL field. > > AFAIK in theory Thrift is designed to handle these sorts of changes, but I do > not know if thats how things have turned out in the real world. If you want > to test a 0.6 client against a 0.7 server, first disable the > thrift_framed_transport_size_in_mb setting as 0.6 did not use framed > transport http://wiki.apache.org/cassandra/StorageConfiguration?highlight=(framed) > > Let me know if you can working. Obviously it should be a temporary solution > and others will have a better understanding of the implications of running a > 0.6 client against 0.7 > > Hope that helps. > Aaron > > > On 20 Jan, 2011,at 01:55 AM, Daniel Josefsson <jid...@gmail.com> wrote: > > Hi, > > I've been looking around for how to upgrade from 0.6 to 0.7, and it looks > like you need to shut down the whole cluster, plus upgrade the clients at the > same time. > > Our live cassandra instances are currently running 0.6.4 with an ever growing > database and need the new TTL feature available in 0.7. For client we use > Pelops. > > Has anyone done a similar upgrade of a live cluster? How did you go about? > > Is there at least a way to avoid having to upgrade both server side and > client side simultaneously? > > Thanks, > Daniel > -- ------------------------------------------------------------------------ Anthony Molinaro <antho...@alumni.caltech.edu>
