Manish, Thank you for checking. I figured it would probably work out by trashing the table and letting Cassandra rebuild, but I was not 100% sure. I was curious to see if there were any built in command line utilities to rebuild those tables, but that appears to not be the case.
I am curious to ask if there are any tables that won't survive being trashed/manually deleted on the system keyspace? I believe that information would be a good addition to have for the DSE / apache cassandra docs. On Mon, Jul 6, 2020, 9:50 PM manish khandelwal <manishkhandelwa...@gmail.com> wrote: > 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! >>>> >>>
