Actually I didn't even notice that one :), the keyspace change and
changing the field order was more noticeable. If instead 0.7 had
done something like
ColumnOrSuperColumn get(1:optional string keyspace,
2:optional string key,
3:required ColumnPath column_path,
4:required ConsistencyLevel
consistency_level=ConsistencyLevel.ONE,
5:optional binary key7)
throws (1:InvalidRequestException ire,
2:NotFoundException nfe,
3:UnavailableException ue,
4:TimedOutException te),
You would be able to have a 0.6 client (with no changes) talk to a 0.7 server
and have a 0.7 client (which use set_keyspace and key7, but not keyspace and
key also talk to the server). Then with 0.8 you could do something like
ColumnOrSuperColumn get(
2:optional binary key,
3:required ColumnPath column_path,
4:required ConsistencyLevel
consistency_level=ConsistencyLevel.ONE,
5:optional binary key7)
throws (1:InvalidRequestException ire,
2:NotFoundException nfe,
3:UnavailableException ue,
4:TimedOutException te),
So that a 0.7 client could continue with not changes and a 0.8 client could
use key.
Then with 0.9 you would finally be at
ColumnOrSuperColumn get(
2:required binary key,
3:required ColumnPath column_path,
4:required ConsistencyLevel
consistency_level=ConsistencyLevel.ONE,
)
throws (1:InvalidRequestException ire,
2:NotFoundException nfe,
3:UnavailableException ue,
4:TimedOutException te),
At all times you would be backward compatible with the previous version of the
client, but you still make forward progress, and you can to upgrades to
cassandra without having to upgrade all the clients at the same time.
-Anthony
On Wed, Jan 19, 2011 at 10:04:54PM +0000, Aaron Morton wrote:
> Your right, forgot about the change to binary keys :)
>
> Forgot what I said.
> A
>
>
> On 20 Jan, 2011,at 11:01 AM, Anthony Molinaro <antho...@alumni.caltech.edu>
> wrote:
>
> 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>
--
------------------------------------------------------------------------
Anthony Molinaro <antho...@alumni.caltech.edu>
