incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <aa...@thelastpickle.com>
Subject Re: Cannot resolve schema disagreement
Date Thu, 09 May 2013 23:09:36 GMT
> 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