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 ACB82200C34 for ; Mon, 27 Feb 2017 18:29:48 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id AB554160B60; Mon, 27 Feb 2017 17:29:48 +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 D1770160B5B for ; Mon, 27 Feb 2017 18:29:47 +0100 (CET) Received: (qmail 50691 invoked by uid 500); 27 Feb 2017 17:29:41 -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 50681 invoked by uid 99); 27 Feb 2017 17:29:41 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Feb 2017 17:29:41 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id EC5B1C1836 for ; Mon, 27 Feb 2017 17:29:40 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.18 X-Spam-Level: * X-Spam-Status: No, score=1.18 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id QlpseXammgqy for ; Mon, 27 Feb 2017 17:29:40 +0000 (UTC) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 8DED15F23A for ; Mon, 27 Feb 2017 17:29:39 +0000 (UTC) Received: by mail-lf0-f48.google.com with SMTP id k202so22627696lfe.1 for ; Mon, 27 Feb 2017 09:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :references:in-reply-to:to; bh=Dq62ofgOlWvKDnYjykaiSX8Gsno6q7gyWgOax8Si21U=; b=fYIZ2mfL2SHm8IC55SDaVNt36arKpk2Nmc7cEPx3ksatly0L/ZkxwyH9DtK+y4kDUc 9K204Yq8RN0rxBcJaHG3AcI/o0XQJBwdxtyqa6U2eqIEM50UuLs3zmcPeGOYOCPM+mtM fnH36V/Fx+DODI1L4nPkV1wJn97M51Vwu4qOIij14aJpOW20XWl2kqFXlpwSpWbCNZhs mVI8oYzLvEgK2CnpoJ+PKgIbClQZM0irR7Z0mIxkvdz0Z0mvYy2TtKl21h/cCEQ3pkdO Oj0bMSZvyaPSHuqr7Yh4gI9rz381W32MRbmVsIQnAOCw9G0M6OkKk0EuY2tgDj6dlwGl vFsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:references:in-reply-to:to; bh=Dq62ofgOlWvKDnYjykaiSX8Gsno6q7gyWgOax8Si21U=; b=PPxHUXqvoXXcSS5z7ST7EAjuHZLJfrcLVupd1YIkQCSdxClFltuzWfIIH7/cTYzm3Y UfgSssQMtGSp9Q9YHr1H2uXRPQzt+nXZc5P1bvi0YSm2W3Ecy8LvGBJUkcCJnexOZlqS oyErUA3o7lgyhZvEx2rfmZ+PeoiZpPk47oViyv4Mk3fKo+DnSkxCbXe9cd50Xzxdbeyx HZfR4fVpk15kTGv5dOZec2jORveIXY05P6ZzF0bsREo/ai5chn6Vn0TnX4s3U+zJjgdA /ocl3c5784TwqdryBVwXs4HbnKHX5jVp3GDbDJeKY9iJzlGN0RPBcCpRig82wm3uap7M rGWw== X-Gm-Message-State: AMke39ld5kZJFVMm5dnuUGSleEUQRT4/8OWW7BaHhfbUhJYuisb5x2nUqdmOXjPYbwc9YQ== X-Received: by 10.25.196.207 with SMTP id u198mr3278330lff.88.1488216577752; Mon, 27 Feb 2017 09:29:37 -0800 (PST) Received: from [10.0.0.4] (c-3ec5d954.05-143-73746f1.cust.bredbandsbolaget.se. [84.217.197.62]) by smtp.gmail.com with ESMTPSA id a16sm4076959lfk.64.2017.02.27.09.29.36 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Feb 2017 09:29:36 -0800 (PST) From: Oskar Kjellin Content-Type: multipart/alternative; boundary=Apple-Mail-7FC0D61F-01C6-4A9D-BF55-447739C80259 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: Is periodic manual repair necessary? Message-Id: Date: Mon, 27 Feb 2017 18:29:36 +0100 References: In-Reply-To: To: user@cassandra.apache.org X-Mailer: iPad Mail (13G36) archived-at: Mon, 27 Feb 2017 17:29:48 -0000 --Apple-Mail-7FC0D61F-01C6-4A9D-BF55-447739C80259 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Are you running multi dc? Skickat fr=C3=A5n min iPad > 27 feb. 2017 kl. 16:08 skrev Thakrar, Jayesh : >=20 > Suppose I have an application, where there are no deletes, only 5-10% of r= ows being occasionally updated (and that too only once) and a lot of reads. > =20 > Furthermore, I have replication =3D 3 and both read and write are configur= ed for local_quorum. > =20 > Occasionally, servers do go into maintenance. > =20 > I understand when the maintenance is longer than the period for hinted_han= doffs to be preserved, they are lost and servers may have stale data. > But I do expect it to be rectified on reads. If the stale data is not read= again, I don=E2=80=99t care for it to be corrected as then the data will be= automatically purged because of TTL. > =20 > In such a situation, do I need to have a periodic (weekly?) manual/batch r= ead_repair process? > =20 > Thanks, > Jayesh Thakrar --Apple-Mail-7FC0D61F-01C6-4A9D-BF55-447739C80259 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Are you running multi dc?

Skick= at fr=C3=A5n min iPad

27 feb. 2017 kl. 16:08 skrev Thakrar, Ja= yesh <jthakrar@conversant= media.com>:

Suppose I have an ap= plication, where there are no deletes, only 5-10% of rows being occasionally= updated (and that too only once) and a lot of reads.

 

Furthermore, I have r= eplication =3D 3 and both read and write are configured for local_quorum.

 

Occasionally, server= s do go into maintenance.

 

I understand when th= e maintenance is longer than the period for hinted_handoffs to be preserved,= they are lost and servers may have stale data.

But I do expect it t= o be rectified on reads. If the stale data is not read again, I don=E2=80=99= t care for it to be corrected as then the data will be automatically purged b= ecause of TTL.

 

In such a situation,= do I need to have a periodic (weekly?) manual/batch read_repair process?

 

Thanks,

Jayesh Thakrar<= /o:p>

= --Apple-Mail-7FC0D61F-01C6-4A9D-BF55-447739C80259--