Right, could be similar issue, same type of fix though. -----Original Message----- From: Jon Haddad [mailto:j...@jonhaddad.com] Sent: Thursday, April 04, 2019 9:52 AM To: user@cassandra.apache.org Subject: Re: Assassinate fails
System != system_auth. On Thu, Apr 4, 2019 at 9:43 AM Kenneth Brotman <kenbrot...@yahoo.com.invalid> wrote: > > From Mastering Cassandra: > > > Forcing read repairs at consistency – ALL > > The type of repair isn't really part of the Apache Cassandra repair paradigm > at all. When it was discovered that a read repair will trigger 100% of the > time when a query is run at ALL consistency, this method of repair started to > gain popularity in the community. In some cases, this method of forcing data > consistency provided better results than normal, scheduled repairs. > > Let's assume, for a second, that an application team is having a hard time > logging into a node in a new data center. You try to cqlsh out to these > nodes, and notice that you are also experiencing intermittent failures, > leading you to suspect that the system_auth tables might be missing a replica > or two. On one node you do manage to connect successfully using cqlsh. One > quick way to fix consistency on the system_auth tables is to set consistency > to ALL, and run an unbound SELECT on every table, tickling each record: > > use system_auth ; > consistency ALL; > consistency level set to ALL. > > SELECT COUNT(*) FROM resource_role_permissons_index ; > SELECT COUNT(*) FROM role_permissions ; > SELECT COUNT(*) FROM role_members ; > SELECT COUNT(*) FROM roles; > > This problem is often seen when logging in with the default cassandra user. > Within cqlsh, there is code that forces the default cassandra user to connect > by querying system_auth at QUORUM consistency. This can be problematic in > larger clusters, and is another reason why you should never use the default > cassandra user. > > > > -----Original Message----- > From: Jon Haddad [mailto:j...@jonhaddad.com] > Sent: Thursday, April 04, 2019 9:21 AM > To: user@cassandra.apache.org > Subject: Re: Assassinate fails > > Ken, > > Alain is right about the system tables. What you're describing only > works on non-local tables. Changing the CL doesn't help with > keyspaces that use LocalStrategy. Here's the definition of the system > keyspace: > > CREATE KEYSPACE system WITH replication = {'class': 'LocalStrategy'} > AND durable_writes = true; > > Jon > > On Thu, Apr 4, 2019 at 9:03 AM Kenneth Brotman > <kenbrot...@yahoo.com.invalid> wrote: > > > > The trick below I got from the book Mastering Cassandra. You have to set > > the consistency to ALL for it to work. I thought you guys knew that one. > > > > > > > > From: Alain RODRIGUEZ [mailto:arodr...@gmail.com] > > Sent: Thursday, April 04, 2019 8:46 AM > > To: user cassandra.apache.org > > Subject: Re: Assassinate fails > > > > > > > > Hi Alex, > > > > > > > > About previous advices: > > > > > > > > You might have inconsistent data in your system tables. Try setting the > > consistency level to ALL, then do read query of system tables to force > > repair. > > > > > > > > System tables use the 'LocalStrategy', thus I don't think any repair would > > happen for the system.* tables. Regardless the consistency you use. It > > should not harm, but I really think it won't help. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
