Re: system_auth replication strategy

> 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 i

Re: nodes are always out of sync

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 cas

Re: system_auth replication strategy

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

Re: nodes are always out of sync

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

Re: nodes are always out of sync

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

Re: nodes are always out of sync

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

Re: nodes are always out of sync

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? *.

Re: Can we get username and timestamp in cqlsh_history?

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

Re: nodes are always out of sync

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,

system_auth replication strategy

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.