This is likely due to
https://issues.apache.org/jira/browse/CASSANDRA-2829. Basically, if
you have a column family on which you stop to write suddenly forever
(which will be the case if you drop a cf), one commit log could get
retained forever (forever meaning "until next restart of the node" in
th
All:
Could anyone help me?
Best Regards
Donna li
-邮件原件-
发件人: Donna Li [mailto:donna...@utstar.com]
发送时间: 2011年7月22日 11:23
收件人: user@cassandra.apache.org
主题: cassandra server disk full
All:
Is there an easy way to fix the bug by change server's code?
Best Regards
Donna li
And I guess there's the next problem, if you have more than one client...
On Mon, Jul 25, 2011 at 5:25 AM, Edward Capriolo wrote:
> You should always sync your host clocks. Clients provide timestamp but for
> the server gc_grace and ttl columns can have issues if server clocks are not
> correct.
>There are many things you can do to lower caches,optimize memtables, and
tune jvms.
Please tell what thins i can do to lower caches,optimize memtables, and
tune jvms?
>From experience with similar-sized data sets, 1.5GB may be too little.
Recently I bumped our java HEAP limit from 3GB to 4GB t
may be you can sync the servers with "pool.ntp.org" with running ntp as a
service.
On 25 July 2011 14:34, Paul Loy wrote:
> And I guess there's the next problem, if you have more than one client...
>
>
> On Mon, Jul 25, 2011 at 5:25 AM, Edward Capriolo wrote:
>
>> You should always sync your hos
As I understand it, this will not quarantee that they are millisecond
accurate which is what you need for Cassandra to use the correct commit.
We've seen problems in production and had to rearchitect parts of the system
due to this even though all servers are NTP synched.
http://www.endruntechnolo
I am using normal SATA disk, actually I was worrying about whether it
is okay if every time cassandra using all the io resources?
further more when is the good time to add more nodes when I was just
using normal SATA disk and with 100r/s it could reach 100 %util
how large the data size it sho
On Mon, Jul 25, 2011 at 8:51 AM, Paul Loy wrote:
> As I understand it, this will not quarantee that they are millisecond
> accurate which is what you need for Cassandra to use the correct commit.
> We've seen problems in production and had to rearchitect parts of the system
> due to this even tho
we don't have those guarantees on EC2. Networks can fluctuate wildly.
On Mon, Jul 25, 2011 at 2:00 PM, zGreenfelder wrote:
>
>
> On Mon, Jul 25, 2011 at 8:51 AM, Paul Loy wrote:
>
>> As I understand it, this will not quarantee that they are millisecond
>> accurate which is what you need for Cass
> As I understand it, this will not quarantee that they are millisecond
> accurate which is what you need for Cassandra to use the correct commit.
> We've seen problems in production and had to rearchitect parts of the system
> due to this even though all servers are NTP synched.
It does not ma
as the wiki suggested:
http://wiki.apache.org/cassandra/LargeDataSetConsiderations
Adding nodes is a slow process if each node is responsible for a large
amount of data. Plan for this; do not try to throw additional hardware
at a cluster at the last minute.
I really would like to know what's the
Hi, thanks both for the answers.
The problem was indeed with the timestamps.
What was happening also was that in a mutation involving 1 deletion and
various insertions for the same key, all were using the same timestamp, so
beside looking at the code doing this
remove key
insert key, col, val
in
We have a patch somewhere that will kill the node on IOErrors, since
those tend to be of the class that are unrecoverable.
-ryan
On Thu, Jul 7, 2011 at 8:02 PM, Jonathan Ellis wrote:
> Yeah, ideally it should probably die or drop into read-only mode if it
> runs out of space.
> (https://issues.a
On Sun, Jul 24, 2011 at 3:36 PM, aaron morton wrote:
> What's your use case ? There are people out there having good times with
> counters, see
>
> http://www.slideshare.net/kevinweil/rainbird-realtime-analytics-at-twitter-strata-2011
> http://www.scribd.com/doc/59830692/Cassandra-at-Twitter
It'
Actually I was wrong– our patch will disable gosisp and thrift but
leave the process running:
https://issues.apache.org/jira/browse/CASSANDRA-2118
If people are interested in that I can make sure its up to date with
our latest version.
-ryan
On Mon, Jul 25, 2011 at 10:07 AM, Ryan King wrote:
>
On Mon, Jul 25, 2011 at 7:35 PM, Aaron Turner wrote:
> On Sun, Jul 24, 2011 at 3:36 PM, aaron morton wrote:
>> What's your use case ? There are people out there having good times with
>> counters, see
>>
>> http://www.slideshare.net/kevinweil/rainbird-realtime-analytics-at-twitter-strata-2011
>>
On Mon, Jul 25, 2011 at 11:24 AM, Sylvain Lebresne wrote:
> On Mon, Jul 25, 2011 at 7:35 PM, Aaron Turner wrote:
>> On Sun, Jul 24, 2011 at 3:36 PM, aaron morton
>> wrote:
>>> What's your use case ? There are people out there having good times with
>>> counters, see
>>>
>>> http://www.slidesha
I'm trying to figure out how to use the sstableloader tool. For my test I
have a single node cassandra instance running on my local machine. I have
cassandra running, and validate this by connecting to it with cassandra-cli.
I run sstableloader using the following command:
bin/sstableloader /Us
If the commit log or data disk is full it's not possible for the server to
process any writes, the best it could do is perform reads. But reads may result
in a write due to read repair and will also need to do some app logging, so
IMHO it's really down / dead.
You should free space and restart
How much memory you need depends on a few things such as how many CF's you
have, what your data is like, and what the usage patterns are like. There is no
exact formula.
Generally…
* i would say 4GB of JVM heap is a good start
* key and row caches are set when the CF is created, see "help creat
There are no hard and fast rules to add new nodes, but here are two guidelines:
1) Single node load is getting too high, rule of thumb is 300GB is probably too
high.
2) There are times when the cluster cannot keep up with throughout, for example
the client is getting TimedOutExceptions or TPSta
It's just not possible to control time, as many super villains and Peter
Schuller have shown us
http://www.mail-archive.com/user@cassandra.apache.org/msg15636.html
Often it's not necessary, you can design around simultaneous updates the same
key, use a coordination layer such as zoo keeper or r
I guess the problem it's not whether you can control time in a distributed
system or not, but in this case at least, it's if you consider a timestamp
set by a client outside the cluster as *safe*.
When the timestamp gets hidden behind a client/wrapper library
implementation default, realizing it's
Offset represent different "units" for each columns.
On SSTables columns, you can see following histgrams:
20 4291637
24 28680590
29 3876198
It means your 4291637 read operations required 20 SStables to read,
28680590 ops required 24, so on.
In Write/Read latency columns, Offset r
Looks like the repair finished successfully the second time. However, the
cluster is still severely unbalanced. I was hoping the repair would balance
the nodes. We're using random partitioner. One node has 900GB and others
have 128GB, 191GB, 129GB, 257 GB, etc. The 900GB and the 646GB are just
insa
Background: http://wiki.apache.org/cassandra/Operations
Use node tool ring to check if the tokens are evenly distributed. If not then
check the Load Balancing and Moving Nodes sections in the page above.
If they are and repair has completed use node tool cleanup to remove the data
the node is n
sstableloader uses gossip to discover the Cassandra ring, so you'll
need to run it on a different IP (127.0.0.2 is fine).
On Mon, Jul 25, 2011 at 2:41 PM, John Conwell wrote:
> I'm trying to figure out how to use the sstableloader tool. For my test I
> have a single node cassandra instance runni
I have only 4GB on server, so i give jvm 3 GB of heap, but this dont help,
cassandra still fall when i launch major compaction on 37 GB database.
28 matches
Mail list logo
