Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 77F81C85E for ; Mon, 3 Jun 2013 16:09:23 +0000 (UTC) Received: (qmail 14451 invoked by uid 500); 3 Jun 2013 16:09:23 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 14425 invoked by uid 500); 3 Jun 2013 16:09:23 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 14414 invoked by uid 99); 3 Jun 2013 16:09:23 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Jun 2013 16:09:23 +0000 Date: Mon, 3 Jun 2013 16:09:23 +0000 (UTC) From: "Jonathan Ellis (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CASSANDRA-5608) "Primary range" repair still isn't quite NTS-aware MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5608: -------------------------------------- Description: Consider the case of a four node cluster, with nodes A and C in DC1, and nodes B and D in DC2. TokenMetadata will break this into ranges of (A-B], (B-C], (C-D], (D-A]. If we have a single copy of a keyspace stored in DC1 only (none in DC2), then the current code correctly calculates that node A is responsible for ranges (C-D], (D-A]. But, if we add a copy in DC2, then we only calculate (D-A] as primary range. This is a bug; we should not care what copies are in other datacenters, when computing what to repair in the local one. was: Consider the case of a four node cluster, with nodes A and C in DC1, and nodes B and D in DC2. TokenMetadata will break this into ranges of (A-B], (B-C], (C-D], (D-A]. If we have a single copy of a keyspace stored in DC1 only (none in DC2), then the current code correctly calculates that node A is responsible for ranges (C-D], (D-A]. But, if we add a copy in DC1, then we only calculate (D-A] as primary range. This is a bug; we should not care what copies are in other datacenters, when computing what to repair in the local one. > "Primary range" repair still isn't quite NTS-aware > -------------------------------------------------- > > Key: CASSANDRA-5608 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5608 > Project: Cassandra > Issue Type: Bug > Components: Tools > Affects Versions: 1.2.5 > Reporter: Jonathan Ellis > Assignee: Jonathan Ellis > Fix For: 1.2.6 > > > Consider the case of a four node cluster, with nodes A and C in DC1, and nodes B and D in DC2. TokenMetadata will break this into ranges of (A-B], (B-C], (C-D], (D-A]. > If we have a single copy of a keyspace stored in DC1 only (none in DC2), then the current code correctly calculates that node A is responsible for ranges (C-D], (D-A]. > But, if we add a copy in DC2, then we only calculate (D-A] as primary range. This is a bug; we should not care what copies are in other datacenters, when computing what to repair in the local one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira