cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Faraz Mateen <fmat...@an10.io>
Subject Re: Shifting data to DCOS
Date Tue, 10 Apr 2018 11:28:00 GMT
Sorry for the late reply. I was trying to figure out some other approach to
it.

@Kurt - My previous cluster has 3 nodes but replication factor is 2. I am
not exactly sure how I would handle the tokens. Can you explain that a bit?

@Michael - Actually, my DC/OS cluster has an older version than my previous
cluster. However both of them have hash with their data directories.
Previous cluster is on version 3.9 while new DC/OS cluster is on 3.0.16.


On Fri, Apr 6, 2018 at 2:35 PM, kurt greaves <kurt@instaclustr.com> wrote:

> Without looking at the code I'd say maybe the keyspaces are displayed
> purely because the directories exist (but it seems unlikely). The process
> you should follow instead is to exclude the system keyspaces for each node
> and manually apply your schema, then upload your CFs into the correct
> directory. Note this only works when RF=#nodes, if you have more nodes you
> need to take tokens into account when restoring.
>
>
> On Fri., 6 Apr. 2018, 17:16 Affan Syed, <asyed@an10.io> wrote:
>
>> 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 <michael@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-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: user-help@cassandra.apache.org
>>>
>>>
>>


-- 
Faraz Mateen

Mime
View raw message