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
the maven shade plugin might be able to help somewhat... if I get some spare
cycles I'll have a look at knocking up a thrift proxy that either makes 0.7
appear as 0.6 or vice versa
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are
Dual writes would require you to have both a 0.6 and 0.7 client in the same
code base unless you have some sort of intermediate file or queue or something.
Since 0.6 and 0.7 use the same names in their thrift files this won't work,
thus my suggestion of adding a second service to the 0.6 and 0.7 th
I agree. I am running a 0.6 cluster and would like to upgrade to 0.7. But,
I can not simply stop my existing nodes.
I need a way to load a new cluster - either on the same machines or new
machines - with the existing data.
I think my overall preference would be to upgrade the cluster to 0.7 run
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
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 wrote:
> No, what I'm thinking of is having t
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
n
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 mo
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 th
an alternative might be a thrift proxy service... mapping the old thrift api
onto the new.
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 20 Jan 2011 05:11, "Jonathan Ellis
On Wed, Jan 19, 2011 at 10:15 PM, Anthony Molinaro
wrote:
> So actually, how hard would it be to release a version of cassandra 6
> which contained a second service Cassandra6 which was a replica of
> service Cassandra, then forward porting that service to Cassandra 7?
Off the top of my head, I d
So actually, how hard would it be to release a version of cassandra 6
which contained a second service Cassandra6 which was a replica of
service Cassandra, then forward porting that service to Cassandra 7?
That would allow and upgrade to do the following
1. rolling upgrade 0.6 server to server wi
Really, my bad, I though they were, but maybe I'm confusing that with
protobuf, I work with too many serialization formats :(.
-Anthony
On Wed, Jan 19, 2011 at 04:46:48PM -0600, Jonathan Ellis wrote:
> On Wed, Jan 19, 2011 at 4:34 PM, Anthony Molinaro
> wrote:
> > Actually I didn't even notice t
On Wed, Jan 19, 2011 at 4:34 PM, Anthony Molinaro
wrote:
> 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
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
Your right, forgot about the change to binary keys :)Forgot what I said. AOn 20 Jan, 2011,at 11:01 AM, Anthony Molinaro 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
http
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://
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 T
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
19 matches
Mail list logo
