Yes, that is what would happen; some anti entropy mechanism would have to
perform the replication after the fact (hinted handoff, read repair, manual
repair etc).
For most things, it's better to rely on the dynamic endpoint snitch and
some sort of dynamic load balancing from the client (see:
https
On 03/08/12 21:40, Edward Capriolo wrote:
On Thu, Mar 8, 2012 at 1:43 PM, Feng Qu wrote:
Hello, is there a way to take one node out of ring and running a major
compaction?
Feng Qu
http://www.jointhegrid.com/highperfcassandra/?p=187
What are the drawbacks to disable thrift and gossip? So y
On Thu, Mar 8, 2012 at 1:43 PM, Feng Qu wrote:
> Hello, is there a way to take one node out of ring and running a major
> compaction?
>
> Feng Qu
http://www.jointhegrid.com/highperfcassandra/?p=187
Cheers
Hello,
In a CF I have with valueless columns and column-name type being
integer, I am seeing latency in the order of 80-90ms to retrieve a
single column from a row containing 50K columns. It is just a single
node db on a single box.
Another row with 20K columns in the same CF, still has the latency
Hi all,
I've recently upgraded a test cluster from 0.8.x to 1.0.8 for testing multi
data center communications. I have the following configuration file on 3 nodes
in a single data center.
https://gist.github.com/4671e4ae562a47f96ed2
However, when I run node tool on any of these nodes, they r
Hello, is there a way to take one node out of ring and running a major
compaction?
Feng Qu
It seemed that one of the other nodes had trouble with a compaction task.
The C node was waiting for that.
It's now streaming all it's data into place.
Thank you all for your time!
2012/3/7
> just run "nodetool compactionstat" on other nodes.
>
>
> -Original Message-
> From: "R. Verlan
Hi all
Running Cassandra 1.0.7, I recently changed a few read heavy column
families from SizeTieredCompactionStrategy to LeveledCompactionStrategy and
added in SnappyCompressor, all with defaults so 5MB files and if memory
serves me correctly 64k chunk size for compression.
The results were amazin
It is better to get a sensible amount. Moving a few MB's is ok (see
thrift_framed_transport_size_in_mb in cassandra.yaml).
Long running queries can reduce the overall query throughput. They also churn
memory over on both the server and the client.
Run some tests on your data, see how long it
I did change the rpc_endpoint to endpoints and now the splits are
computed correctly. So it's a bug in cassandra to hadoop interface. I
suspect that it has something to do with wide rows with tens of
thousands of columns we have because the unpatched getSubSplits()
works with small test data we hav
10 matches
Mail list logo
