Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id D9E9A200B34 for ; Fri, 27 May 2016 17:44:14 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id D8EAD160A37; Fri, 27 May 2016 15:44:14 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 2D217160A12 for ; Fri, 27 May 2016 17:44:14 +0200 (CEST) Received: (qmail 37502 invoked by uid 500); 27 May 2016 15:44:13 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 37464 invoked by uid 99); 27 May 2016 15:44:13 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 May 2016 15:44:13 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 14C062C1F60 for ; Fri, 27 May 2016 15:44:13 +0000 (UTC) Date: Fri, 27 May 2016 15:44:13 +0000 (UTC) From: "Aleksey Yeschenko (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CASSANDRA-11899) Please create a swarm decommission mode MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 27 May 2016 15:44:15 -0000 [ https://issues.apache.org/jira/browse/CASSANDRA-11899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-11899: ------------------------------------------ Summary: Please create a swarm decommission mode (was: Please create a swarm decommission node) > Please create a swarm decommission mode > --------------------------------------- > > Key: CASSANDRA-11899 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11899 > Project: Cassandra > Issue Type: Improvement > Reporter: Mark Danko > Priority: Minor > > Right now when I remove a node that is up I understand 2 choices. > nodetool decommission: The current hosts starts sending out data as the only source. This takes a long time. The one node you want to remove becomes a huge bottle neck (even worse if you want to remove it because it is under performing). > cassandra stop, then nodetool removenode: This lets all other nodes that share the keyranges be sources. This runs about 8-16X faster than decommission on my system, but this requires me to run with reduced redundancy when it happens. > I think it would be really cool if there was a way to decommission a node that is up, and leverage the power of other data sources. > Request : When you decommission a node all other nodes that share a keyrange should also help in being sources for the data that needs to be copied. Maybe, with options for how far to get the data/balance of load: old behavior, same rack, same dc, other dc (or some default scheme based on latency between nodes/racks/dcs). -- This message was sent by Atlassian JIRA (v6.3.4#6332)