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
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
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
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
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
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
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.
