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 8CCDD9F97 for ; Thu, 19 Apr 2012 17:19:12 +0000 (UTC) Received: (qmail 58133 invoked by uid 500); 19 Apr 2012 17:19:10 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 58098 invoked by uid 500); 19 Apr 2012 17:19:10 -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 58084 invoked by uid 99); 19 Apr 2012 17:19:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Apr 2012 17:19:10 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [213.199.154.139] (HELO db3outboundpool.messaging.microsoft.com) (213.199.154.139) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Apr 2012 17:18:59 +0000 Received: from mail106-db3-R.bigfish.com (10.3.81.231) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 17:18:38 +0000 Received: from mail106-db3 (localhost [127.0.0.1]) by mail106-db3-R.bigfish.com (Postfix) with ESMTP id 6EFA03008B3 for ; Thu, 19 Apr 2012 17:18:37 +0000 (UTC) X-SpamScore: 0 X-BigFish: VPS0(zzc85fhzz1202hzz8275bh8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.56.252.133;KIP:(null);UIP:(null);IPV:NLI;H:DBXPRD0310HT003.eurprd03.prod.outlook.com;RD:none;EFVD:NLI Received: from mail106-db3 (localhost.localdomain [127.0.0.1]) by mail106-db3 (MessageSwitch) id 1334855915277982_21799; Thu, 19 Apr 2012 17:18:35 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.254]) by mail106-db3.bigfish.com (Postfix) with ESMTP id 3F9EF140057 for ; Thu, 19 Apr 2012 17:18:35 +0000 (UTC) Received: from DBXPRD0310HT003.eurprd03.prod.outlook.com (157.56.252.133) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 17:18:34 +0000 Received: from DBXPRD0310MB384.eurprd03.prod.outlook.com ([169.254.4.135]) by DBXPRD0310HT003.eurprd03.prod.outlook.com ([10.255.65.166]) with mapi id 14.16.0143.004; Thu, 19 Apr 2012 17:18:34 +0000 From: Richard Lowe To: "user@cassandra.apache.org" Subject: RE: default required in cassandra-topology.properties? Thread-Topic: default required in cassandra-topology.properties? Thread-Index: AQHNHkfENjHoG36/SE6gEwDP7Nk5aZaiYOLQ Date: Thu, 19 Apr 2012 17:18:33 +0000 Message-ID: <9FC471D82FE4194FA2B6A1403B475C9B08EE573D@DBXPRD0310MB384.eurprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.181.69.227] Content-Type: multipart/alternative; boundary="_000_9FC471D82FE4194FA2B6A1403B475C9B08EE573DDBXPRD0310MB384_" MIME-Version: 1.0 X-OriginatorOrg: arkivum.com --_000_9FC471D82FE4194FA2B6A1403B475C9B08EE573DDBXPRD0310MB384_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes it is possible. Put the following as the last line of your topology fil= e: default=3Dunknown:unknown So long as you don't have any DC or rack with this name your local node wil= l not be able to address any nodes that aren't explicitly given in its topo= logy file. However bear in mind that, whilst Cassandra won't try to use replication fa= ctor to store to these 'unknown' nodes, their token may mean that the 'natu= ral' home for a row is on a node that is not addressable. This can create h= oles in your dataset and create situations where data can 'disappear' becau= se the bloom filter says the data is on a particular node (due to its token= ) but the coordinator can't contact that node to get at the data. Careful use of replication factor and NetworkTopologyStrategy can help with= this, but you should make sure that a node really doesn't need to contact = the unknown nodes before marking them as such. Richard From: Bill Au [mailto:bill.w.au@gmail.com] Sent: 19 April 2012 17:16 To: user@cassandra.apache.org Subject: default required in cassandra-topology.properties? All the examples of cassandra-topology.properties that I have seen have a d= efault entry assigning unknown nodes to a specific data center and rack. I= s it possible to have Cassandra ignore unknown nodes for the purpose of rep= lication? Bill --_000_9FC471D82FE4194FA2B6A1403B475C9B08EE573DDBXPRD0310MB384_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes it is possible. Put t= he following as the last line of your topology file:

 <= /p>

default=3Dunknown:unknown=

 <= /p>

So long as you don’= t have any DC or rack with this name your local node will not be able to ad= dress any nodes that aren’t explicitly given in its topology file.

 <= /p>

However bear in mind that= , whilst Cassandra won’t try to use replication factor to store to th= ese ‘unknown’ nodes, their token may mean that the ‘natur= al’ home for a row is on a node that is not addressable. This can create holes in y= our dataset and create situations where data can ‘disappear’ be= cause the bloom filter says the data is on a particular node (due to its to= ken) but the coordinator can’t contact that node to get at the data.

 <= /p>

Careful use of replicatio= n factor and NetworkTopologyStrategy can help with this, but you should mak= e sure that a node really doesn’t need to contact the unknown nodes before marking them as such.

 <= /p>

 <= /p>

Richard=

 <= /p>

 <= /p>

From: Bill Au [mailto:bill.w.au@gmail.com]
Sent: 19 April 2012 17:16
To: user@cassandra.apache.org
Subject: default required in cassandra-topology.properties?

 

All the examples of cassandra-topology.properties th= at I have seen have a default entry assigning unknown nodes to a specific d= ata center and rack.  Is it possible to have Cassandra ignore unknown = nodes for the purpose of replication?

Bill

--_000_9FC471D82FE4194FA2B6A1403B475C9B08EE573DDBXPRD0310MB384_--