Michael, both of the folders are with hash, so I dont think that would be an issue.
What is strange is why the tables dont show up if the keyspaces are visible. Shouldnt that be a meta data that can be edited once and then be visible? Affan - Affan On Thu, Apr 5, 2018 at 7:55 PM, Michael Shuler <mich...@pbandjelly.org> wrote: > On 04/05/2018 09:04 AM, Faraz Mateen wrote: > > > > For example, if the table is *data_main_bim_dn_10*, its data directory > > is named data_main_bim_dn_10-a73202c02bf311e8b5106b13f463f8b9. I created > > a new table with the same name through cqlsh. This resulted in creation > > of another directory with a different hash i.e. > > data_main_bim_dn_10-c146e8d038c611e8b48cb7bc120612c9. I copied all data > > from the former to the latter. > > > > Then I ran *"nodetool refresh ks1 data_main_bim_dn_10"*. After that I > > was able to access all data contents through cqlsh. > > > > Now, the problem is, I have around 500 tables and the method I mentioned > > above is quite cumbersome. Bulkloading through sstableloader or remote > > seeding are also a couple of options but they will take a lot of time. > > Does anyone know an easier way to shift all my data to new setup on > DC/OS? > > For upgrade support from older versions of C* that did not have the hash > on the data directory, the table data dir can be just > `data_main_bim_dn_10` without the appended hash, as in your example. > > Give that a quick test to see if that simplifies things for you. > > -- > Kind regards, > Michael > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >