Re: Trying to understand QUORUM and Strategies
Note that this is an implementation detail, not something that inherently can't work with other strategies. LOCAL_QUORUM and EACH_QUORUM are logically equivalent to QUORUM when there is a single datacenter. We tried briefly to add support for non-NTS strategies in https://issues.apache.org/jira/browse/CASSANDRA-2516, but reverted it in https://issues.apache.org/jira/browse/CASSANDRA-2627. On Fri, Sep 2, 2011 at 12:53 PM, Anthony Ikeda wrote: > Okay, great I just wanted to confirm that LOCAL_QUORUM will not work with > SimpleStrategy. There was somewhat of a debate amongst my devs that said it > should work. > Anthon > > On Fri, Sep 2, 2011 at 9:55 AM, Evgeniy Ryabitskiy > wrote: >> >> So. >> You have created keyspace with SimpleStrategy. >> If you want to use LOCAL_QUORUM, you should create keyspace (or change >> existing) with NetworkTopologyStrategy. >> >> I have provided CLI examples on how to do it. If you are creating keyspace >> from Hector, you have to do same via Java API. >> >> Evgeny. >> >> > > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: Trying to understand QUORUM and Strategies
Okay, great I just wanted to confirm that LOCAL_QUORUM will not work with SimpleStrategy. There was somewhat of a debate amongst my devs that said it should work. Anthon On Fri, Sep 2, 2011 at 9:55 AM, Evgeniy Ryabitskiy < evgeniy.ryabits...@wikimart.ru> wrote: > So. > You have created keyspace with SimpleStrategy. > If you want to use *LOCAL_QUORUM, *you should create keyspace (or change > existing) with NetworkTopologyStrategy. > > I have provided CLI examples on how to do it. If you are creating keyspace > from Hector, you have to do same via Java API. > > Evgeny. > > >
Re: Trying to understand QUORUM and Strategies
So. You have created keyspace with SimpleStrategy. If you want to use *LOCAL_QUORUM, *you should create keyspace (or change existing) with NetworkTopologyStrategy. I have provided CLI examples on how to do it. If you are creating keyspace from Hector, you have to do same via Java API. Evgeny.
Re: Trying to understand QUORUM and Strategies
Thanks Evneniy,
We encountered this exception with the following settings:
Caused by: InvalidRequestException(why:consistency level LOCAL_QUORUM not
compatible with replication strategy (org.apache.cassandra.locator
.SimpleStrategy))
at
org.apache.cassandra.thrift.Cassandra$batch_mutate_result.read(Cassandra.java:19045)
at
org.apache.cassandra.thrift.Cassandra$Client.recv_batch_mutate(Cassandra.java:1035)
at
org.apache.cassandra.thrift.Cassandra$Client.batch_mutate(Cassandra.java:1009)
at
me.prettyprint.cassandra.service.KeyspaceServiceImpl$1.execute(KeyspaceServiceImpl.java:95)
at
me.prettyprint.cassandra.service.KeyspaceServiceImpl$1.execute(KeyspaceServiceImpl.java:90)
at
me.prettyprint.cassandra.service.Operation.executeAndSetResult(Operation.java:101)
at
me.prettyprint.cassandra.connection.HConnectionManager.operateWithFailover(HConnectionManager.java:232)
at
me.prettyprint.cassandra.service.KeyspaceServiceImpl.operateWithFailover(KeyspaceServiceImpl.java:131)
at
me.prettyprint.cassandra.service.KeyspaceServiceImpl.batchMutate(KeyspaceServiceImpl.java:102)
at
me.prettyprint.cassandra.service.KeyspaceServiceImpl.batchMutate(KeyspaceServiceImpl.java:108)
at
me.prettyprint.cassandra.model.MutatorImpl$3.doInKeyspace(MutatorImpl.java:222)
at
me.prettyprint.cassandra.model.MutatorImpl$3.doInKeyspace(MutatorImpl.java:219)
at
me.prettyprint.cassandra.model.KeyspaceOperationCallback.doInKeyspaceAndMeasure(KeyspaceOperationCallback.java:20)
at
me.prettyprint.cassandra.model.ExecutingKeyspace.doExecute(ExecutingKeyspace.java:85)
at
me.prettyprint.cassandra.model.MutatorImpl.execute(MutatorImpl.java:219)
Which is why I raised this email originally. It is probable that we have not
configured the system correctly, I just need to find out what it is I'm
missing.
Anthony
On Wed, Aug 31, 2011 at 2:59 PM, Evgeniy Ryabitskiy <
evgeniy.ryabits...@wikimart.ru> wrote:
> Hi
> Actually you can use LOCAL_QUORUM and EACH_QUORUM policy everywhere on
> DEV/QA/Prod.
> Even it would be better for integration tests to use same Consistency level
> as on production.
>
> For production with multiple DC you usually need to chouse between 2 common
> solutions: Geographical Distribution or Disaster Recovery.
> See: http://www.datastax.com/docs/0.8/operations/datacenter
>
> LOCAL_QUORUM and EACH_QUORUM for DEV/QA/Prod by examples:
>
> create keyspace KeyspaceDEV
> with placement_strategy =
> 'org.apache.cassandra.locator.NetworkTopologyStrategy'
> and strategy_options=[{*datacenter1*:1}];
>
> create keyspace KeyspaceQA
> with placement_strategy =
> 'org.apache.cassandra.locator.NetworkTopologyStrategy'
> and strategy_options=[{*datacenter1*:2}];
>
> create keyspace KeyspaceProd
> with placement_strategy =
> 'org.apache.cassandra.locator.NetworkTopologyStrategy'
> and strategy_options=[{*datacenter1*:3, datacenter2:3}];
>
>
> Be careful(!!!), usually default name of DC in new cluster is *datacenter1
> *. But cassandra-cli use default name *DC1*. (some small mismatch/bug
> maybe).
>
> Evgeny.
>
Re: Trying to understand QUORUM and Strategies
Hi
Actually you can use LOCAL_QUORUM and EACH_QUORUM policy everywhere on
DEV/QA/Prod.
Even it would be better for integration tests to use same Consistency level
as on production.
For production with multiple DC you usually need to chouse between 2 common
solutions: Geographical Distribution or Disaster Recovery.
See: http://www.datastax.com/docs/0.8/operations/datacenter
LOCAL_QUORUM and EACH_QUORUM for DEV/QA/Prod by examples:
create keyspace KeyspaceDEV
with placement_strategy =
'org.apache.cassandra.locator.NetworkTopologyStrategy'
and strategy_options=[{*datacenter1*:1}];
create keyspace KeyspaceQA
with placement_strategy =
'org.apache.cassandra.locator.NetworkTopologyStrategy'
and strategy_options=[{*datacenter1*:2}];
create keyspace KeyspaceProd
with placement_strategy =
'org.apache.cassandra.locator.NetworkTopologyStrategy'
and strategy_options=[{*datacenter1*:3, datacenter2:3}];
Be careful(!!!), usually default name of DC in new cluster is *datacenter1*.
But cassandra-cli use default name *DC1*. (some small mismatch/bug maybe).
Evgeny.
Trying to understand QUORUM and Strategies
Okay, we are looking at setting up a production environment which means getting our quorum settings and strategies correct. However, we need to really understand the approach taken to get this right. So far we have been working with co-located nodes and our prod environment is going to be distributed across 2 DCs. Our setup: Dev = 2 nodes, SimpleStrategy, RF=1 QA = 3 nodes, SimpleStrategy, RF=2 Prod = 2 DC's (3 nodes each), NetworkTopologyStrategy, RF=3 For the Dev and QA environment we have been using ConsistencyPolicy of ONE for reads and the default for writes For Prod I'm guessing we will be using a ConsistencyPolicy of LOCAL_QUORUM for both reads and writes. Correct me if I'm wrong but as I understand it: The Dev and QA environment can only use ConsistencyLevel of ONE or QUORUM. LOCAL_QUORUM cannot be used - well we've seen an exception stating LOCAL_QUORUM cannot be used with SimpleStrategy. The Prod environment should be able to use all ConsistencyPolicy's, however, we would have: Reads: LOCAL_QUORUM Writes: LOCAL_QUORUM - Is having LOCAL_QUORUM for reads going to affect us if we need to rely on the other DC as failover? - i.e. if we lose 2 nodes in DC1, will we still be able to read from DC2? - Would we need to ensure that any snitches are configured for the prod environment? - Is there anything else that I may be overlooking aside from these configuration values? Anthony
