Re: decommission dead node without token

2014-06-01 Thread Jens Rantil
You might need double backslashes in bash.—
Sent from Mailbox

On Sun, Jun 1, 2014 at 6:42 AM, Tim Dunphy  wrote:

>>
>> backslash it  \-9485547484
>> just guessing.
> Oh, worth a shot! But I'm heading to bed now. I'll try again with this
> tomorrow.
> cya
> Tim
> On Sun, Jun 1, 2014 at 12:39 AM, Spencer Brown  wrote:
>> backslash it  \-9485547484
>> just guessing.
>>
>>
>> On Sun, Jun 1, 2014 at 12:31 AM, Tim Dunphy  wrote:
>>
>>> nodetool -host 10.10.1.68 removetoken -9208584805646615844
>>>
>>>
>>> I still get a unix usage message with this syntax, yo. Just a theory
>>> dude, but I think that the negative sign is confusing bash.
>>>
>>> But yeah definitely fixing posts is the priority. Then maybe we can
>>> tackle my cassandra woes. And then move onto improving the font.  Mainly
>>> cassandra is an issue in that I can't do a repair on the database unless
>>> all nodes are present with none down. I definitely think there's a way out
>>> of this jam. I hope that the list has some input here.
>>>
>>>  But definitely don't worry about JF until you're caught up with work. I
>>> want to see you keep this job going as much as you can. Like I do with mine
>>> at NBCU! :)
>>>
>>> on fixing posting or nodes?  I don't think posting fix should be too
 hard.  I'm mainly just late with my primary job in fixing something which
 should be easy.  It's an AJAX sort of thing.  Have you dealt with that...
  it's hard.  It means Asynchronous Javascript and XML.  And there's an HTML
 element too.  And in this case there is some JQuery.  And when you combine
 all that it becomes a pain in the ass.
>>>
>>>
>>> Never really dealt with AJAX. Always meant to get into it tho. I hear it
>>> can be powerful! But definitely good luck with that! And I hope you can
>>> indeed get to do some JF stuff this weekend. But don't stress about it if
>>> you're stuck with work.
>>>
>>> Tim
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Jun 1, 2014 at 12:21 AM, Spencer Brown 
>>> wrote:
>>>
 nodetool -host 10.10.1.68 removetoken -9208584805646615844


 On Sun, Jun 1, 2014 at 12:17 AM, Tim Dunphy 
 wrote:

> sorry for the barrage of questions but I'm having trouble with the
> nodetool remove phase.
>
> [root@cassandra01 ~]# nodetool removetoken -h 10.10.1.68
> -9208584805646615844
>
> Gives me a unix usage message. As in:
>
> [root@cassandra01 ~]# nodetool removetoken -h 107.170.178.68
> -9208584805646615844 | head -5
> Unrecognized option: -9208584805646615844
> usage: java org.apache.cassandra.tools.NodeCmd --host  
>
>  -a,--include-all-sstables   includes sstables that are already on the
>  most recent version during upgradesstables
>  -c,--compactprint histograms in a more compact format
>
> I think the problem is that the bash environment is getting confused by
> the minus sign in front of the token. But that is the token and the minus
> sign is integral to it. I've even tried quoting it with both single quotes
> and double quotes to no avail. I still get the same usage message.
>
> Can someone please help with the right syntax here?
>
> Thanks
> Tim
>
>
> On Sun, Jun 1, 2014 at 12:01 AM, Tim Dunphy 
> wrote:
>
>> Just wondering.. might I be able to retried the 'lost' intital_token
>> of the node I want to remove by going:
>>
>> [root@beta-new:~] #nodetool ring | grep 10.10.1.102 | head -1
>> 107.170.175.102  rack1   Down   Normal  123.41 KB   32.19%
>>  -9208584805646615844
>>
>> Then
>>
>> 1) place that token in the cassandra.yaml of a new node with a new IP
>> as  -9208584805646615844 -1
>> 2)  set auto_bootstrap in the cassandra.yaml
>> 3) once the node boots run 'nodetool removetoken -9208584805646615844'
>> 4) run nodetool cleanup
>>
>> Would this be the way to get out of this bind? Just want to be sure I
>> understand the process.
>>
>> Thanks
>> Tim
>>
>>
>> On Sat, May 31, 2014 at 10:38 PM, Tim Dunphy 
>> wrote:
>>
>>> hey guys,
>>>
>>>  I have two dead nodes in my ring.
>>>
>>>  Status=Up/Down
>>>
>>> |/ State=Normal/Leaving/Joining/Moving
>>>
>>> --  Address  Load   Tokens  Owns   Host ID
>>> Rack
>>>
>>> DN  10.10.1.102  123.41 KB  256 32.2%
>>> ddcafc75-24ed-4c6a-99bb-afe3dd551a9c  rack1
>>>
>>> UN  10.10.1.94   170.81 KB  256 35.4%
>>> fd2f76ae-8dcf-4e93-a37f-bf1e9088696e  rack1
>>>
>>> DN  10..10.10.64   ?  256 32.5%
>>> f2a48fc7-a362-43f5-9061-4bb3739fdeaf  rack1
>>>
>>>
>>> Unfortunately I am early in my learning curve and failed to preserve
>>> the initial_token for each of the nodes that were taken out of service. 
>>> As
>>> things stand now I cannot do a nodetool 

Batched statements two different cassandra clusters.

2014-06-01 Thread Kevin Burton
As far as I understand, this is impossible.

There isn't a way to figure out which statement goes to which cluster.

We are going to have two different clusters because the hardware config is
slightly different and so is our caching strategy.

A plan B could be to write to both commits to something like JMS/Apollo and
then use transactional messages to verify that everything is written to
both places.



-- 

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
Skype: *burtonator*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile


War is peace. Freedom is slavery. Ignorance is strength. Corporations are
people.


Tune cache MB settings per table.

2014-06-01 Thread Kevin Burton
It's possible to set caching to:

all, keys_only, rows_only, or none

.. for a given table.

But we have one table which is MASSIVE and we only need the most recent 4-8
hours in memory.

Anything older than that can go to disk as the queries there are very rare.

… but I don't think cassandra can do this (which is a shame).

Another option is to partition our tables per hour… then tell the older
tables to cache 'none'…

I hate this option though.  A smarter mechanism would be to have a
compaction strategy that created an SSTable for every hour and then had
custom caching settings for that table.

The additional upside for this is that TTLs would just drop the older data
in the compactor..

-- 

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
Skype: *burtonator*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile


War is peace. Freedom is slavery. Ignorance is strength. Corporations are
people.


Re: Batched statements two different cassandra clusters.

2014-06-01 Thread Colin
Set it up as one cluster with multiple datacenters and configure replication 
accordingly.

--
Colin Clark 
+1-320-221-9531
 

> On Jun 1, 2014, at 2:43 PM, Kevin Burton  wrote:
> 
> As far as I understand, this is impossible.
> 
> There isn't a way to figure out which statement goes to which cluster.
> 
> We are going to have two different clusters because the hardware config is 
> slightly different and so is our caching strategy.
> 
> A plan B could be to write to both commits to something like JMS/Apollo and 
> then use transactional messages to verify that everything is written to both 
> places.
> 
> 
> 
> -- 
> Founder/CEO Spinn3r.com
> Location: San Francisco, CA
> Skype: burtonator
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations are 
> people.


Re: Tune cache MB settings per table.

2014-06-01 Thread Colin
The OS should handle this really well as long as your on v3 linux kernel  

--
Colin Clark 
+1-320-221-9531
 

> On Jun 1, 2014, at 2:49 PM, Kevin Burton  wrote:
> 
> It's possible to set caching to:
> 
> all, keys_only, rows_only, or none
> 
> .. for a given table.
> 
> But we have one table which is MASSIVE and we only need the most recent 4-8 
> hours in memory.  
> 
> Anything older than that can go to disk as the queries there are very rare.
> 
> … but I don't think cassandra can do this (which is a shame).
> 
> Another option is to partition our tables per hour… then tell the older 
> tables to cache 'none'… 
> 
> I hate this option though.  A smarter mechanism would be to have a compaction 
> strategy that created an SSTable for every hour and then had custom caching 
> settings for that table.
> 
> The additional upside for this is that TTLs would just drop the older data in 
> the compactor.. 
> 
> -- 
> Founder/CEO Spinn3r.com
> Location: San Francisco, CA
> Skype: burtonator
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations are 
> people.


Re: Tune cache MB settings per table.

2014-06-01 Thread DuyHai Doan
Hello Kevin

 You'll be probably interested by this :
http://www.datastax.com/dev/blog/row-caching-in-cassandra-2-1


On Sun, Jun 1, 2014 at 9:49 PM, Kevin Burton  wrote:

> It's possible to set caching to:
>
> all, keys_only, rows_only, or none
>
> .. for a given table.
>
> But we have one table which is MASSIVE and we only need the most recent
> 4-8 hours in memory.
>
> Anything older than that can go to disk as the queries there are very rare.
>
> … but I don't think cassandra can do this (which is a shame).
>
> Another option is to partition our tables per hour… then tell the older
> tables to cache 'none'…
>
> I hate this option though.  A smarter mechanism would be to have a
> compaction strategy that created an SSTable for every hour and then had
> custom caching settings for that table.
>
> The additional upside for this is that TTLs would just drop the older data
> in the compactor..
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> Skype: *burtonator*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations are
> people.
>
>


Re: I have a deaf node?

2014-06-01 Thread Kevin Burton
could be worse… it could be under caffeinated and say decafbad …


On Sat, May 31, 2014 at 10:45 AM, Tim Dunphy  wrote:

> I think the "deaf" thing is just the ending of the host ID in hexadecimal.
>> It's an extraordinary coincidence that it ends with DEAF :D
>
>
> Hah.. yeah that thought did cross my mind.  :)
>
>
>
> On Sat, May 31, 2014 at 1:35 PM, DuyHai Doan  wrote:
>
>> I think the "deaf" thing is just the ending of the host ID in
>> hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D
>>
>>
>> On Sat, May 31, 2014 at 6:38 PM, Tim Dunphy  wrote:
>>
>>> I didn't realize cassandra nodes could develop hearing problems. :)
>>>
>>>
>>> But I have a dead node in my cluster I would like to get rid of.
>>>
>>> [root@beta:~] #nodetool status
>>> Datacenter: datacenter1
>>> ===
>>> Status=Up/Down
>>> |/ State=Normal/Leaving/Joining/Moving
>>> --  Address Load   Tokens  Owns   Host ID
>>> Rack
>>> UN  10.10.1.94  199.6 KB   256 49.4%
>>>  fd2f76ae-8dcf-4e93-a37f-bf1e9088696e  rack1
>>> DN  10.10.1.64  ?  256 50.6%
>>>  f2a48fc7-a362-43f5-9061-4bb3739f*deaf * rack1
>>>
>>> I was just wondering what this could indicate and if that might mean
>>> that I will have some more trouble than I would be bargaining for in
>>> getting rid of it.
>>>
>>> I've made a couple of attempts to get rid of this so far. I'm about to
>>> try again.
>>>
>>> Thanks
>>> Tim
>>>
>>> --
>>> GPG me!!
>>>
>>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>>
>>>
>>
>
>
> --
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>
>


-- 

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
Skype: *burtonator*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile


War is peace. Freedom is slavery. Ignorance is strength. Corporations are
people.


Re: Tune cache MB settings per table.

2014-06-01 Thread Kevin Burton
Not in our experience… We've been using fadvise don't need to purge pages
that aren't necessary any longer.

Of course YMMV based on your usage.  I tend to like to control everything
explicitly instead of having magic.

That's worked out very well for us in the past so it would be nice to still
have this on cassandra.


On Sun, Jun 1, 2014 at 12:53 PM, Colin  wrote:

> The OS should handle this really well as long as your on v3 linux
> kernel
>
> --
> *Colin Clark*
> +1-320-221-9531
>
>
> On Jun 1, 2014, at 2:49 PM, Kevin Burton  wrote:
>
> It's possible to set caching to:
>
> all, keys_only, rows_only, or none
>
> .. for a given table.
>
> But we have one table which is MASSIVE and we only need the most recent
> 4-8 hours in memory.
>
> Anything older than that can go to disk as the queries there are very rare.
>
> … but I don't think cassandra can do this (which is a shame).
>
> Another option is to partition our tables per hour… then tell the older
> tables to cache 'none'…
>
> I hate this option though.  A smarter mechanism would be to have a
> compaction strategy that created an SSTable for every hour and then had
> custom caching settings for that table.
>
> The additional upside for this is that TTLs would just drop the older data
> in the compactor..
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> Skype: *burtonator*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations are
> people.
>
>


-- 

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
Skype: *burtonator*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile


War is peace. Freedom is slavery. Ignorance is strength. Corporations are
people.


Re: Tune cache MB settings per table.

2014-06-01 Thread Colin
Have you been unable to achieve your SLA's using Cassandra out of the box so 
far?

Based upon my experience, trying to tune Cassandra before the app is done and 
without simulating real world load patterns, you might actually be doing 
yourself a disservice.

--
Colin
320-221-9531


> On Jun 1, 2014, at 6:08 PM, Kevin Burton  wrote:
> 
> Not in our experience… We've been using fadvise don't need to purge pages 
> that aren't necessary any longer.
> 
> Of course YMMV based on your usage.  I tend to like to control everything 
> explicitly instead of having magic.
> 
> That's worked out very well for us in the past so it would be nice to still 
> have this on cassandra.
> 
> 
>> On Sun, Jun 1, 2014 at 12:53 PM, Colin  wrote:
>> The OS should handle this really well as long as your on v3 linux kernel 
>>  
>> 
>> --
>> Colin Clark 
>> +1-320-221-9531
>>  
>> 
>>> On Jun 1, 2014, at 2:49 PM, Kevin Burton  wrote:
>>> 
>>> It's possible to set caching to:
>>> 
>>> all, keys_only, rows_only, or none
>>> 
>>> .. for a given table.
>>> 
>>> But we have one table which is MASSIVE and we only need the most recent 4-8 
>>> hours in memory.  
>>> 
>>> Anything older than that can go to disk as the queries there are very rare.
>>> 
>>> … but I don't think cassandra can do this (which is a shame).
>>> 
>>> Another option is to partition our tables per hour… then tell the older 
>>> tables to cache 'none'… 
>>> 
>>> I hate this option though.  A smarter mechanism would be to have a 
>>> compaction strategy that created an SSTable for every hour and then had 
>>> custom caching settings for that table.
>>> 
>>> The additional upside for this is that TTLs would just drop the older data 
>>> in the compactor.. 
>>> 
>>> -- 
>>> Founder/CEO Spinn3r.com
>>> Location: San Francisco, CA
>>> Skype: burtonator
>>> blog: http://burtonator.wordpress.com
>>> … or check out my Google+ profile
>>> 
>>> War is peace. Freedom is slavery. Ignorance is strength. Corporations are 
>>> people.
> 
> 
> 
> -- 
> Founder/CEO Spinn3r.com
> Location: San Francisco, CA
> Skype: burtonator
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations are 
> people.


Re: Tune cache MB settings per table.

2014-06-01 Thread Jonathan Haddad
I think of all the areas you could spend your time, this will have the
least returns.  The OS will keep the most frequently used data in memory.
 There's no reason to require cassandra to do it.

If you're curious as to what's been loaded into ram, try Al Tobey's pcstat
utility.  https://github.com/tobert/pcstat


On Sun, Jun 1, 2014 at 4:30 PM, Colin  wrote:

> Have you been unable to achieve your SLA's using Cassandra out of the box
> so far?
>
> Based upon my experience, trying to tune Cassandra before the app is done
> and without simulating real world load patterns, you might actually be
> doing yourself a disservice.
>
> --
> Colin
> 320-221-9531
>
>
> On Jun 1, 2014, at 6:08 PM, Kevin Burton  wrote:
>
> Not in our experience… We've been using fadvise don't need to purge pages
> that aren't necessary any longer.
>
> Of course YMMV based on your usage.  I tend to like to control everything
> explicitly instead of having magic.
>
> That's worked out very well for us in the past so it would be nice to
> still have this on cassandra.
>
>
> On Sun, Jun 1, 2014 at 12:53 PM, Colin  wrote:
>
>> The OS should handle this really well as long as your on v3 linux
>> kernel
>>
>> --
>> *Colin Clark*
>> +1-320-221-9531
>>
>>
>> On Jun 1, 2014, at 2:49 PM, Kevin Burton  wrote:
>>
>> It's possible to set caching to:
>>
>> all, keys_only, rows_only, or none
>>
>> .. for a given table.
>>
>> But we have one table which is MASSIVE and we only need the most recent
>> 4-8 hours in memory.
>>
>> Anything older than that can go to disk as the queries there are very
>> rare.
>>
>> … but I don't think cassandra can do this (which is a shame).
>>
>> Another option is to partition our tables per hour… then tell the older
>> tables to cache 'none'…
>>
>> I hate this option though.  A smarter mechanism would be to have a
>> compaction strategy that created an SSTable for every hour and then had
>> custom caching settings for that table.
>>
>> The additional upside for this is that TTLs would just drop the older
>> data in the compactor..
>>
>> --
>>
>> Founder/CEO Spinn3r.com
>> Location: *San Francisco, CA*
>> Skype: *burtonator*
>> blog: http://burtonator.wordpress.com
>> … or check out my Google+ profile
>> 
>> 
>> War is peace. Freedom is slavery. Ignorance is strength. Corporations are
>> people.
>>
>>
>
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> Skype: *burtonator*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations are
> people.
>
>


-- 
Jon Haddad
http://www.rustyrazorblade.com
skype: rustyrazorblade


Re: Tune cache MB settings per table.

2014-06-01 Thread Kevin Burton
Good question. still migrating.. but we don't want to paint ourselves into
a corner.

There's an interesting line between premature optimization and painting
yourself into a corner ;)

Best to get it right in between both extremes.


On Sun, Jun 1, 2014 at 4:30 PM, Colin  wrote:

> Have you been unable to achieve your SLA's using Cassandra out of the box
> so far?
>
> Based upon my experience, trying to tune Cassandra before the app is done
> and without simulating real world load patterns, you might actually be
> doing yourself a disservice.
>
> --
> Colin
> 320-221-9531
>
>
> On Jun 1, 2014, at 6:08 PM, Kevin Burton  wrote:
>
> Not in our experience… We've been using fadvise don't need to purge pages
> that aren't necessary any longer.
>
> Of course YMMV based on your usage.  I tend to like to control everything
> explicitly instead of having magic.
>
> That's worked out very well for us in the past so it would be nice to
> still have this on cassandra.
>
>
> On Sun, Jun 1, 2014 at 12:53 PM, Colin  wrote:
>
>> The OS should handle this really well as long as your on v3 linux
>> kernel
>>
>> --
>> *Colin Clark*
>> +1-320-221-9531
>>
>>
>> On Jun 1, 2014, at 2:49 PM, Kevin Burton  wrote:
>>
>> It's possible to set caching to:
>>
>> all, keys_only, rows_only, or none
>>
>> .. for a given table.
>>
>> But we have one table which is MASSIVE and we only need the most recent
>> 4-8 hours in memory.
>>
>> Anything older than that can go to disk as the queries there are very
>> rare.
>>
>> … but I don't think cassandra can do this (which is a shame).
>>
>> Another option is to partition our tables per hour… then tell the older
>> tables to cache 'none'…
>>
>> I hate this option though.  A smarter mechanism would be to have a
>> compaction strategy that created an SSTable for every hour and then had
>> custom caching settings for that table.
>>
>> The additional upside for this is that TTLs would just drop the older
>> data in the compactor..
>>
>> --
>>
>> Founder/CEO Spinn3r.com
>> Location: *San Francisco, CA*
>> Skype: *burtonator*
>> blog: http://burtonator.wordpress.com
>> … or check out my Google+ profile
>> 
>> 
>> War is peace. Freedom is slavery. Ignorance is strength. Corporations are
>> people.
>>
>>
>
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> Skype: *burtonator*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations are
> people.
>
>


-- 

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
Skype: *burtonator*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile


War is peace. Freedom is slavery. Ignorance is strength. Corporations are
people.


Re: Tune cache MB settings per table.

2014-06-01 Thread Colin
Your data model will most likely be the far most important component of your 
migration.  Get that right, and the rest is easy.

--
Colin Clark 
+1-320-221-9531
 

> On Jun 1, 2014, at 7:01 PM, Kevin Burton  wrote:
> 
> Good question. still migrating.. but we don't want to paint ourselves into a 
> corner.
> 
> There's an interesting line between premature optimization and painting 
> yourself into a corner ;)
> 
> Best to get it right in between both extremes.
> 
> 
>> On Sun, Jun 1, 2014 at 4:30 PM, Colin  wrote:
>> Have you been unable to achieve your SLA's using Cassandra out of the box so 
>> far?
>> 
>> Based upon my experience, trying to tune Cassandra before the app is done 
>> and without simulating real world load patterns, you might actually be doing 
>> yourself a disservice.
>> 
>> --
>> Colin
>> 320-221-9531
>> 
>> 
>>> On Jun 1, 2014, at 6:08 PM, Kevin Burton  wrote:
>>> 
>>> Not in our experience… We've been using fadvise don't need to purge pages 
>>> that aren't necessary any longer.
>>> 
>>> Of course YMMV based on your usage.  I tend to like to control everything 
>>> explicitly instead of having magic.
>>> 
>>> That's worked out very well for us in the past so it would be nice to still 
>>> have this on cassandra.
>>> 
>>> 
 On Sun, Jun 1, 2014 at 12:53 PM, Colin  wrote:
 The OS should handle this really well as long as your on v3 linux 
 kernel  
 
 --
 Colin Clark 
 +1-320-221-9531
  
 
> On Jun 1, 2014, at 2:49 PM, Kevin Burton  wrote:
> 
> It's possible to set caching to:
> 
> all, keys_only, rows_only, or none
> 
> .. for a given table.
> 
> But we have one table which is MASSIVE and we only need the most recent 
> 4-8 hours in memory.  
> 
> Anything older than that can go to disk as the queries there are very 
> rare.
> 
> … but I don't think cassandra can do this (which is a shame).
> 
> Another option is to partition our tables per hour… then tell the older 
> tables to cache 'none'… 
> 
> I hate this option though.  A smarter mechanism would be to have a 
> compaction strategy that created an SSTable for every hour and then had 
> custom caching settings for that table.
> 
> The additional upside for this is that TTLs would just drop the older 
> data in the compactor.. 
> 
> -- 
> Founder/CEO Spinn3r.com
> Location: San Francisco, CA
> Skype: burtonator
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations are 
> people.
>>> 
>>> 
>>> 
>>> -- 
>>> Founder/CEO Spinn3r.com
>>> Location: San Francisco, CA
>>> Skype: burtonator
>>> blog: http://burtonator.wordpress.com
>>> … or check out my Google+ profile
>>> 
>>> War is peace. Freedom is slavery. Ignorance is strength. Corporations are 
>>> people.
> 
> 
> 
> -- 
> Founder/CEO Spinn3r.com
> Location: San Francisco, CA
> Skype: burtonator
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations are 
> people.


Re: I have a deaf node?

2014-06-01 Thread Apostolis Xekoukoulotakis
That made my day. Not to worry thought unless you  start seeing the number
23 in your host ids.
On Jun 2, 2014 12:40 AM, "Kevin Burton"  wrote:

> could be worse… it could be under caffeinated and say decafbad …
>
>
> On Sat, May 31, 2014 at 10:45 AM, Tim Dunphy  wrote:
>
>> I think the "deaf" thing is just the ending of the host ID in
>>> hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D
>>
>>
>> Hah.. yeah that thought did cross my mind.  :)
>>
>>
>>
>> On Sat, May 31, 2014 at 1:35 PM, DuyHai Doan 
>> wrote:
>>
>>> I think the "deaf" thing is just the ending of the host ID in
>>> hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D
>>>
>>>
>>> On Sat, May 31, 2014 at 6:38 PM, Tim Dunphy 
>>> wrote:
>>>
 I didn't realize cassandra nodes could develop hearing problems. :)


 But I have a dead node in my cluster I would like to get rid of.

 [root@beta:~] #nodetool status
 Datacenter: datacenter1
 ===
 Status=Up/Down
 |/ State=Normal/Leaving/Joining/Moving
 --  Address Load   Tokens  Owns   Host ID
 Rack
 UN  10.10.1.94  199.6 KB   256 49.4%
  fd2f76ae-8dcf-4e93-a37f-bf1e9088696e  rack1
 DN  10.10.1.64  ?  256 50.6%
  f2a48fc7-a362-43f5-9061-4bb3739f*deaf * rack1

 I was just wondering what this could indicate and if that might mean
 that I will have some more trouble than I would be bargaining for in
 getting rid of it.

 I've made a couple of attempts to get rid of this so far. I'm about to
 try again.

 Thanks
 Tim

 --
 GPG me!!

 gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B


>>>
>>
>>
>> --
>> GPG me!!
>>
>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>
>>
>
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> Skype: *burtonator*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations are
> people.
>
>


Re: I have a deaf node?

2014-06-01 Thread Tim Dunphy
>
> That made my day. Not to worry thought unless you  start seeing the number
> 23 in your host ids.


Yeah man, glad to provide some comic relief to the list! ;)


On Sun, Jun 1, 2014 at 11:01 PM, Apostolis Xekoukoulotakis <
xekou...@gmail.com> wrote:

> That made my day. Not to worry thought unless you  start seeing the number
> 23 in your host ids.
> On Jun 2, 2014 12:40 AM, "Kevin Burton"  wrote:
>
>> could be worse… it could be under caffeinated and say decafbad …
>>
>>
>> On Sat, May 31, 2014 at 10:45 AM, Tim Dunphy 
>> wrote:
>>
>>> I think the "deaf" thing is just the ending of the host ID in
 hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D
>>>
>>>
>>> Hah.. yeah that thought did cross my mind.  :)
>>>
>>>
>>>
>>> On Sat, May 31, 2014 at 1:35 PM, DuyHai Doan 
>>> wrote:
>>>
 I think the "deaf" thing is just the ending of the host ID in
 hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D


 On Sat, May 31, 2014 at 6:38 PM, Tim Dunphy 
 wrote:

> I didn't realize cassandra nodes could develop hearing problems. :)
>
>
> But I have a dead node in my cluster I would like to get rid of.
>
> [root@beta:~] #nodetool status
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  Address Load   Tokens  Owns   Host ID
>   Rack
> UN  10.10.1.94  199.6 KB   256 49.4%
>  fd2f76ae-8dcf-4e93-a37f-bf1e9088696e  rack1
> DN  10.10.1.64  ?  256 50.6%
>  f2a48fc7-a362-43f5-9061-4bb3739f*deaf * rack1
>
> I was just wondering what this could indicate and if that might mean
> that I will have some more trouble than I would be bargaining for in
> getting rid of it.
>
> I've made a couple of attempts to get rid of this so far. I'm about to
> try again.
>
> Thanks
> Tim
>
> --
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>
>

>>>
>>>
>>> --
>>> GPG me!!
>>>
>>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>>
>>>
>>
>>
>> --
>>
>> Founder/CEO Spinn3r.com
>> Location: *San Francisco, CA*
>> Skype: *burtonator*
>> blog: http://burtonator.wordpress.com
>> … or check out my Google+ profile
>> 
>> 
>> War is peace. Freedom is slavery. Ignorance is strength. Corporations are
>> people.
>>
>>


-- 
GPG me!!

gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B


Re: I have a deaf node?

2014-06-01 Thread Paulo Ricardo Motta Gomes
This post should definitely make to the hall of fame!! :)


On Mon, Jun 2, 2014 at 12:05 AM, Tim Dunphy  wrote:

> That made my day. Not to worry thought unless you  start seeing the number
>> 23 in your host ids.
>
>
> Yeah man, glad to provide some comic relief to the list! ;)
>
>
> On Sun, Jun 1, 2014 at 11:01 PM, Apostolis Xekoukoulotakis <
> xekou...@gmail.com> wrote:
>
>> That made my day. Not to worry thought unless you  start seeing the
>> number 23 in your host ids.
>>  On Jun 2, 2014 12:40 AM, "Kevin Burton"  wrote:
>>
>>> could be worse… it could be under caffeinated and say decafbad …
>>>
>>>
>>> On Sat, May 31, 2014 at 10:45 AM, Tim Dunphy 
>>> wrote:
>>>
 I think the "deaf" thing is just the ending of the host ID in
> hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D


 Hah.. yeah that thought did cross my mind.  :)



 On Sat, May 31, 2014 at 1:35 PM, DuyHai Doan 
 wrote:

> I think the "deaf" thing is just the ending of the host ID in
> hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D
>
>
> On Sat, May 31, 2014 at 6:38 PM, Tim Dunphy 
> wrote:
>
>> I didn't realize cassandra nodes could develop hearing problems. :)
>>
>>
>> But I have a dead node in my cluster I would like to get rid of.
>>
>> [root@beta:~] #nodetool status
>> Datacenter: datacenter1
>> ===
>> Status=Up/Down
>> |/ State=Normal/Leaving/Joining/Moving
>> --  Address Load   Tokens  Owns   Host ID
>>   Rack
>> UN  10.10.1.94  199.6 KB   256 49.4%
>>  fd2f76ae-8dcf-4e93-a37f-bf1e9088696e  rack1
>> DN  10.10.1.64  ?  256 50.6%
>>  f2a48fc7-a362-43f5-9061-4bb3739f*deaf * rack1
>>
>> I was just wondering what this could indicate and if that might mean
>> that I will have some more trouble than I would be bargaining for in
>> getting rid of it.
>>
>> I've made a couple of attempts to get rid of this so far. I'm about
>> to try again.
>>
>> Thanks
>> Tim
>>
>> --
>> GPG me!!
>>
>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>
>>
>


 --
 GPG me!!

 gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B


>>>
>>>
>>> --
>>>
>>> Founder/CEO Spinn3r.com
>>> Location: *San Francisco, CA*
>>> Skype: *burtonator*
>>> blog: http://burtonator.wordpress.com
>>> … or check out my Google+ profile
>>> 
>>> 
>>> War is peace. Freedom is slavery. Ignorance is strength. Corporations
>>> are people.
>>>
>>>
>
>
> --
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>
>


-- 
*Paulo Motta*

Chaordic | *Platform*
*www.chaordic.com.br *
+55 48 3232.3200


Re: I have a deaf node?

2014-06-01 Thread Tim Dunphy
>
> This post should definitely make to the hall of fame!! :)


My proudest accomplishment on the list. heh


On Sun, Jun 1, 2014 at 11:24 PM, Paulo Ricardo Motta Gomes <
paulo.mo...@chaordicsystems.com> wrote:

> This post should definitely make to the hall of fame!! :)
>
>
> On Mon, Jun 2, 2014 at 12:05 AM, Tim Dunphy  wrote:
>
>> That made my day. Not to worry thought unless you  start seeing the
>>> number 23 in your host ids.
>>
>>
>> Yeah man, glad to provide some comic relief to the list! ;)
>>
>>
>> On Sun, Jun 1, 2014 at 11:01 PM, Apostolis Xekoukoulotakis <
>> xekou...@gmail.com> wrote:
>>
>>> That made my day. Not to worry thought unless you  start seeing the
>>> number 23 in your host ids.
>>>  On Jun 2, 2014 12:40 AM, "Kevin Burton"  wrote:
>>>
 could be worse… it could be under caffeinated and say decafbad …


 On Sat, May 31, 2014 at 10:45 AM, Tim Dunphy 
 wrote:

> I think the "deaf" thing is just the ending of the host ID in
>> hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D
>
>
> Hah.. yeah that thought did cross my mind.  :)
>
>
>
> On Sat, May 31, 2014 at 1:35 PM, DuyHai Doan 
> wrote:
>
>> I think the "deaf" thing is just the ending of the host ID in
>> hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D
>>
>>
>> On Sat, May 31, 2014 at 6:38 PM, Tim Dunphy 
>> wrote:
>>
>>> I didn't realize cassandra nodes could develop hearing problems. :)
>>>
>>>
>>> But I have a dead node in my cluster I would like to get rid of.
>>>
>>> [root@beta:~] #nodetool status
>>> Datacenter: datacenter1
>>> ===
>>> Status=Up/Down
>>> |/ State=Normal/Leaving/Joining/Moving
>>> --  Address Load   Tokens  Owns   Host ID
>>> Rack
>>> UN  10.10.1.94  199.6 KB   256 49.4%
>>>  fd2f76ae-8dcf-4e93-a37f-bf1e9088696e  rack1
>>> DN  10.10.1.64  ?  256 50.6%
>>>  f2a48fc7-a362-43f5-9061-4bb3739f*deaf * rack1
>>>
>>> I was just wondering what this could indicate and if that might mean
>>> that I will have some more trouble than I would be bargaining for in
>>> getting rid of it.
>>>
>>> I've made a couple of attempts to get rid of this so far. I'm about
>>> to try again.
>>>
>>> Thanks
>>> Tim
>>>
>>> --
>>> GPG me!!
>>>
>>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>>
>>>
>>
>
>
> --
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>
>


 --

 Founder/CEO Spinn3r.com
 Location: *San Francisco, CA*
 Skype: *burtonator*
 blog: http://burtonator.wordpress.com
 … or check out my Google+ profile
 
 
 War is peace. Freedom is slavery. Ignorance is strength. Corporations
 are people.


>>
>>
>> --
>> GPG me!!
>>
>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>
>>
>
>
> --
> *Paulo Motta*
>
> Chaordic | *Platform*
> *www.chaordic.com.br *
> +55 48 3232.3200
>



-- 
GPG me!!

gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B


Re: I have a deaf node?

2014-06-01 Thread David Daeschler
I wouldnt worry unless it changes from deaf to deadbeef


On Sun, Jun 1, 2014 at 11:34 PM, Tim Dunphy  wrote:

> This post should definitely make to the hall of fame!! :)
>
>
> My proudest accomplishment on the list. heh
>
>
> On Sun, Jun 1, 2014 at 11:24 PM, Paulo Ricardo Motta Gomes <
> paulo.mo...@chaordicsystems.com> wrote:
>
>> This post should definitely make to the hall of fame!! :)
>>
>>
>> On Mon, Jun 2, 2014 at 12:05 AM, Tim Dunphy  wrote:
>>
>>> That made my day. Not to worry thought unless you  start seeing the
 number 23 in your host ids.
>>>
>>>
>>> Yeah man, glad to provide some comic relief to the list! ;)
>>>
>>>
>>> On Sun, Jun 1, 2014 at 11:01 PM, Apostolis Xekoukoulotakis <
>>> xekou...@gmail.com> wrote:
>>>
 That made my day. Not to worry thought unless you  start seeing the
 number 23 in your host ids.
  On Jun 2, 2014 12:40 AM, "Kevin Burton"  wrote:

> could be worse… it could be under caffeinated and say decafbad …
>
>
> On Sat, May 31, 2014 at 10:45 AM, Tim Dunphy 
> wrote:
>
>> I think the "deaf" thing is just the ending of the host ID in
>>> hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D
>>
>>
>> Hah.. yeah that thought did cross my mind.  :)
>>
>>
>>
>> On Sat, May 31, 2014 at 1:35 PM, DuyHai Doan 
>> wrote:
>>
>>> I think the "deaf" thing is just the ending of the host ID in
>>> hexadecimal. It's an extraordinary coincidence that it ends with DEAF :D
>>>
>>>
>>> On Sat, May 31, 2014 at 6:38 PM, Tim Dunphy 
>>> wrote:
>>>
 I didn't realize cassandra nodes could develop hearing problems. :)


 But I have a dead node in my cluster I would like to get rid of.

 [root@beta:~] #nodetool status
 Datacenter: datacenter1
 ===
 Status=Up/Down
 |/ State=Normal/Leaving/Joining/Moving
 --  Address Load   Tokens  Owns   Host ID
 Rack
 UN  10.10.1.94  199.6 KB   256 49.4%
  fd2f76ae-8dcf-4e93-a37f-bf1e9088696e  rack1
 DN  10.10.1.64  ?  256 50.6%
  f2a48fc7-a362-43f5-9061-4bb3739f*deaf * rack1

 I was just wondering what this could indicate and if that might
 mean that I will have some more trouble than I would be bargaining for 
 in
 getting rid of it.

 I've made a couple of attempts to get rid of this so far. I'm about
 to try again.

 Thanks
 Tim

 --
 GPG me!!

 gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B


>>>
>>
>>
>> --
>> GPG me!!
>>
>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>
>>
>
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> Skype: *burtonator*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> 
> War is peace. Freedom is slavery. Ignorance is strength. Corporations
> are people.
>
>
>>>
>>>
>>> --
>>> GPG me!!
>>>
>>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>>
>>>
>>
>>
>> --
>> *Paulo Motta*
>>
>> Chaordic | *Platform*
>> *www.chaordic.com.br *
>> +55 48 3232.3200
>>
>
>
>
> --
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>
>


-- 
David Daeschler