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
>
>

Reply via email to