Fixing / Rebuilding Secondary Index

and every node in DC2 and start a cleanup/repair, or 2. drop the secondary index and re-create it using "update column family" in CLI What do you think about those approaches? Thanks, Eran Chinthaka Withana

Re: Bringing a dead node back up after fixing hardware issues

Thanks Brandon. Thanks, Eran Chinthaka Withana On Thu, Jul 26, 2012 at 12:46 PM, Brandon Williams wrote: > On Wed, Jul 25, 2012 at 6:16 PM, Eran Chinthaka Withana > wrote: > > > Alright, lets assume I want to go on this route. I have RF=2 in the data > > center and I be

Re: Bringing a dead node back up after fixing hardware issues

Hi Brandon, > Increasing CL is tricky for us for now, as our RF on that datacenter is 2 > > and CL is set to ONE. If we make the CL to be LOCAL_QUORUM, then, if a > node > > goes down we will have trouble. I will try to increase the RF to 3 in > that > > data center and set the CL to LOCAL_QUORUM

Re: Bringing a dead node back up after fixing hardware issues

to be decommissioned. Coming back to the original question, without touching the CL, can we bring back a dead node (after fixing it) and somehow tell Cassandra that the node is backup and do not send read requests until it gets all the data? Thanks, Eran Chinthaka Withana On Mon, Jul 23, 2012 at 6:

Bringing a dead node back up after fixing hardware issues

n the node comes up, it started serving reads, creating a large number of read misses. So the question is, what is the best way to bring back a dead node (once its hardware issues are fixed) without impacting read misses? Thanks, Eran Chinthaka Withana

Re: Adding New Nodes to a Production Cluster

Thanks Robin for the insight. I thought the node will start serving requests before the bootstrap process completes. Seems like I'm wrong. I got this verified thru #cassandra too. Thanks, Eran Chinthaka Withana On Wed, Jun 27, 2012 at 2:44 PM, Robin Verlangen wrote: > Hi Eran, >

Adding New Nodes to a Production Cluster

a node goes down (say, disk or RAID failure) for a longer period of time. Please help me to find an answer to this. Thanks, Eran Chinthaka Withana

Integration Testing for Cassandra

dy in Cassandra code base? I really appreciate if someone can shed some light here. [1] http://prettyprint.me/2010/02/14/running-cassandra-as-an-embedded-service/ Thanks, Eran Chinthaka Withana

Re: Few Clarifications on Major Compactions

I think I can afford this too. Thanks, Eran Chinthaka Withana On Wed, Feb 29, 2012 at 7:17 PM, Tyler Hobbs wrote: > At this point, using LeveledCompaction is a much better way to have good > guarantees about how many sstables your reads will hit (and thus better > latency guarantees) t

Few Clarifications on Major Compactions

should avoid at all costs? What will be the implications? Thanks, Eran Chinthaka Withana

Re: Key cache hit rate issue

True, the high hit rate has translated to low read latency. But the question is how can I debug the reason for low hit rate now assuming read patterns haven't changed. Thanks, Eran Chinthaka Withana On Fri, Feb 17, 2012 at 3:07 PM, Jonathan Ellis wrote: > I suspect the main difference

Re: Key cache hit rate issue

nning repairs last night but didn't see any read latency improvements, yet. Thanks, Eran Chinthaka Withana On Fri, Feb 17, 2012 at 11:30 AM, Jonathan Ellis wrote: > Only thing I can think of is that if you've set the cache size > manually over JMX it will preserve that size i

Re: Key cache hit rate issue

Hi Jonathan, > > > For some reason 16637958 (the keys cached) has become a golden number > and I > > don't see key cache increasing beyond that. > > 16637958 is your configured cache capacity according to the cfstats you > pasted. this is another weird part. If you look at the schema[1] (pasted

Re: Key cache hit rate issue

he_capacity_to. see > how much free memory you have and if the numbers suggest that you have hit > that limit, therefore reducing row cache size > > > > From: Eran Chinthaka Withana > Reply-To: "user@cassandra.apache.org" > Date: Thu, 16 Feb 2012 13:52:38 -0800

Re: Key cache hit rate issue

eason 16637958 (the keys cached) has become a golden number and I don't see key cache increasing beyond that. I also checked memory and I have about 4GB left in JVM memory and didn't see any issues on logs. Thanks, Eran Chinthaka Withana On Thu, Feb 16, 2012 at 1:20 PM, Jonathan Ellis wr

Re: Key cache hit rate issue

Filter Space Used: 331522920 Key cache capacity: 16637958 Key cache size: 16637958 Key cache hit rate: 0.2708 Row cache: disabled Compacted row minimum size: 51 Compacted row maximum size: 6866 Compacted row mean size: 2560 Thanks, Eran Chinthaka Withana On Thu, Feb 16, 2012 at 12:30

Re: Key cache hit rate issue

Its in the order of 261 to 8000 and the ratio is 0.00. But i guess 8000 is bit high. Is there a way to fix/improve it? Thanks, Eran Chinthaka Withana On Tue, Feb 14, 2012 at 3:42 PM, aaron morton wrote: > Out of interest what does cfstats say about the bloom filter stats ? A > high

Key cache hit rate issue

Hi, I'm using Cassandra 1.0.7 and I've set the keys_cached to about 80% (using the numerical values). This is visible in cfstats too. But I'm getting less than 20% (or sometimes even 0%) key cache hit rate. Well, the data access pattern is not the issue here as I know they are retrieving the same