Re: Periodic Anti-Entropy repair

Did you have a look at Reaper? https://github.com/spotify/cassandra-reaper it's a project created by Spotify to address this issue, I did not evaluate it yet but it looks promising. On May 22, 2015 9:01 PM, Brice Argenson bargen...@gmail.com wrote: Hi everyone, We are currently migrating from

INFO LOGS NOT written to System.log (Intermittently)

Hi I have a *3 node *cluster. Logging Level: *INFO* We observed that for there is nothing written to the system.log file(on all three nodes) for a substantial duration of time(~24 minutes) *INFO [CompactionExecutor:52531] 2015-05-20 05:16:38,187 CompactionController.java (line 198)

Normal to have an 8g commit log?

I have a single node c* server (used for dev). I've been playing around with it, inserting / removing several million rows. At the moment, all tables have been dropped / truncated, and the data directory itself is showing about 45mb used (most of it is probably in the OpsCenter tables rather than

RE: Nodetool on 2.1.5

Thanks all, Looks like the long way of doing nodetool cleanup repair on each machine is want needs to be done now. So what about the graphs on Ops Center not working , anyone seen this before? Steve From: Jason Wee [mailto:peich...@gmail.com] Sent: 22 May 2015 04:27 To:

RE: Drop/Create table with same CF Name

Can someone share the content on this link please, I’m aware of issues where recreating key spaces can cause inconsistency in 2.0.13 if memTables are not flushed beforehand , is this the issues that is resolved? From: Ken Hancock [mailto:ken.hanc...@schange.com] Sent: 21 May 2015 17:13 To:

Re: Normal to have an 8g commit log?

Yes. 2.1 commitlogs are 8gb. 2.0 were 1gb. you can configure this in the yaml. http://docs.datastax.com/en/cassandra/1.2/cassandra/configuration/configCassandra_yaml_r.html?scroll=reference_ds_qfg_n1r_1k__commitlog_segment_size_in_mb All the best, [image: datastax_logo.png]

Re: Performance penalty of multiple UPDATEs of non-pk columns

Thanks, I wasn't sure if memtables and sstables contain only the newest values (I though replication might require storing old values). So the number of lookups for a newest value should be bound by max_compaction_threshold setting. Looks to me it's safe to perform many UPDATEs of non-pk

Re: Drop/Create table with same CF Name

I hadn't run into that one, but I did run into the old (deleted) SSTables somehow getting injected back into the dropped column family, resulting in a exception and the Thrift connection closing down. On Fri, May 22, 2015 at 7:53 AM, Walsh, Stephen stephen.wa...@aspect.com wrote: Can someone

Re: Normal to have an 8g commit log?

So it won't increase beyond 8gb ish? On May 22, 2015 6:39 PM, Sebastian Estevez sebastian.este...@datastax.com wrote: Yes. 2.1 commitlogs are 8gb. 2.0 were 1gb. you can configure this in the yaml.

Re: Drop/Create table with same CF Name

I’m aware of issues where recreating key spaces can cause inconsistency in 2.0.13 if memTables are not flushed beforehand , is this the issues that is resolved? Yep, that's https://issues.apache.org/jira/browse/CASSANDRA-7511 All the best, [image: datastax_logo.png]

RE: Multiple cassandra instances per physical node

We run 2 nodes (from 2 different rings) on the same physical host. One is for a random ring; the other is byteordered to support some alphabetic range queries. Each instance has its own binary install, data directory and ports. One limitation - with one install of OpsCenter agent, it can only

RE: Drop/Create table with same CF Name

Thanks for the link, I don’t think your link is what I hand mind – considering it mentioned to be fixed in 2.0.13 I was referring to this “won’t fix” issue https://issues.apache.org/jira/browse/CASSANDRA-4857 We’ve seen this a few times, we’re we drop a key space and re-create it and get

Re: Normal to have an 8g commit log?

Correct, the segments are allocated and reused and have the size you specify in the YAML. Only one known issue where it will grow beyond 8gb that I'm aware of if you're running an old version: https://issues.apache.org/jira/browse/CASSANDRA-7511 All the best, [image: datastax_logo.png]

Re: Drop/Create table with same CF Name

This issue really needs to be strongly highlighted in the documentation. Imagine someone noticing similarities between SQL and CQL and assuming that one could actually drop a table and recreate the table as a method of deleting all the data...totally crazy, I know... On Fri, May 22, 2015 at 11:06

Periodic Anti-Entropy repair

Hi everyone, We are currently migrating from DSE to Apache Cassandra and we would like to put in place an automatic and periodic *nodetool repair* execution to replace the one executed by OpsCenter. I wanted to create a script / service that would run something like that: *token_rings =