R, Thank you for the reply. I was actually using this article to repair a normal table (a table not in the system keyspace).
However, my issue is related to a system level keyspace. I don't believe this article will help me, as my questions are related to repairing system level keyspaces (sstable_activity specifically) and not a typical table. However, that being said, if the solution is to manually remove the offending data and rerun the repair then I am willing to try that. However, before i potentially render my affected node inoperable... I want to make sure there are not more options for fixing a cassandra generated and maintained table. Even so, thank you for the article! I am glad I am not the only one who uses it, and confirms that at least I was performing the required tasks for my other repairs correctly! :) On Thu, Jul 2, 2020, 12:39 PM Reid Pinchback <rpinchb...@tripadvisor.com> wrote: > Here’s an article link for repairing table corruption, something I’d saved > back last year in case I ever needed it: > > > > https://blog.pythian.com/so-you-have-a-broken-cassandra-sstable-file/ > > > > Hope it helps. > > > > R > > > > *From: *F <gumpinato...@gmail.com> > *Reply-To: *"user@cassandra.apache.org" <user@cassandra.apache.org> > *Date: *Thursday, July 2, 2020 at 12:50 PM > *To: *"user@cassandra.apache.org" <user@cassandra.apache.org> > *Subject: *Corrupt sstables_activity > > > > *Message from External Sender* > > Good afternoon! I have a question related to a system level keyspace. > > Problem: While running a routine full repair on a specific keyspace and > table where i had to remove one of the big data portions for corruption > (sstablescrub failed), the system.log indicated that the specific keyspace > and table repaired successfully. Nevertheless, the system.log also > indicated that one of the big data files related to system.sstable_activity > was corrupted. > > I tried running nodetool scrub on the system.sstable_activity, but it > tombstoned 0 rows and still states it is corrupted. I also verified, via > cqlsh, that the specific node's sstable_activity is not queryable either. > > Because the system keyspace is local, i don't think i can repair it with > nodetool repair. What would be the steps involved to correct this table? > > Version of Apache Cassandra: 3.9 ( its old ) > > Current ideas i have not yet performed: > > 1.) Stop cassandra manually. Remove the offending .db file throwing the > corruption error. Restart cassandra. See if cassandra will rebuild the > table automatically. > > 2.) As (1) above, but remove the entire folder instead of specific db file. > > 3.) Drop the node from the cluster ( would like to avoid this, some data > is RF 1, and i still need to complete other full repairs) > > 4.) Sstablescrub on system.sstable_activity? ( i dont believe this will do > anything because RF is still local ) > > > > Any suggestions moving forward would be appreciated! Thanks! >
