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 965466E02 for ; Tue, 14 Jun 2011 07:21:50 +0000 (UTC) Received: (qmail 95974 invoked by uid 500); 14 Jun 2011 07:21:48 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 95772 invoked by uid 500); 14 Jun 2011 07:21:43 -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 95761 invoked by uid 99); 14 Jun 2011 07:21:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jun 2011 07:21:42 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tmarthinussen@gmail.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-ww0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jun 2011 07:21:35 +0000 Received: by wwa36 with SMTP id 36so4765213wwa.25 for ; Tue, 14 Jun 2011 00:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=rT+YH+OzGoFmxIYdYUP9JKvsBnpS8ykeD6XGO49ivYc=; b=Uqtb8YkCS4v8uDJ5aqBgGkdMwO9KCcheQPLqJ4+vif6afXBECEUKopmESRKMQHoxbz irWDFwc0WpqkvJPHsZWLpsOMKBUOgv4gG4S34E8DYUJ6Lxvx/KANvDUj5Js0Uv9frWyN 0R567vlRlN+34iYn476ktGFaj33TnwmJ/ZbVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CfBEAEVhwW5H7TftEat5leaB6cpuOeMjIDS5nZzfqO3eZWPDbtB7z6pdfSiCNLM8xQ 3tpodnZjCBTtAtZvUUczQEWbDFSd58dNDb/+hwzDQFcU5ynEmKhvSjfAllkFY5FVVPXR godX7Qw1h8mv7Hr2FgZCknOoEpeabA0T9YKZw= MIME-Version: 1.0 Received: by 10.217.4.9 with SMTP id t9mr2791376wes.20.1308036074943; Tue, 14 Jun 2011 00:21:14 -0700 (PDT) Received: by 10.216.20.73 with HTTP; Tue, 14 Jun 2011 00:21:14 -0700 (PDT) Date: Tue, 14 Jun 2011 16:21:14 +0900 Message-ID: Subject: repair and amount of transfers From: Terje Marthinussen To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=20cf30207b2899b2d604a5a6e150 X-Virus-Checked: Checked by ClamAV on apache.org --20cf30207b2899b2d604a5a6e150 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have been testing repairs a bit in different ways on 0.8.0 and I am curious on what to really expect in terms of data transferred. I would expect my data to be fairly consistent in this case from the start. More than a billion supercolumns, but there was no errors in feed and we have seen minimal amounts of read repair going on while doing a complete scan of the data for consistency checking. As such, I would also expect repair to finish reasonably fast. On some nodes, it finishes in a couple of hours, but other nodes it is taking more than 12 hours and I see some 65GB of data streamed to the node which surprises me as I am pretty sure that it is not that out of sync. Not sure how much the merkle trees are actually reducing what needs to be streamed though. What should we expect to see if this works? Regards, Terje --20cf30207b2899b2d604a5a6e150 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=A0

I have been testing repairs a bit in different wa= ys on 0.8.0 and I am curious on what to really expect in terms of data tran= sferred.

I would expect my data to be fairly consi= stent in this case from the start. More than a billion supercolumns, but th= ere was no errors in feed and we have seen minimal amounts of read repair g= oing on while doing a complete scan of the data for consistency checking. A= s such, I would also expect repair to finish reasonably fast.

On some nodes, it finishes in a couple of hours, but ot= her nodes it is taking more than 12 hours and I see some 65GB of data strea= med to the node which surprises me as I am pretty sure that it is not that = out of sync.

Not sure how much the merkle trees are actually reducin= g what needs to be streamed though.

What should we= expect to see if this works?

Regards,
Terje=A0
--20cf30207b2899b2d604a5a6e150--