[ 
https://issues.apache.org/jira/browse/CASSANDRA-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035041#comment-13035041
 ] 

Jonathan Ellis commented on CASSANDRA-2045:
-------------------------------------------

bq. Doesn't this mean that, given a very unstable cluster (e.g. EC2) writes 
using CL.ANY can cause nodes to fill up with data unexpectedly quickly?

Sort of.  It means you can fill up by at most 1/RF faster than you thought, 
yes, since rows can only be stored on at most once node that is not a replica 
(the coordinator). The correct fix to that is "stabilize your cluster." :)

bq. It's probably a good idea to try to retain backwards compatibility here as 
much as possible so that rolling upgrades of a cluster is possible

Right, but as discussed above we're not planning to move to materialized-hints 
entirely, so ripping out "classic" hints isn't an option anyway.

bq. I think Edward's idea of storing hints in a per-node CommitLog is a pretty 
elegant solution, unfortunately it's quite a lot more invasive and would be a 
nightmare for maintaining backwards compatibility.

serialized mutation objects as columns in a row is pretty close to commitlog 
format, only you can query it w/ normal tools.

> Simplify HH to decrease read load when nodes come back
> ------------------------------------------------------
>
>                 Key: CASSANDRA-2045
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2045
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Chris Goffinet
>             Fix For: 1.0
>
>
> Currently when HH is enabled, hints are stored, and when a node comes back, 
> we begin sending that node data. We do a lookup on the local node for the row 
> to send. To help reduce read load (if a node is offline for long period of 
> time) we should store the data we want forward the node locally instead. We 
> wouldn't have to do any lookups, just take byte[] and send to the destination.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to