Return-Path: 
 <user-return-6278-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org>
Delivered-To: apmail-cassandra-user-archive@www.apache.org
Received: (qmail 15201 invoked from network); 1 Jun 2010 12:38:28 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 1 Jun 2010 12:38:28 -0000
Received: (qmail 62147 invoked by uid 500); 1 Jun 2010 12:38:26 -0000
Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org
Received: (qmail 62127 invoked by uid 500); 1 Jun 2010 12:38:26 -0000
Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@cassandra.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@cassandra.apache.org>
List-Post: <mailto:user@cassandra.apache.org>
List-Id: <user.cassandra.apache.org>
Reply-To: user@cassandra.apache.org
Delivered-To: mailing list user@cassandra.apache.org
Received: (qmail 62119 invoked by uid 99); 1 Jun 2010 12:38:26 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jun 2010 12:38:26 +0000
X-ASF-Spam-Status: No, hits=4.4 required=10.0
	tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of hive13@gmail.com designates
 209.85.212.172 as permitted sender)
Received: from [209.85.212.172] (HELO mail-px0-f172.google.com)
 (209.85.212.172)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jun 2010 12:38:20 +0000
Received: by pxi19 with SMTP id 19so2152772pxi.31
        for <user@cassandra.apache.org>; Tue, 01 Jun 2010 05:37:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:date:message-id
         :subject:from:to:content-type;
        bh=qXvUj8vI3LM9CO5XaZmSVnT1GuXxxPb2R6Jfx9ytBU0=;
        b=aSjTd4aJvFhwPWoQ3xuQwlpqASRXpv/QEIVArCQwGgLxWo8cuHbbbob0pCpuNryqYQ
         N21yDrhKbm+iQDA8gUsWATDUrHpx4t/At5FYDnicESoFZvl6GBPfgvAqzu707C3Ulq/K
         wJrgwZq791RMnwr0j96DE3phRix95yQwFd3Co=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=YDY4Ih+FuF1wrZBl/7L32YN4ZnNplsFkZSRf4uQjxYQVDWHSAxFbBMjTps8zQtO0GM
         hEaNl3oPBfOheSYzny5qB4A3uHwi8mt9CQrBD3lsI1IyV4I+s5Sgd+mOUdil1vHRe9la
         N0ZgeCkEpZKuHnUBJocJF8+gST6kft8atfuiY=
MIME-Version: 1.0
Received: by 10.114.186.35 with SMTP id j35mr4807466waf.13.1275395877406;
 Tue,
	01 Jun 2010 05:37:57 -0700 (PDT)
Received: by 10.114.36.5 with HTTP; Tue, 1 Jun 2010 05:37:57 -0700 (PDT)
Date: Tue, 1 Jun 2010 20:37:57 +0800
Message-ID: <AANLkTin7bsso3h5wicNl7Wv0UpPtUjIN0JgTFpftA0Oz@mail.gmail.com>
Subject: Skipping corrupted rows when doing compaction
From: hive13 Wong <hive13@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=001485e7c9503887f10487f73e06

--001485e7c9503887f10487f73e06
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Is there a way to skip corrupted rows when doing compaction?

We are currently deploying 2 nodes with replicationfactor=2 but one node
reports lots of exceptions like java.io.UTFDataFormatException: malformed
input around byte 72. My guess is that some of the data in the SSTable is
corrupted but not all because I can still read data out of the related CF
but for some keys.

It's OK for us to throw away a small portion of the data to get the nodes
working normal.

If there is no such way to skip corrupted rows can I just clean all the data
in the corrupted node and then add it back to the cluster?
Will it automatically migrating data from the other node?

Thanks.

Ivan

--001485e7c9503887f10487f73e06
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,=A0<div><br></div><div>Is there a way to skip corrupted rows when doing =
compaction?</div><div><br></div><div>We are currently deploying 2 nodes wit=
h replicationfactor=3D2 but one node reports lots of exceptions like java.i=
o.UTFDataFormatException: malformed input around byte 72. My guess is that =
some of the data in the SSTable is corrupted but not all because I can stil=
l read data out of the related CF but for some keys.</div>
<div><br></div><div>It&#39;s OK for us to throw away a small portion of the=
 data to get the nodes working normal.</div><div><br></div><div>If there is=
 no such way to skip corrupted rows can I just clean all the data in the co=
rrupted node and then add it back to the cluster?</div>
<div>Will it automatically migrating data from the other node?</div><div><b=
r></div><div>Thanks.</div><div><br></div><div>Ivan</div>

--001485e7c9503887f10487f73e06--