Failed decommission

2013-08-25 Thread Janne Jalkanen
This on cass 1.2.8 Ring state before decommission -- Address Load Owns Host ID TokenRack UN 10.0.0.1 38.82 GB 33.3% 21a98502-dc74-4ad0-9689-0880aa110409 1 1a UN 10.0.

Issue with CQLsh

2013-08-25 Thread Vivek Mishra
Hi, I have created a column family using Cassandra-cli as: create column family default; and then inserted some record as: set default[1]['type']='bytes'; Then i tried to alter table it via cqlsh as: alter table default alter key type text; // it works alter table default alter column1 type

Re: Failed decommission

2013-08-25 Thread Nate McCall
Are you using Murmur3 or the older Random partitioner on this cluster? On Sun, Aug 25, 2013 at 3:06 AM, Janne Jalkanen wrote: > This on cass 1.2.8 > > Ring state before decommission > > -- Address Load Owns Host ID > TokenRack > UN 10.0.0.1

Re: Failed decommission

2013-08-25 Thread Mike Heffner
Janne, We ran into this too. Appears it's a bug in 1.2.8 that is fixed in the upcoming 1.2.9. I added the steps I took to finally remove the node here: https://issues.apache.org/jira/browse/CASSANDRA-5857?focusedCommentId=13748998&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpan

Re: Failed decommission

2013-08-25 Thread Jon Haddad
We ran into a similar issue as well. I believe we removed the node via cqlsh from the system keyspace, restarted the cluster, then ran a repair. I'm not sure how safe this really is though. On Aug 25, 2013, at 8:47 AM, Mike Heffner wrote: > Janne, > > We ran into this too. Appears it's a b

Re: Failed decommission

2013-08-25 Thread Janne Jalkanen
This would be RP (cluster upgraded from 0.6->0.8->1.0->1.1 ;-). Looks to me like decommission assumes Murmur and 64-bit tokens. /Janne On Aug 25, 2013, at 17:25 , Nate McCall wrote: > Are you using Murmur3 or the older Random partitioner on this cluster? > > > On Sun, Aug 25, 2013 at 3:06 A

Re: Failed decommission

2013-08-25 Thread Janne Jalkanen
Thanks; this worked for me too. /Janne On Aug 25, 2013, at 18:47 , Mike Heffner wrote: > Janne, > > We ran into this too. Appears it's a bug in 1.2.8 that is fixed in the > upcoming 1.2.9. I added the steps I took to finally remove the node here: > https://issues.apache.org/jira/browse/CASS

conflict resolution in range scans

2013-08-25 Thread John Sanda
How is conflict resolution done with range scans? I understand when reading a single column, the latest timestamp wins. Is the timestamp for each column compared with a range scan such that some columns in the result could come from one replica while other columns come from another? - John

Re: Failed decommission

2013-08-25 Thread Nate McCall
This is what I was seeing code wise as well - but Mike's answer was spot on. Glad you got this straightened out. (And huge thanks to Mike for coming back to post a work-around here and on the ticket). On Sun, Aug 25, 2013 at 11:42 AM, Janne Jalkanen wrote: > > This would be RP (cluster upgraded

Re: Issue with CQLsh

2013-08-25 Thread Nate McCall
What version of cassandra are you using? On Sun, Aug 25, 2013 at 8:34 AM, Vivek Mishra wrote: > Hi, > I have created a column family using Cassandra-cli as: > > create column family default; > > and then inserted some record as: > > set default[1]['type']='bytes'; > > Then i tried to alter tabl

Re: conflict resolution in range scans

2013-08-25 Thread Nate McCall
See that last part on this page: http://wiki.apache.org/cassandra/ReadRepair This doc is dated, but I'm pretty sure it still works this way. On Sun, Aug 25, 2013 at 3:38 PM, John Sanda wrote: > How is conflict resolution done with range scans? I understand when > reading a single column, the l

Re: Issue with CQLsh

2013-08-25 Thread Vivek Mishra
cassandra 1.2.4 On Mon, Aug 26, 2013 at 2:51 AM, Nate McCall wrote: > What version of cassandra are you using? > > > On Sun, Aug 25, 2013 at 8:34 AM, Vivek Mishra wrote: > >> Hi, >> I have created a column family using Cassandra-cli as: >> >> create column family default; >> >> and then inserte

Re: OrderPreservingPartitioner in 1.2

2013-08-25 Thread Takenori Sato(Cloudian)
From the Jira, > One possibility is that getToken of OPP can return hex value if it fails to encode bytes to UTF-8 instead of throwing error. By this system tables seem to be working fine with OPP. This looks like an option to try for me. Thanks! (2013/08/23 20:44), Vara Kumar wrote: For th

Re: Issue with CQLsh

2013-08-25 Thread Jonathan Haddad
My understanding is that if you want to use CQL, you should create your tables via CQL. Mixing thrift calls w/ CQL seems like it's just asking for problems like this. On Sun, Aug 25, 2013 at 6:53 PM, Vivek Mishra wrote: > cassandra 1.2.4 > > > On Mon, Aug 26, 2013 at 2:51 AM, Nate McCall wrote

Re: Issue with CQLsh

2013-08-25 Thread Vivek Mishra
I understand that CQL <-> Thrift interoperability is an issue. For Application which were build earlier(using thrift) there must be a way and it should be at least give some error message, but it simply hangs with out any error. -Vivek On Mon, Aug 26, 2013 at 8:42 AM, Jonathan Haddad wrote: >

Cluster Management

2013-08-25 Thread Anthony Grasso
Hi Cassandra Users, Before I go ahead and create my own solution... are there any tools that exist to help with the management of a Cassandra cluster? For example, if I want to make some changes to the configuration file that resides on each node, is there a tool that will propagate the change to