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 B275310DEF for ; Tue, 3 Jun 2014 17:52:43 +0000 (UTC) Received: (qmail 47811 invoked by uid 500); 3 Jun 2014 17:52:41 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 47775 invoked by uid 500); 3 Jun 2014 17:52: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 47767 invoked by uid 99); 3 Jun 2014 17:52:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jun 2014 17:52:41 +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 (nike.apache.org: domain of rcoli@eventbrite.com designates 209.85.128.182 as permitted sender) Received: from [209.85.128.182] (HELO mail-ve0-f182.google.com) (209.85.128.182) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jun 2014 17:52:37 +0000 Received: by mail-ve0-f182.google.com with SMTP id sa20so7352879veb.41 for ; Tue, 03 Jun 2014 10:52:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=pve/Cd0e+XGhfOtfg3sqaOirKHYsAN3vYl00l1U7fXY=; b=YCbgHphDdvu4jSjwC6c8IAt3EesSXSW7kckRtAXQKKh5wr3RQAMZkPQNLl59RsxmZT 91KTPyz/urTlCg9zoJAiSsRJjoYoa5LA7dDBY6a+I645jyJjGTIHXesoyWeIRBX/vIxx 6traOrq91hd4X8o8AytdAyfCOgMQkLZJRRJCX9NDV+NacFynUricKW2f7CHVrZnuFxP8 Px12tlLROtqRzYjk3X91ZKxKyZ9E02OLdJrS0tr36TmgH3BNCZWgftdzdQFRr7gXUAKv Ik2jnxXpwcYtHIkn1urSkEY+LWSG47O5s5CbzIO08ddWgKDUXA/IcB04snMo6BigK0mJ gsFw== X-Gm-Message-State: ALoCoQm0x78+aZ35RSLLaPn2kpNIaNDm3+cP6EDaI3uacV6whYyFL6N8xBTl7+k6VC/+DDXzhat5 MIME-Version: 1.0 X-Received: by 10.220.196.82 with SMTP id ef18mr2551928vcb.78.1401817933536; Tue, 03 Jun 2014 10:52:13 -0700 (PDT) Received: by 10.220.155.11 with HTTP; Tue, 3 Jun 2014 10:52:13 -0700 (PDT) In-Reply-To: References: <5387B31E.7030206@gmail.com> Date: Tue, 3 Jun 2014 10:52:13 -0700 Message-ID: Subject: Re: Multi-DC Environment Question From: Robert Coli To: "user@cassandra.apache.org" Content-Type: multipart/alternative; boundary=001a1133db9cf7f79804faf22b7c X-Virus-Checked: Checked by ClamAV on apache.org --001a1133db9cf7f79804faf22b7c Content-Type: text/plain; charset=UTF-8 On Fri, May 30, 2014 at 4:08 AM, Vasileios Vlachos < vasileiosvlachos@gmail.com> wrote: > Basically you sort of confirmed that if down_time > max_hint_window_in_ms > the only way to bring DC1 up-to-date is anti-entropy repair. > Also, read repair does not help either as we assumed that down_time > > max_hint_window_in_ms. Please correct me if I am wrong. > My understanding is that if you : 1) set read repair chance to 100% 2) read all keys in the keyspace with a client You would accomplish the same increase in consistency as you would by running repair. In cases where this may matter, and your system can handle delivering the hints, increasing the already-increased-from-old-default-of-1-hour current default of 3 hours to 6 or more hours gives operators more time to work in the case of partition or failure. Note that hints are only an optimization, only repair (and read repair at 100%, I think..) assert any guarantee of consistency. =Rob --001a1133db9cf7f79804faf22b7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, May 30, 2014 at 4:08 AM, Vasileios Vlachos <vasileiosvlachos@= gmail.com> wrote:
Basically you sort of = confirmed that if down_time > max_hint_window_in_ms the only way to brin= g DC1 up-to-date is anti-entropy repair.=C2=A0

Also, read repair does not help either as we assumed that dow= n_time > max_hint_window_in_ms. Please correct me if I am wrong.

My understanding is that if you :

1) set read repair chance to 100%
2) read = all keys in the keyspace with a client

You would a= ccomplish the same increase in consistency as you would by running repair.<= /div>

In cases where this may matter, and your system can han= dle delivering the hints, increasing the already-increased-from-old-default= -of-1-hour current default of 3 hours to 6 or more hours gives operators mo= re time to work in the case of partition or failure. Note that hints are on= ly an optimization, only repair (and read repair at 100%, I think..) assert= any guarantee of consistency.

=3DRob

--001a1133db9cf7f79804faf22b7c--