incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "olek.stasiak@gmail.com" <olek.stas...@gmail.com>
Subject Re: Problems with adding datacenter and schema version disagreement
Date Wed, 19 Mar 2014 15:44:46 GMT
Bump, could anyone comment this behaviour, is it correct, or should I
create Jira task for this problems?
regards
Olek

2014-03-18 16:49 GMT+01:00 olek.stasiak@gmail.com <olek.stasiak@gmail.com>:
> Oh, one more question: what should be configuration for storing
> system_traces keyspace? Should it be replicated or stored locally?
> Regards
> Olek
>
> 2014-03-18 16:47 GMT+01:00 olek.stasiak@gmail.com <olek.stasiak@gmail.com>:
>> Ok, i've dropped all system keyspaces, rebuild cluster and recover
>> schema, now everything looks ok.
>> But main goal of operations was to add new datacenter to cluster.
>> After starting node in new cluster two schema versions appear, one
>> version is held by 6 nodes of first datacenter, second one is in newly
>> added node in new datacenter. Sth like this:
>> nodetool status
>> Datacenter: datacenter1
>> =======================
>> Status=Up/Down
>> |/ State=Normal/Leaving/Joining/Moving
>> --  Address        Load       Tokens  Owns   Host ID
>>             Rack
>> UN  192.168.1.1  50.19 GB   1       0,5%
>> c9323f38-d9c4-4a69-96e3-76cd4e1a204e  rack1
>> UN  192.168.1.2  54.83 GB   1       0,3%
>> ad1de2a9-2149-4f4a-aec6-5087d9d3acbb  rack1
>> UN  192.168.1.3  51.14 GB   1       0,6%
>> 0ceef523-93fe-4684-ba4b-4383106fe3d1  rack1
>> UN  192.168.1.4  54.31 GB   1       0,7%
>> 39d15471-456d-44da-bdc8-221f3c212c78  rack1
>> UN  192.168.1.5  53.36 GB   1       0,3%
>> 7fed25a5-e018-43df-b234-47c2f118879b  rack1
>> UN  192.168.1.6  39.89 GB   1       0,1%
>> 9f54fad6-949a-4fa9-80da-87efd62f3260  rack1
>> Datacenter: DC1
>> ===============
>> Status=Up/Down
>> |/ State=Normal/Leaving/Joining/Moving
>> --  Address        Load       Tokens  Owns   Host ID
>>             Rack
>> UN  192.168.1.7  100.77 KB  256     97,4%
>> ddb1f913-d075-4840-9665-3ba64eda0558  RAC1
>>
>> describe cluster;
>> Cluster Information:
>>    Name: Metadata Cluster
>>    Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
>>    Partitioner: org.apache.cassandra.dht.RandomPartitioner
>>    Schema versions:
>> 8fe34841-4f2a-3c05-97f2-15dd413d71dc: [192.168.1.7]
>>
>> 4ad381b6-df5a-3cbc-ba5a-0234b74d2383: [192.168.1.1, 192.168.1.2,
>> 192.168.1.3, 192.168.1.4, 192.168.1.5, 192.168.1.6]
>>
>> All keyspaces are now configured to keep data in datacenter1.
>> I assume, that It's not correct behaviour, is it true?
>> Could you help me, how can I safely add new DC to the cluster?
>>
>> Regards
>> Aleksander
>>
>>
>> 2014-03-14 18:28 GMT+01:00 olek.stasiak@gmail.com <olek.stasiak@gmail.com>:
>>> Ok, I'll do this during the weekend, I'll give you a feedback on Monday.
>>> Regards
>>> Aleksander
>>>
>>> 14 mar 2014 18:15 "Robert Coli" <rcoli@eventbrite.com> napisaƂ(a):
>>>
>>>> On Fri, Mar 14, 2014 at 12:40 AM, olek.stasiak@gmail.com
>>>> <olek.stasiak@gmail.com> wrote:
>>>>>
>>>>> OK, I see, so the data files stay in place, i have to just stop
>>>>> cassandra on whole cluster, remove system schema and then start
>>>>> cluster and recreate all keyspaces with all column families? Data will
>>>>> be than loaded automatically from existing ssstables, right?
>>>>
>>>>
>>>> Right. If you have clients reading while loading the schema, they may get
>>>> exceptions.
>>>>
>>>>>
>>>>> So one more question: what about KS system_traces? should it be
>>>>> removed and recreted? What data it's holding?
>>>>
>>>>
>>>> It's holding data about tracing, a profiling feature. It's safe to nuke.
>>>>
>>>> =Rob
>>>>

Mime
View raw message