Hi Fabrice and Yuri,
Thanks for your questions and answers.
>From my point of view, it is now a common architecture to have 1 or more DC
for on line queries, and 1 DC for stats.
It is also very common (and recommended ?) to specify -pr option for
anti-entropy repair operations.
In my case, I have a very large table, and I don't want to compute
statistics from the data stored in that table.
In that case, a convenient and obvious solution is to create a specific
keyspace with RF={"s1":"3","stats":"0","b1":"3"}, as explained by Fabrice.
It means that I can use -pr option for anti-entropy repair operations for
keyspaces having RF > 0 in DC stats. However, I have to execute a full
repair (without -pr) for keyspace(s) having RF = 0 in DC stats.
If my understanding is correct, I guess it should very useful to explain
this point a little bit more in the documentation :
http://www.datastax.com/documentation/cassandra/1.2/cassandra/tools/toolsNodetool_r.html
http://www.datastax.com/documentation/cassandra/1.2/cassandra/operations/ops_repair_nodes_c.html?scroll=concept_ds_ebj_d3q_gk
https://wiki.apache.org/cassandra/Operations#Frequency_of_nodetool_repair
Something like
/!\ If you use NTS and set RF=0 for 1 (or more) keyspace(s) in 1 (or more)
DCs, -pr option for anti-entropy repair operations will not repair all the
ranges of tokens for those keyspaces. If what you want a safe anti entropy
operation, you need to repair without -pr option.
I have read that 2.0 will come with a lot of exciting improvements for
repair operations. Is it still a concern with 2.0 ? with 2.1 ?
Regards.
Jean Armel
2014-02-27 20:06 GMT+01:00 Yuki Morishita <mor.y...@gmail.com>:
> Yes.
>
> On Thu, Feb 27, 2014 at 12:49 PM, Fabrice Facorat
> <fabrice.faco...@gmail.com> wrote:
> > So if I understand well from CASSANDRA-5424 and CASSANDRA-5608, as
> > stats dc doesn't own data, repair -pr will not repair the data. Only a
> > full repair will do it.
> >
> > Once we will add a RF to stats DC, repair -pr will work again. That's
> correct ?
> >
> > 2014-02-27 19:15 GMT+01:00 Yuki Morishita <mor.y...@gmail.com>:
> >> Yes, it is expected behavior since
> >> 1.2.5(https://issues.apache.org/jira/browse/CASSANDRA-5424).
> >> Since you set foobar not to replicate to stats dc, primary range of
> >> foobar keyspace for nodes in stats is empty.
> >>
> >>
> >> On Thu, Feb 27, 2014 at 10:16 AM, Fabrice Facorat
> >> <fabrice.faco...@gmail.com> wrote:
> >>> Hi,
> >>>
> >>> we have a cluster with 3 DC, and for one DC ( stats ), RF=0 for a
> >>> keyspace using NetworkTopologyStrategy.
> >>>
> >>> cqlsh> SELECT * FROM system.schema_keyspaces WHERE
> keyspace_name='foobar';
> >>>
> >>> keyspace_name | durable_writes | strategy_class
> >>> | strategy_options
> >>>
> ----------------+----------------+------------------------------------------------------+---------------------------------
> >>> foobar | True |
> >>> org.apache.cassandra.locator.NetworkTopologyStrategy |
> >>> {"s1":"3","stats":"0","b1":"3"}
> >>>
> >>>
> >>> When doing a "nodetool repair -pr foobar" on a node in DC stats, we
> >>> notice that the repair doesn't do anything : it just skips the
> >>> keyspace.
> >>>
> >>> Is this normal behavior ? I guess that some keys belonging to DC
> >>> stats's primary range token should have been repaired in the two
> >>> others DC ? Am I wrong ?
> >>>
> >>> We are using cassandra 1.2.13, with 256 vnodes and Murmur3Partitioner
> >>>
> >>>
> >>> --
> >>> Close the World, Open the Net
> >>> http://www.linux-wizard.net
> >>
> >>
> >>
> >> --
> >> Yuki Morishita
> >> t:yukim (http://twitter.com/yukim)
> >
> >
> >
> > --
> > Close the World, Open the Net
> > http://www.linux-wizard.net
>
>
>
> --
> Yuki Morishita
> t:yukim (http://twitter.com/yukim)
>
