cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2045) Simplify HH to decrease read load when nodes come back
Date Tue, 17 May 2011 20:55:47 GMT


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

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:
>             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:

View raw message