Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # user >> decommissioning node woes


Copy link to this message
-
Re: decommissioning node woes
I like to keep that rather high.  If I am decommissioning nodes, I generally
want them out of the cluster NOW.

That is probably a personality defect on my part.

On Fri, Mar 18, 2011 at 9:59 AM, Michael Segel <[EMAIL PROTECTED]>wrote:

> Once you see those blocks successfully replicated... you can take down the
> next.
>
> Is it clean? No, not really.
> Is it dangerous? No, not really.
> Do I recommend it? No, but its a quick and dirty way of doing things...
>
> Or you can up your dfs.balance.bandwidthPerSecIn the configuration files.
> The default is pretty low.
>
> The downside is that you have to bounce the cloud to get this value
> updated, and it could have a negative impact on performance if set too high.
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB