You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Anthony Ikeda <an...@gmail.com> on 2011/09/14 23:43:49 UTC
Configuring the keyspace correctly - NTS
Okay, in a previous post, it was stated that I could use a
NetworkTopologyStrategy in a singel data centre by setting up my keyspace
with:
create keyspace KeyspaceDEV
with placement_strategy =
'org.apache.cassandra.locator.NetworkTopologyStrategy'
and strategy_options=[{datacenter1:3}];
Whereby my understanding is that:
[{datacenter1:3}]
represents:
- 1 Datacentre
- 3 nodes in that datacentre
My infrastructure team were recommended to instead of use "datacenter1" to
use the second value in the IP address:
x.130.x.x
[{130:3}]
However, when trying to access the keyspace the following error was return:
"May not be enough replicas present to handle consistency level"
When I rebuilt the keyspace using the "datacenter1" semantic, it worked
fine.
My guess is that there is some correlation between the "130" value and
either the rpc_address or listen_address. Am I correct in thinking this?
I don't have access to the se configurations so I'm just going out on a whim
here trying to figure out why using the "130" form the IP address would
cause the error.
Anthony
Re: Configuring the keyspace correctly - NTS
Posted by Anthony Ikeda <an...@gmail.com>.
Aaron, when using the RackInferringSnitch, is the octet correlated from the
rpc_address or listen_address?
I just noticed that when I tried to configure this locally on my laptop I
had to "0" (127.0.0.1) instead of "160" (192.160.202.235)
Anthony
On Wed, Sep 14, 2011 at 3:15 PM, aaron morton <aa...@thelastpickle.com>wrote:
> The strategy_options for NTS accept the data centre name and the rf,
> [{<dc_name> : <dc_rf>}]
>
> Where the DC name comes from the snitch, so…
>
> SimpleSnitch (gotta love this guy, in there day in day out putting in the
> hard yards) puts all the nodes in "datacenter1" which is why thats in the
> defaults.
>
> RackInferringSnitch (or the "Hollywood Snitch" as I call it) puts the them
> in a DC named after the second octet of the IP. So 130 in your case.
>
> PropertyFileSnitch does whats in the cassandra-topology.properties file.
> EC2Snitch uses the EC2 Region. Brisk snitch does it's thing.
>
> If you want to use 130 you should be using the RackInferringSnitch, if you
> want to use human names use either the SimpleSnitch or the
> PropertyFileSnitch. Property File Snitch has a default catch all DC, see the
> cassandra-topology.properties file.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 15/09/2011, at 9:43 AM, Anthony Ikeda wrote:
>
> Okay, in a previous post, it was stated that I could use a
> NetworkTopologyStrategy in a singel data centre by setting up my keyspace
> with:
>
> create keyspace KeyspaceDEV
>
> with placement_strategy =
> 'org.apache.cassandra.locator.NetworkTopologyStrategy'
>
> and strategy_options=[{datacenter1:3}];
>
>
> Whereby my understanding is that:
>
> [{datacenter1:3}]
>
> represents:
>
>
> - 1 Datacentre
> - 3 nodes in that datacentre
>
> My infrastructure team were recommended to instead of use "datacenter1" to
> use the second value in the IP address:
> x.130.x.x
>
> [{130:3}]
>
> However, when trying to access the keyspace the following error was return:
>
> "May not be enough replicas present to handle consistency level"
> When I rebuilt the keyspace using the "datacenter1" semantic, it worked
> fine.
>
> My guess is that there is some correlation between the "130" value and
> either the rpc_address or listen_address. Am I correct in thinking this?
>
> I don't have access to the se configurations so I'm just going out on a
> whim here trying to figure out why using the "130" form the IP address would
> cause the error.
>
> Anthony
>
>
>
>
>
Re: Configuring the keyspace correctly - NTS
Posted by Anthony Ikeda <an...@gmail.com>.
Great that makes perfect sense - I apologise for not getting this right it
seems I'm doing someone elses job here.
Anthony
On Wed, Sep 14, 2011 at 3:15 PM, aaron morton <aa...@thelastpickle.com>wrote:
> The strategy_options for NTS accept the data centre name and the rf,
> [{<dc_name> : <dc_rf>}]
>
> Where the DC name comes from the snitch, so…
>
> SimpleSnitch (gotta love this guy, in there day in day out putting in the
> hard yards) puts all the nodes in "datacenter1" which is why thats in the
> defaults.
>
> RackInferringSnitch (or the "Hollywood Snitch" as I call it) puts the them
> in a DC named after the second octet of the IP. So 130 in your case.
>
> PropertyFileSnitch does whats in the cassandra-topology.properties file.
> EC2Snitch uses the EC2 Region. Brisk snitch does it's thing.
>
> If you want to use 130 you should be using the RackInferringSnitch, if you
> want to use human names use either the SimpleSnitch or the
> PropertyFileSnitch. Property File Snitch has a default catch all DC, see the
> cassandra-topology.properties file.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 15/09/2011, at 9:43 AM, Anthony Ikeda wrote:
>
> Okay, in a previous post, it was stated that I could use a
> NetworkTopologyStrategy in a singel data centre by setting up my keyspace
> with:
>
> create keyspace KeyspaceDEV
>
> with placement_strategy =
> 'org.apache.cassandra.locator.NetworkTopologyStrategy'
>
> and strategy_options=[{datacenter1:3}];
>
>
> Whereby my understanding is that:
>
> [{datacenter1:3}]
>
> represents:
>
>
> - 1 Datacentre
> - 3 nodes in that datacentre
>
> My infrastructure team were recommended to instead of use "datacenter1" to
> use the second value in the IP address:
> x.130.x.x
>
> [{130:3}]
>
> However, when trying to access the keyspace the following error was return:
>
> "May not be enough replicas present to handle consistency level"
> When I rebuilt the keyspace using the "datacenter1" semantic, it worked
> fine.
>
> My guess is that there is some correlation between the "130" value and
> either the rpc_address or listen_address. Am I correct in thinking this?
>
> I don't have access to the se configurations so I'm just going out on a
> whim here trying to figure out why using the "130" form the IP address would
> cause the error.
>
> Anthony
>
>
>
>
>
Re: Configuring the keyspace correctly - NTS
Posted by aaron morton <aa...@thelastpickle.com>.
The strategy_options for NTS accept the data centre name and the rf, [{<dc_name> : <dc_rf>}]
Where the DC name comes from the snitch, so…
SimpleSnitch (gotta love this guy, in there day in day out putting in the hard yards) puts all the nodes in "datacenter1" which is why thats in the defaults.
RackInferringSnitch (or the "Hollywood Snitch" as I call it) puts the them in a DC named after the second octet of the IP. So 130 in your case.
PropertyFileSnitch does whats in the cassandra-topology.properties file. EC2Snitch uses the EC2 Region. Brisk snitch does it's thing.
If you want to use 130 you should be using the RackInferringSnitch, if you want to use human names use either the SimpleSnitch or the PropertyFileSnitch. Property File Snitch has a default catch all DC, see the cassandra-topology.properties file.
Cheers
-----------------
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 15/09/2011, at 9:43 AM, Anthony Ikeda wrote:
> Okay, in a previous post, it was stated that I could use a NetworkTopologyStrategy in a singel data centre by setting up my keyspace with:
>
> create keyspace KeyspaceDEV
>
> with placement_strategy = 'org.apache.cassandra.locator.NetworkTopologyStrategy'
>
> and strategy_options=[{datacenter1:3}];
>
>
> Whereby my understanding is that:
>
> [{datacenter1:3}]
>
> represents:
>
>
> 1 Datacentre
> 3 nodes in that datacentre
> My infrastructure team were recommended to instead of use "datacenter1" to use the second value in the IP address:
> x.130.x.x
>
> [{130:3}]
>
> However, when trying to access the keyspace the following error was return:
> "May not be enough replicas present to handle consistency level"
>
> When I rebuilt the keyspace using the "datacenter1" semantic, it worked fine.
>
> My guess is that there is some correlation between the "130" value and either the rpc_address or listen_address. Am I correct in thinking this?
>
> I don't have access to the se configurations so I'm just going out on a whim here trying to figure out why using the "130" form the IP address would cause the error.
>
> Anthony
>
>
>