Hi, Despite our use cases, is't it a good feature to disable reading when a node is doing hinted handoff, just like bootstraping? It will be very useful for READ ONE consitency level.
Or it can be an option in storage-conf.xml, and user can set it when necessary. I'd like to implement this feature if it's useful. 2010/8/18 Chen Xinli <chen.d...@gmail.com> > Thanks for your reply. > > Cassandra, in our case, is used for searching purposes not for data > storage. > We can build the cassandra keyspace data daily/weekly when system load is > lower. > > We have modified the cassandra code to add a value filter which makes the > data-repair not working. > The value filter, as I say, is to filter the columns of a key, and only the > desired column is returned. > The filter is done in local cassandra, not in thrift client; So we have to > disable data-repair. > > Cassandra has met most of our needs except that: > if a node fails, after a while, recovers, joins the cluster and doing > hinted handoff, then a reading is forward to this node, the data returned is > out of date. > > The node failure is not frequently; if it happens unfortunately, we should > keep the reading consitency. > > > 2010/8/18 Benjamin Black <b...@b3k.us> > > On Tue, Aug 17, 2010 at 7:55 PM, Chen Xinli <chen.d...@gmail.com> wrote: >> > Hi, >> > >> > We are going to use cassandra for searching purpose like inbox search. >> > The reading qps is very high, we'd like to use ConsitencyLevel.One for >> > reading and disable read-repair at the same time. >> > >> >> In 0.7 you can set a probability for read repair, but disabling it is >> a spectacularly bad idea. Any write problems on a node will result in >> persistent inconsistency. >> >> > For reading consistency in this condition, the writing should use >> > ConsistencyLevel.ALL. But the writing will fail if one node fails. >> >> You are free to read and write with consistency levels where R+W < N, >> it just means you have weaker consistency guarantees. >> >> > We want such a ConsistencyLevel for writing/reading that : >> > 1. writing will success if there is node alive for this key >> > 2. reading will not forward to a node that's just recovered and doing >> hinted >> > handoff >> > >> > So that, if some node fails, others nodes for replica will receive the >> data >> > and surve reading successfully; >> > when the failure node recovers, it will receive hinted handoff from >> other >> > nodes and it'll not surve reading until hinted handoff is done. >> > >> > Does cassandra support the cases already? or should I modify the code to >> > meet our requirements? >> > >> >> You are phrasing these requirements in terms of a specific >> implementation. What are your actual consistency goals? If node >> failure is such a common occurrence in your system, you are going to >> have _numerous_ problems. >> >> >> b >> > > > > -- > Best Regards, > Chen Xinli > -- Best Regards, Chen Xinli
