cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <aa...@thelastpickle.com>
Subject Re: Frequency of Flushing in 1.0
Date Mon, 27 Feb 2012 20:47:37 GMT
> Isn't decomission meant to do the same thing as disablethrift and gossip?

decommission removes a node entirely from the cluster, including streaming it's data to other
nodes. 

disablethrift and disablegossip just stop it from responding to clients and other nodes. 

Cheers

-----------------
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com

On 27/02/2012, at 2:26 PM, Mohit Anchlia wrote:

> 
> 
> On Sun, Feb 26, 2012 at 12:18 PM, aaron morton <aaron@thelastpickle.com> wrote:
> Nathan Milford has a post about taking a node down 
> 
> http://blog.milford.io/2011/11/rolling-upgrades-for-cassandra/
> 
> The only thing I would do differently would be turn off thrift first.
> 
> Cheers
>  
> Isn't decomission meant to do the same thing as disablethrift and gossip?
> 
> 
> -----------------
> Aaron Morton
> Freelance Developer
> @aaronmorton
> http://www.thelastpickle.com
> 
> On 27/02/2012, at 4:35 AM, Edward Capriolo wrote:
> 
>> If you are doing a planned maintenance you can flush first as well
>> ensuring the that the commit logs will not be as large.
>> 
>> On Sun, Feb 26, 2012 at 10:09 AM, Radim Kolar <hsn@sendmail.cz> wrote:
>>>> if a node goes down, it will take longer for commitlog replay.
>>> 
>>> commit log replay time is insignificant. most time during node startup is
>>> wasted on index sampling. Index sampling here runs for about 15 minutes.
> 
> 


Mime
View raw message