Btw anyone having problems with repair might like to follow proposal for different system: https://issues.apache.org/jira/browse/CASSANDRA-3620
With this system you would only need to run repair to ensure all data has maximum redundancy across the cluster (which also increases consistency for ConsistencyLevel.ONE reads). The tombstone buildup that can kill performance would be automatically prevented, so you wouldn't need to run with low GCSeconds values, and there would no longer be the risk of data corruption when repair can't be run within the GCSeconds window On 15 December 2011 14:30, Edward Capriolo <edlinuxg...@gmail.com> wrote: > The more physical data that lives on a node the more intensive operations > are. Especially read based ops. > > Even if your ring is balanced something like a failed repair could create > a data imbalance. > > From some offline talks with you I know you node count is on smaller end > and repairs have been problematic from disk space. > > Have you considered leveraging read repair? An application that sweeps > though range-scan + get would trigger read repairs. Also the 1.0 hinting > took steps to make hints stored on the coordinator and lessened the need > for anti entropy repair. > > On Wednesday, December 14, 2011, Maxim Potekhin <potek...@bnl.gov> wrote: > > What could be the reason I see unequal loads on a 3-node cluster? > > This all started happening during repairs (which again are not going > smoothly). > > > > Maxim > > > >
