Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E6BF410024 for ; Sat, 31 Aug 2013 13:18:04 +0000 (UTC) Received: (qmail 20750 invoked by uid 500); 31 Aug 2013 13:18:02 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 20457 invoked by uid 500); 31 Aug 2013 13:17:59 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 20449 invoked by uid 99); 31 Aug 2013 13:17:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 31 Aug 2013 13:17:58 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rodrigofelixdealmeida@gmail.com designates 209.85.160.41 as permitted sender) Received: from [209.85.160.41] (HELO mail-pb0-f41.google.com) (209.85.160.41) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 31 Aug 2013 13:17:53 +0000 Received: by mail-pb0-f41.google.com with SMTP id rp2so2976816pbb.28 for ; Sat, 31 Aug 2013 06:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=zNA3wljZszObzKKmgWO8bJw/IWo5xqYq2a5PgbstFEM=; b=cxBi4ylwtZZVLOXuY/v6Tb7GUkFyIoH7BWb5xeUrXgWucUK3mfBMbtm+iWA9owXwt6 WiDhnU/fqCHVvlR6lWSAvvdQjzAF4OU6KtaE9IDvlqmjRC2zN0GVWOI1Wfz4Xi0kblPl oVcXLH1piAdhBVQvsS7l8fWr8P0h9BlNWWnxuSXckSMa+nK+r+VvG+YS+arhcX56u45P ESDCk7MV5ei0UniZ20Gx9R8B3PZJ5+CxsxRgvQut7Bb6Jz2K0nEqJIhr89PW4rqYGtUe FCjD1RPgKXziNc3TH443vmK/Vg9Q6qPTlTYidQE+jCMizjemIABHC36zmR85L+efZFGB mm4A== X-Received: by 10.66.235.106 with SMTP id ul10mr16041137pac.19.1377955053319; Sat, 31 Aug 2013 06:17:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.168.49 with HTTP; Sat, 31 Aug 2013 06:17:13 -0700 (PDT) In-Reply-To: References: From: Rodrigo Felix Date: Sat, 31 Aug 2013 10:17:13 -0300 Message-ID: Subject: Re: Decommission faster than bootstrap To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=047d7b111d19783c9804e53e2919 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b111d19783c9804e53e2919 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Do you think that not to run cleanup operation after bootstrapping a node can affect the bootstrap time of a subsequent node? I mean, keys not removed can somehow affect a bootstrap operation? Thanks. Att. *Rodrigo Felix de Almeida* LSBD - Universidade Federal do Cear=E1 Project Manager MBA, CSM, CSPO, SCJP On Mon, Aug 26, 2013 at 10:39 PM, Rodrigo Felix < rodrigofelixdealmeida@gmail.com> wrote: > Boris, > > We are not using secondary index. We tested both on version 1.1.5 and > 1.1.12 and had similar results. > > Does anybody know what are the steps in details to bootstrap and to > decommission a node? > I'd like to figure out which step is creating this difference. For me, th= e > time should be similar, assuming that data streaming is the most > time-consuming task and that the amount of data streamed is similar. > > Thanks in advance for all comments. > > Att. > > *Rodrigo Felix de Almeida* > LSBD - Universidade Federal do Cear=E1 > Project Manager > MBA, CSM, CSPO, SCJP > > > On Thu, Aug 22, 2013 at 11:48 PM, Boris Yen wrote: > >> We are using 1.0. Our observation is that if you are using secondary >> index, building secondary index after streaming is time consuming. And t= he >> bootstrap needs to wait for the process of building secondary indexes to >> complete. >> >> I am not sure if this also applies to 1.1/1.2. You could set the log >> level to debug to observe what is really going on when a node is >> bootstraping. >> >> Boris >> >> >> On Mon, Aug 19, 2013 at 6:19 AM, Rodrigo Felix < >> rodrigofelixdealmeida@gmail.com> wrote: >> >>> Hi, >>> >>> I've noticed that, at least in my enviroment (Cassandra 1.1.12 >>> running on Amazon EC2), decommission operations take about 3-4 minutes >>> while bootstrap can take more than 20 minutes. >>> What is the reason to have this time difference? For both operations= , >>> what it is time-consuming the data streaming from (or to) other node, r= ight? >>> Thanks in advance. >>> >>> Att. >>> >>> *Rodrigo Felix de Almeida* >>> LSBD - Universidade Federal do Cear=E1 >>> Project Manager >>> MBA, CSM, CSPO, SCJP >>> >> >> > --047d7b111d19783c9804e53e2919 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Do you think that not to run cleanup operation after boots= trapping a node can affect the bootstrap time of a subsequent node?
I m= ean, keys not removed can somehow affect a bootstrap operation?
Thanks.

Att.
Rodrigo Felix de Almeida
LSBD - Universidade Federal do Cea= r=E1
Project Manager
MBA, CSM, CSPO, SCJP


On Mon, Aug 26, 2013 at 10:39 PM, Rodrig= o Felix <rodrigofelixdealmeida@gmail.com> wrot= e:
Boris,

= =A0 =A0We are not using secondary index. We tested both on version 1.1.5 an= d 1.1.12 and had similar results.

Does anybody know what are the steps in details to boot= strap and to decommission a node?
I'd like to figure out which step is creating this difference. For= me, the time should be similar, assuming that data streaming is the most t= ime-consuming task and that the amount of data streamed is similar.

Thanks in advance for all comments.

Att.

= Rodrigo Felix de Almeida
LSBD - Universidade Federal do Cear=E1
P= roject Manager
MBA, CSM, CSPO, SCJP


On Thu, Aug= 22, 2013 at 11:48 PM, Boris Yen <yulinyen@gmail.com> wrote= :
We are using 1.0. Our observation is that if you are using= secondary index, building secondary index after streaming is time consumin= g. And the bootstrap needs to wait for the process of building secondary in= dexes to complete.

I am not sure if this also applies to 1.1/1.2. You could set= the log level to debug to observe what is really going on when a node is b= ootstraping.

Boris


On Mon, Aug 19, 2013 at 6:19 AM, Rodrigo= Felix <rodrigofelixdealmeida@gmail.com> wrote= :
Hi,

=A0 = =A0I've noticed that, at least in my enviroment (Cassandra 1.1.12 runni= ng on Amazon EC2), decommission operations take about 3-4 minutes while boo= tstrap can take more than 20 minutes.
=A0 =A0What is the reason to have this time difference? For both opera= tions, what it is time-consuming the data streaming from (or to) other node= , right?
=A0 =A0Thanks in advance.

Att.

Rodrigo Felix de Almeida
LSBD - Universidade Federal do Cear= =E1
Project Manager
MBA, CSM, CSPO, SCJP



--047d7b111d19783c9804e53e2919--