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 643CA1731C for ; Fri, 31 Oct 2014 12:08:35 +0000 (UTC) Received: (qmail 60769 invoked by uid 500); 31 Oct 2014 12:08:32 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 60728 invoked by uid 500); 31 Oct 2014 12:08:32 -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 60718 invoked by uid 99); 31 Oct 2014 12:08:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Oct 2014 12:08:32 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of samvenkatram@outlook.com designates 65.54.190.147 as permitted sender) Received: from [65.54.190.147] (HELO BAY004-OMC3S9.hotmail.com) (65.54.190.147) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Oct 2014 12:08:28 +0000 Received: from BAY169-W115 ([65.54.190.188]) by BAY004-OMC3S9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 31 Oct 2014 05:07:46 -0700 X-TMN: [wN+I2euT3C+LHIFP9cTigaD0DmkMofav51C824JG4rs=] X-Originating-Email: [samvenkatram@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_58977ec0-ee4b-4053-b2ab-3c9226bf9ccc_" From: venkat sam To: "user@cassandra.apache.org" Subject: RE: Commissioning failure Date: Fri, 31 Oct 2014 17:37:46 +0530 Importance: Normal In-Reply-To: References: ,,,,, MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2014 12:07:46.0534 (UTC) FILETIME=[48655060:01CFF503] X-Virus-Checked: Checked by ClamAV on apache.org --_58977ec0-ee4b-4053-b2ab-3c9226bf9ccc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes Hannu=2C Initially for one month we didn't face any problem. But once t= ables got bigger we are getting the disk space issues.=20 Can I change the compaction strategy. Will changing compaction strategy hav= e an impact on data consistency? Will it cause corruption of SSTable . -Venkat Date: Fri=2C 31 Oct 2014 13:43:11 +0200 Subject: Re: Commissioning failure From: hkroger@gmail.com To: user@cassandra.apache.org Hi=2C I think only LevelledCompactionStrategy makes sense on JBOD because that ca= n distribute data more evenly. Although I don't know what is the exact stra= tegy where each compaction strategy will store sstables. If you use SizeTie= redCompactionStrategy you might run into problems when sstables get big eno= ugh. I think the theoretical maximum size for an STCS table is the half of = one disk size. Because you might be able to run major compaction in that si= tuation. I wouldn't actually use JBOD with anything else than LCS. With smaller tab= les it doesn't really matter that much but with big tables you would run in= to problem with anything else. Please correct me if I am wrong. Hannu 2014-10-31 12:16 GMT+02:00 venkat sam : =0A= =0A= =0A= Thanks Rob. We have disabled firewalls between the nodes and yet getting the same error= . I have one more doubt. In our cluster we configured size tiered compaction = strategy on JBOD and we are facing issues like uneven distribution of data.= Is it possible to change compaction strategy of tables with data? Which co= mpaction strategy will be ideal for data directories in JBOD ? Date: Thu=2C 30 Oct 2014 11:16:59 -0700 Subject: Re: Commissioning failure From: rcoli@eventbrite.com To: user@cassandra.apache.org On Wed=2C Oct 29=2C 2014 at 10:39 PM=2C Aravindan T w= rote: What could be the reasons for the stream error other than SSTABLE corruptio= n? There's tons of reasons streams fail. Cassandra team is aware of how painfu= l it makes things=2C so they are working on them. Be sure that a firewall is not dropping long running connections. =3DRobhttp://twitter.com/rcolidba =0A= = --_58977ec0-ee4b-4053-b2ab-3c9226bf9ccc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes Hannu=2C Initially for o= ne month we didn't face any problem. But once tables got bigger we are gett= ing the disk space issues.

Can I change the compaction strategy. Wi= ll changing compaction strategy have an impact on data consistency? Will it= cause corruption of SSTable .

-Venkat
Date: Fri=2C 31 Oct 2014 13:43:11 +0200
Subject: Re: Commissioning fa= ilure
From: hkroger@gmail.com
To: user@cassandra.apache.org

Hi=2C

I think only LevelledCompactionStra= tegy makes sense on JBOD because that can distribute data more evenly. Alth= ough I don't know what is the exact strategy where each compaction strategy= will store sstables. If you use SizeTieredCompactionStrategy you might run= into problems when sstables get big enough. I think the theoretical maximu= m size for an STCS table is the half of one disk size. Because you might be= able to run major compaction in that situation.

&= nbsp=3BI wouldn't actually use JBOD with anything else than LCS. With small= er tables it doesn't really matter that much but with big tables you would = run into problem with anything else.

Please correc= t me if I am wrong.

Hannu


2014-10-31 12:1= 6 GMT+02:00 venkat sam <=3Bsamvenkatram@outlook.com>=3B= :
=0A= =0A= =0A=
Thanks Rob.

We have disabled firewalls between= the nodes and yet getting the same error.

I have one more doubt. In= our cluster we configured size tiered compaction strategy on JBOD and we a= re facing issues like uneven distribution of data. Is it possible to change= compaction strategy of tables with data? Which compaction strategy will be= ideal for data directories in JBOD ?

=0A=

= --_58977ec0-ee4b-4053-b2ab-3c9226bf9ccc_--