I have actually tested repair in many interesting scenarios: Once I joined a node and forgot autobootstrap=true So the data looked like this in the ring left node 8GB new node 0GB right node 8GB
After repair left node 10 GB new node 13 gb right node 12 gb We do not run repair at all. It is better then the 0.6 and 0.7 days, but a missed delete does not mean much to us. The difference between an 8gb sstable and a 12 gb one could be major performance for us since we do thousands of reads/sec. On Wed, May 15, 2013 at 5:37 AM, André Cruz <andre.c...@co.sapo.pt> wrote: > On May 10, 2013, at 7:24 PM, Robert Coli <rc...@eventbrite.com> wrote: > > > 1) What version of Cassandra do you run, on what hardware? > > 1.1.5 - 6 nodes, 32GB RAM, 300GB data per node, 900GB 10k RAID1, Intel(R) > Xeon(R) CPU E5-2609 0 @ 2.40GHz. > > > 2) What consistency level do you write at? Do you do DELETEs? > > QUORUM. Yes, we do deletes. > > > 3) Do you run a regularly scheduled repair? > > Yes. > > > 4) If you answered "yes" to 3, what is the frequency of the repair? > > Every 2 days. > > > 5) What has been your subjective experience with the performance of > > repair? (Does it work as you would expect? Does its overhead have a > > significant impact on the performance of your cluster?) > > It works as we expect, it has some impact on performance, but it takes a > long time. We used to run daily repairs, but they started overlapping. The > reason for more frequent repairs is that we do a lot of deletes so we > lowered the gc_grace_period otherwise the dataset would grow too large. > > André > >
