incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Questions while evaluating Cassandra
Date Thu, 04 Mar 2010 22:03:52 GMT
On Thu, Mar 4, 2010 at 2:51 AM, Eran Kutner <eran@gigya-inc.com> wrote:
> On Tue, Mar 2, 2010 at 15:44, Jonathan Ellis <jbellis@gmail.com> wrote:
>>
>> On Tue, Mar 2, 2010 at 6:43 AM, Eran Kutner <eran@gigya.com> wrote:
>> > Is the procedure described in the description of ticket CASSANDRA-44 really
>> > the way to do schema changes in the latest release? I'm not sure what's your
>> > thoughts about this but our experience is that every release of our software
>> > requires schema changes because we add new column families for indexes.
>>
>> Yes, that is how it is for 0.5 and 0.6.  0.7 will add online schema
>> changes (i.e., fix -44), Gary is working on that now.
>
> So just to be clear, that would require a complete cluster restart as
> well as stopping the client app (to prevent new writes from coming in
> after doing the flush), right? Do you know how others are handling it
> on a live system?

If you're just adding new CFs then you don't need to worry about the
commitlog.  So in production just leave the old ones defined and
remove the data files from the FS, client doesn't have to care, and
you can do a rolling restart of your cassandra nodes.

>> DatacenterShardStrategy will put multiple replicas in each DC, for use
>> with CL.DCQUORUM, that is, a majority of replicas in the same DC as
>> the coordinator node for the current request.  DCQOURUM is not yet
>> finished, though; currently it behaves the same as CL.ALL.
>
> Is it planned for any specific release?

It's planned as soon as someone wants it badly enough to finish it. :)

>> The short answer is, we maintained backwards compatibility for 0.4 ->
>> 0.5 -> 0.6, but we are going to break things in 0.7 moving from String
>> keys to byte[] and possibly other changes.
>
> hmmm... My assumption was that although keys are strings they are
> still compared as bytes when using the OPP right? That would be the
> difference between the OPP and the COPP, right? Just confirming
> because otherwise creating composite keys with different data types
> may prove problematic.

Right.

-Jonathan

Mime
View raw message