Re: system_auth replication strategy

[Jeff Jirsa]

> You should use a network topology strategy with high RF in each DC 


There's some debate here - some blogs/speakers will say to put a replica on 
each instance, but that falls down above a few dozen instances. Imagine if you 
have (for example) 200 instances per DC, auth logins for super users is 101 
replicas serving the read - that's a really slow login that's likely to fail 
(think about thread pools on the coordinator doing the read response handling, 
it's an ugly ugly mess).

Normal logins do use LOCAL_ONE though so if there are lots of replicas, auth 
will be faster - so use 5-10 replicas per DC, and crank up the caching timeouts 
as well

Re: nodes are always out of sync

[Roland Otta]

thank you both chris and benjamin for taking time to clarify that.


On Sat, 2017-04-01 at 21:17 +0200, benjamin roth wrote:
Tl;Dr: there are race conditions in a repair and it is not trivial to fix them. 
So we rather stay with these race conditions. Actually they don't really hurt. 
The worst case is that ranges are repaired that don't really need a repair.

Am 01.04.2017 21:14 schrieb "Chris Lohfink" 
mailto:clohfin...@gmail.com>>:
Repairs do not have an ability to instantly build a perfect view of its data 
between your 3 nodes at an exact time. When a piece of data is written there is 
a delay between when they applied between the nodes, even if its just 500ms. So 
if a request to read the data and build the merkle tree of the data occurs and 
it finishes on node1 at 12:01 while node2 finishes at 12:02 the 1 minute or so 
delta (even if a few seconds, or if using snapshot repairs) between the 
partition/range hashes in the merkle tree can be different. On a moving data 
set its almost impossible to have the clusters perfectly in sync for a repair. 
I wouldnt worry about that log message. If you are worried about consistency 
between your read/writes use each or local quorum for both.

Chris

On Thu, Mar 30, 2017 at 1:22 AM, Roland Otta 
mailto:roland.o...@willhaben.at>> wrote:
hi,

we see the following behaviour in our environment:

cluster consists of 6 nodes (cassandra version 3.0.7). keyspace has a
replication factor 3.
clients are writing data to the keyspace with consistency one.

we are doing parallel, incremental repairs with cassandra reaper.

even if a repair just finished and we are starting a new one
immediately, we can see the following entries in our logs:

INFO  [RepairJobTask:1] 2017-03-30 10:14:00,782 SyncTask.java:73 -
[repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints 
/192.168.0.188
and /192.168.0.191 have 1 range(s) out of sync for 
ad_event_history
INFO  [RepairJobTask:2] 2017-03-30 10:14:00,782 SyncTask.java:73 -
[repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints 
/192.168.0.188
and /192.168.0.189 have 1 range(s) out of sync for 
ad_event_history
INFO  [RepairJobTask:4] 2017-03-30 10:14:00,782 SyncTask.java:73 -
[repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints 
/192.168.0.189
and /192.168.0.191 have 1 range(s) out of sync for 
ad_event_history
INFO  [RepairJobTask:2] 2017-03-30 10:14:03,997 SyncTask.java:73 -
[repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints 
/192.168.0.26
and /192.168.0.189 have 2 range(s) out of sync for 
ad_event_history
INFO  [RepairJobTask:1] 2017-03-30 10:14:03,997 SyncTask.java:73 -
[repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints 
/192.168.0.26
and /192.168.0.191 have 2 range(s) out of sync for 
ad_event_history
INFO  [RepairJobTask:4] 2017-03-30 10:14:03,997 SyncTask.java:73 -
[repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints 
/192.168.0.189
and /192.168.0.191 have 2 range(s) out of sync for 
ad_event_history
INFO  [RepairJobTask:1] 2017-03-30 10:14:05,375 SyncTask.java:73 -
[repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints 
/192.168.0.189
and /192.168.0.191 have 1 range(s) out of sync for 
ad_event_history
INFO  [RepairJobTask:2] 2017-03-30 10:14:05,375 SyncTask.java:73 -
[repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints 
/192.168.0.189
and /192.168.0.190 have 1 range(s) out of sync for 
ad_event_history
INFO  [RepairJobTask:4] 2017-03-30 10:14:05,375 SyncTask.java:73 -
[repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints 
/192.168.0.190
and /192.168.0.191 have 1 range(s) out of sync for 
ad_event_history

we cant see any hints on the systems ... so we thought everything is
running smoothly with the writes.

do we have to be concerned about the nodes always being out of sync or
is this a normal behaviour in a write intensive table (as the tables
will never be 100% in sync for the latest inserts)?

bg,
roland

Re: system_auth replication strategy

[Chris Lohfink]

You should use a network topology strategy with high RF in each DC or something 
like the everywhere strategy.

You should never really use SimpleStrategy, especially if you have multiple DCs 
and are using LOCAL or EACH consistencies. Its more for test and dev setups 
then a prod environment.

The problem is that it DOES ensure a LOCAL consistency level will be targeted 
in the same DC as the coordinator but it doesn ensure there will be data on 
each DC. This means that if there are no nodes in your DC that are a replica of 
the data you can get an unavailable exception even if 100% of your nodes are up 
and healthy.

So if you have 10 nodes, 5 per dc, 2 dcs and a RF of 3 with simple strategy

DC1
[0] [10] [30] [40] [45]

DC2
[1] [11] [15] [21] [41]

Especially if you have random token assignment like above. A partition with a 
token of 11 can end up on

DC1
[ ] [ ] [ ] [ ] [ ]

DC2
[ ] [*] [*] [*] [ ]

In which case an insert or read to a node on DC1 with LOCAL_ONE or LOCAL_QUORUM 
will result in an unavailable exception.

Chris

> On Apr 1, 2017, at 10:51 AM, Vlad  wrote:
> 
> Hi,
> 
> what is the suitable replication strategy for system_auth keyspace?
> As I understand factor should be equal to total nodes number, so can we use 
> SimpleStrategy? Does it ensure that queries with LOCAL_ONE consistency level 
> will be targeted to local DC (or the same node)?
> 
> Thanks.

Re: nodes are always out of sync

[benjamin roth]

Tl;Dr: there are race conditions in a repair and it is not trivial to fix
them. So we rather stay with these race conditions. Actually they don't
really hurt. The worst case is that ranges are repaired that don't really
need a repair.

Am 01.04.2017 21:14 schrieb "Chris Lohfink" :

> Repairs do not have an ability to instantly build a perfect view of its
> data between your 3 nodes at an exact time. When a piece of data is written
> there is a delay between when they applied between the nodes, even if its
> just 500ms. So if a request to read the data and build the merkle tree of
> the data occurs and it finishes on node1 at 12:01 while node2 finishes at
> 12:02 the 1 minute or so delta (even if a few seconds, or if using snapshot
> repairs) between the partition/range hashes in the merkle tree can be
> different. On a moving data set its almost impossible to have the clusters
> perfectly in sync for a repair. I wouldnt worry about that log message. If
> you are worried about consistency between your read/writes use each or
> local quorum for both.
>
> Chris
>
> On Thu, Mar 30, 2017 at 1:22 AM, Roland Otta 
> wrote:
>
>> hi,
>>
>> we see the following behaviour in our environment:
>>
>> cluster consists of 6 nodes (cassandra version 3.0.7). keyspace has a
>> replication factor 3.
>> clients are writing data to the keyspace with consistency one.
>>
>> we are doing parallel, incremental repairs with cassandra reaper.
>>
>> even if a repair just finished and we are starting a new one
>> immediately, we can see the following entries in our logs:
>>
>> INFO  [RepairJobTask:1] 2017-03-30 10:14:00,782 SyncTask.java:73 -
>> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.188
>> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:2] 2017-03-30 10:14:00,782 SyncTask.java:73 -
>> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.188
>> and /192.168.0.189 have 1 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:4] 2017-03-30 10:14:00,782 SyncTask.java:73 -
>> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
>> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:2] 2017-03-30 10:14:03,997 SyncTask.java:73 -
>> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.26
>> and /192.168.0.189 have 2 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:1] 2017-03-30 10:14:03,997 SyncTask.java:73 -
>> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.26
>> and /192.168.0.191 have 2 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:4] 2017-03-30 10:14:03,997 SyncTask.java:73 -
>> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
>> and /192.168.0.191 have 2 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:1] 2017-03-30 10:14:05,375 SyncTask.java:73 -
>> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
>> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:2] 2017-03-30 10:14:05,375 SyncTask.java:73 -
>> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
>> and /192.168.0.190 have 1 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:4] 2017-03-30 10:14:05,375 SyncTask.java:73 -
>> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.190
>> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
>>
>> we cant see any hints on the systems ... so we thought everything is
>> running smoothly with the writes.
>>
>> do we have to be concerned about the nodes always being out of sync or
>> is this a normal behaviour in a write intensive table (as the tables
>> will never be 100% in sync for the latest inserts)?
>>
>> bg,
>> roland
>>
>>
>>
>

Re: nodes are always out of sync

[benjamin roth]

I think your way to communicate needs work. No one forces you to answer on
questions.

Am 01.04.2017 21:09 schrieb "daemeon reiydelle" :

> What you are doing is correctly going to result in this, IF there is
> substantial backlog/network/disk or whatever pressure.
>
> What do you think will happen when you write with a replication factor
> greater than consistency level of write? Perhaps your mental model of how
> C* works needs work?
>
>
> *...*
>
>
>
> *Daemeon C.M. ReiydelleUSA (+1) 415.501.0198 <(415)%20501-0198>London
> (+44) (0) 20 8144 9872 <+44%2020%208144%209872>*
>
> On Sat, Apr 1, 2017 at 11:09 AM, Vladimir Yudovin 
> wrote:
>
>> Hi,
>>
>> did you try to read data with consistency ALL immediately after write
>> with consistency ONE? Does it succeed?
>>
>> Best regards, Vladimir Yudovin,
>> *Winguzone  - Cloud Cassandra Hosting*
>>
>>
>>  On Thu, 30 Mar 2017 04:22:28 -0400 *Roland Otta
>> >* wrote 
>>
>> hi,
>>
>> we see the following behaviour in our environment:
>>
>> cluster consists of 6 nodes (cassandra version 3.0.7). keyspace has a
>> replication factor 3.
>> clients are writing data to the keyspace with consistency one.
>>
>> we are doing parallel, incremental repairs with cassandra reaper.
>>
>> even if a repair just finished and we are starting a new one
>> immediately, we can see the following entries in our logs:
>>
>> INFO  [RepairJobTask:1] 2017-03-30 10:14:00,782 SyncTask.java:73 -
>> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.188
>> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:2] 2017-03-30 10:14:00,782 SyncTask.java:73 -
>> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.188
>> and /192.168.0.189 have 1 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:4] 2017-03-30 10:14:00,782 SyncTask.java:73 -
>> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
>> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:2] 2017-03-30 10:14:03,997 SyncTask.java:73 -
>> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.26
>> and /192.168.0.189 have 2 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:1] 2017-03-30 10:14:03,997 SyncTask.java:73 -
>> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.26
>> and /192.168.0.191 have 2 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:4] 2017-03-30 10:14:03,997 SyncTask.java:73 -
>> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
>> and /192.168.0.191 have 2 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:1] 2017-03-30 10:14:05,375 SyncTask.java:73 -
>> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
>> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:2] 2017-03-30 10:14:05,375 SyncTask.java:73 -
>> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
>> and /192.168.0.190 have 1 range(s) out of sync for ad_event_history
>> INFO  [RepairJobTask:4] 2017-03-30 10:14:05,375 SyncTask.java:73 -
>> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.190
>> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
>>
>> we cant see any hints on the systems ... so we thought everything is
>> running smoothly with the writes.
>>
>> do we have to be concerned about the nodes always being out of sync or
>> is this a normal behaviour in a write intensive table (as the tables
>> will never be 100% in sync for the latest inserts)?
>>
>> bg,
>> roland
>>
>>
>>
>>
>

Re: nodes are always out of sync

[Chris Lohfink]

Repairs do not have an ability to instantly build a perfect view of its
data between your 3 nodes at an exact time. When a piece of data is written
there is a delay between when they applied between the nodes, even if its
just 500ms. So if a request to read the data and build the merkle tree of
the data occurs and it finishes on node1 at 12:01 while node2 finishes at
12:02 the 1 minute or so delta (even if a few seconds, or if using snapshot
repairs) between the partition/range hashes in the merkle tree can be
different. On a moving data set its almost impossible to have the clusters
perfectly in sync for a repair. I wouldnt worry about that log message. If
you are worried about consistency between your read/writes use each or
local quorum for both.

Chris

On Thu, Mar 30, 2017 at 1:22 AM, Roland Otta 
wrote:

> hi,
>
> we see the following behaviour in our environment:
>
> cluster consists of 6 nodes (cassandra version 3.0.7). keyspace has a
> replication factor 3.
> clients are writing data to the keyspace with consistency one.
>
> we are doing parallel, incremental repairs with cassandra reaper.
>
> even if a repair just finished and we are starting a new one
> immediately, we can see the following entries in our logs:
>
> INFO  [RepairJobTask:1] 2017-03-30 10:14:00,782 SyncTask.java:73 -
> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.188
> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:2] 2017-03-30 10:14:00,782 SyncTask.java:73 -
> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.188
> and /192.168.0.189 have 1 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:4] 2017-03-30 10:14:00,782 SyncTask.java:73 -
> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:2] 2017-03-30 10:14:03,997 SyncTask.java:73 -
> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.26
> and /192.168.0.189 have 2 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:1] 2017-03-30 10:14:03,997 SyncTask.java:73 -
> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.26
> and /192.168.0.191 have 2 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:4] 2017-03-30 10:14:03,997 SyncTask.java:73 -
> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
> and /192.168.0.191 have 2 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:1] 2017-03-30 10:14:05,375 SyncTask.java:73 -
> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:2] 2017-03-30 10:14:05,375 SyncTask.java:73 -
> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
> and /192.168.0.190 have 1 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:4] 2017-03-30 10:14:05,375 SyncTask.java:73 -
> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.190
> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
>
> we cant see any hints on the systems ... so we thought everything is
> running smoothly with the writes.
>
> do we have to be concerned about the nodes always being out of sync or
> is this a normal behaviour in a write intensive table (as the tables
> will never be 100% in sync for the latest inserts)?
>
> bg,
> roland
>
>
>

Re: nodes are always out of sync

[daemeon reiydelle]

What you are doing is correctly going to result in this, IF there is
substantial backlog/network/disk or whatever pressure.

What do you think will happen when you write with a replication factor
greater than consistency level of write? Perhaps your mental model of how
C* works needs work?


*...*



*Daemeon C.M. ReiydelleUSA (+1) 415.501.0198London (+44) (0) 20 8144 9872*

On Sat, Apr 1, 2017 at 11:09 AM, Vladimir Yudovin 
wrote:

> Hi,
>
> did you try to read data with consistency ALL immediately after write with
> consistency ONE? Does it succeed?
>
> Best regards, Vladimir Yudovin,
> *Winguzone  - Cloud Cassandra Hosting*
>
>
>  On Thu, 30 Mar 2017 04:22:28 -0400 *Roland Otta
> >* wrote 
>
> hi,
>
> we see the following behaviour in our environment:
>
> cluster consists of 6 nodes (cassandra version 3.0.7). keyspace has a
> replication factor 3.
> clients are writing data to the keyspace with consistency one.
>
> we are doing parallel, incremental repairs with cassandra reaper.
>
> even if a repair just finished and we are starting a new one
> immediately, we can see the following entries in our logs:
>
> INFO  [RepairJobTask:1] 2017-03-30 10:14:00,782 SyncTask.java:73 -
> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.188
> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:2] 2017-03-30 10:14:00,782 SyncTask.java:73 -
> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.188
> and /192.168.0.189 have 1 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:4] 2017-03-30 10:14:00,782 SyncTask.java:73 -
> [repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:2] 2017-03-30 10:14:03,997 SyncTask.java:73 -
> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.26
> and /192.168.0.189 have 2 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:1] 2017-03-30 10:14:03,997 SyncTask.java:73 -
> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.26
> and /192.168.0.191 have 2 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:4] 2017-03-30 10:14:03,997 SyncTask.java:73 -
> [repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
> and /192.168.0.191 have 2 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:1] 2017-03-30 10:14:05,375 SyncTask.java:73 -
> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:2] 2017-03-30 10:14:05,375 SyncTask.java:73 -
> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189
> and /192.168.0.190 have 1 range(s) out of sync for ad_event_history
> INFO  [RepairJobTask:4] 2017-03-30 10:14:05,375 SyncTask.java:73 -
> [repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.190
> and /192.168.0.191 have 1 range(s) out of sync for ad_event_history
>
> we cant see any hints on the systems ... so we thought everything is
> running smoothly with the writes.
>
> do we have to be concerned about the nodes always being out of sync or
> is this a normal behaviour in a write intensive table (as the tables
> will never be 100% in sync for the latest inserts)?
>
> bg,
> roland
>
>
>
>

Re: Can we get username and timestamp in cqlsh_history?

[Vladimir Yudovin]

Hi anuja,



I don't thinks there is a way to do this without creating custom Cassandra 
build.

There is mutations logs and somewhere on list was thread about parsing them, 
but I'm not sure it's what you need.



Best regards, Vladimir Yudovin, 

Winguzone - Cloud Cassandra Hosting






 On Wed, 29 Mar 2017 07:37:15 -0400 anuja jain  
wrote 




Hi,

I have a cassandra cluster having a lot of keyspaces and users. I want to get 
the history of cql commands along with the username and the time at which the 
command is run.

Also if we are running some commands from GUI tools like Devcenter,dbeaver, can 
we log those commands too? If yes, how?



Thanks,

Anuja

Re: nodes are always out of sync

[Vladimir Yudovin]

Hi,



did you try to read data with consistency ALL immediately after write with 
consistency ONE? Does it succeed?



Best regards, Vladimir Yudovin, 

Winguzone - Cloud Cassandra Hosting






 On Thu, 30 Mar 2017 04:22:28 -0400 Roland Otta 
 wrote 




hi, 

 

we see the following behaviour in our environment: 

 

cluster consists of 6 nodes (cassandra version 3.0.7). keyspace has a 

replication factor 3. 

clients are writing data to the keyspace with consistency one. 

 

we are doing parallel, incremental repairs with cassandra reaper. 

 

even if a repair just finished and we are starting a new one 

immediately, we can see the following entries in our logs: 

 

INFO  [RepairJobTask:1] 2017-03-30 10:14:00,782 SyncTask.java:73 - 

[repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.188 

and /192.168.0.191 have 1 range(s) out of sync for ad_event_history 

INFO  [RepairJobTask:2] 2017-03-30 10:14:00,782 SyncTask.java:73 - 

[repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.188 

and /192.168.0.189 have 1 range(s) out of sync for ad_event_history 

INFO  [RepairJobTask:4] 2017-03-30 10:14:00,782 SyncTask.java:73 - 

[repair #d0f651f6-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189 

and /192.168.0.191 have 1 range(s) out of sync for ad_event_history 

INFO  [RepairJobTask:2] 2017-03-30 10:14:03,997 SyncTask.java:73 - 

[repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.26 

and /192.168.0.189 have 2 range(s) out of sync for ad_event_history 

INFO  [RepairJobTask:1] 2017-03-30 10:14:03,997 SyncTask.java:73 - 

[repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.26 

and /192.168.0.191 have 2 range(s) out of sync for ad_event_history 

INFO  [RepairJobTask:4] 2017-03-30 10:14:03,997 SyncTask.java:73 - 

[repair #d0fa70a1-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189 

and /192.168.0.191 have 2 range(s) out of sync for ad_event_history 

INFO  [RepairJobTask:1] 2017-03-30 10:14:05,375 SyncTask.java:73 - 

[repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189 

and /192.168.0.191 have 1 range(s) out of sync for ad_event_history 

INFO  [RepairJobTask:2] 2017-03-30 10:14:05,375 SyncTask.java:73 - 

[repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.189 

and /192.168.0.190 have 1 range(s) out of sync for ad_event_history 

INFO  [RepairJobTask:4] 2017-03-30 10:14:05,375 SyncTask.java:73 - 

[repair #d0fbd033-1520-11e7-a443-d9f5b942818e] Endpoints /192.168.0.190 

and /192.168.0.191 have 1 range(s) out of sync for ad_event_history 

 

we cant see any hints on the systems ... so we thought everything is 

running smoothly with the writes. 

 

do we have to be concerned about the nodes always being out of sync or 

is this a normal behaviour in a write intensive table (as the tables 

will never be 100% in sync for the latest inserts)? 

 

bg, 

roland 

 

 

system_auth replication strategy

[Vlad]

Hi,
what is the suitable replication strategy for system_auth keyspace?As I 
understand factor should be equal to total nodes number, so can we use 
SimpleStrategy? Does it ensure that queries with LOCAL_ONE consistency level 
will be targeted to local DC (or the same node)?
Thanks.