I did a POC on CCM, removed sstable_activity sstables files from directory after stopping the node. Restarted the node, sstable_activity table was generated again. You can verify it in your test environment and see if node is working fine without any issues. Important thing is to validate any step in test environment before applying in production.
Regards Manish Regards Manish On Tue, Jul 7, 2020 at 2:36 AM F <gumpinato...@gmail.com> wrote: > Allow me to simplify the question: > > Are there any tables under the system keyspace, if deleted, will rebuild > themselves safely or could be configured to be rebuilt without trashing the > entire node? > > https://docs.datastax.com/en/dse/6.0/cql/cql/cql_using/useQuerySystem.html > > Particular table i am looking at under system keyspace: sstable_activity > > > Apache Cassandra 3.9 > > On Thu, Jul 2, 2020, 12:49 PM F <gumpinato...@gmail.com> wrote: > >> 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! >>> >>
