incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From srmore <comom...@gmail.com>
Subject Re: Cannot resolve schema disagreement
Date Fri, 10 May 2013 03:49:04 GMT
Thought so.

Thanks Aaron !



On Thu, May 9, 2013 at 6:09 PM, aaron morton <aaron@thelastpickle.com>wrote:

> This raises an important question, where does Cassandra get the time
> information from ?
>
> http://docs.oracle.com/javase/6/docs/api/java/lang/System.html
> normally milliSeconds, not sure if 1.0.12 may use nanoTime() which is less
> reliable on some VM's.
>
> and is it required (I know it is highly highly advisable to) to keep
> clocks in sync, any suggestions/best practices on how to keep the clocks in
> sync  ?
>
> http://en.wikipedia.org/wiki/Network_Time_Protocol
>
> Hope that helps.
>
> -----------------
> Aaron Morton
> Freelance Cassandra Consultant
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 10/05/2013, at 9:16 AM, srmore <comomore@gmail.com> wrote:
>
> Thanks Rob !
>
> Tried the steps, that did not work, however I was able to resolve the
> problem by syncing the clocks. The thing that confuses me is that, the FAQ
> says "Before 0.7.6, this can also be caused by cluster system clocks being
> substantially out of sync with each other". The version I am using was
> 1.0.12.
>
> This raises an important question, where does Cassandra get the time
> information from ? and is it required (I know it is highly highly advisable
> to) to keep clocks in sync, any suggestions/best practices on how to keep
> the clocks in sync  ?
>
>
>
> /srm
>
>
> On Thu, May 9, 2013 at 1:58 PM, Robert Coli <rcoli@eventbrite.com> wrote:
>
>> On Wed, May 8, 2013 at 5:40 PM, srmore <comomore@gmail.com> wrote:
>> > After running the commands, I get back to the same issue. Cannot afford
>> to
>> > lose the data so I guess this is the only option for me. And
>> unfortunately I
>> > am using 1.0.12 ( cannot upgrade as of now ). Any, ideas on what might
>> be
>> > happening or any pointers will be greatly appreciated.
>>
>> If you can afford downtime on the cluster, the solution to this
>> problem with the highest chance of success is :
>>
>> 1) dump the existing schema from a good node
>> 2) nodetool drain on all nodes
>> 3) stop cluster
>> 4) move schema and migration CF tables out of the way on all nodes
>> 5) start cluster
>> 6) re-load schema, being careful to explicitly check for schema
>> agreement on all nodes between schema modifying statements
>>
>> In many/most cases of schema disagreement, people try the FAQ approach
>> and it doesn't work and they end up being forced to do the above
>> anyway. In general if you can tolerate the downtime, you should save
>> yourself the effort and just do the above process.
>>
>> =Rob
>>
>
>
>

Mime
View raw message