Re: Cassandra disk usage

Hello The load of data on 3 nodes is : Address DC RackStatus State Load OwnsToken 113427455640312821154458202477256070485 172.19.10.1 19 10 Up Normal 22.16 GB 33.33% 0 172.19.10.2 19 10 Up Normal 19.89 GB 33.33%

Replication Factor question

Hello, currently reading the "Practical Cassandra". In the section about replication factors the book says: "It is generally not recommended to set a replication factor of 3 if you have fewer than six nodes in a data center". Why is that? What problems would arise if I had a replication factor

Re: Replication Factor question

Hi Markus, > "It is generally not recommended to set a replication factor of 3 if > you have fewer than six nodes in a data center". Actually you can create a cluster with 3 nodes and replication level 3. But in this case if one of them would fail cluster become inconsistent. In this way minimum re

Re: Replication Factor question

I do not agree with this advice. It can be perfectly reasonable to have #nodes < 2*RF. It is common to deploy a 3 node cluster with RF=3 and it works fine as long as each node can handle 100% of your data, and keep up with the workload. -Tupshin On Apr 14, 2014 5:25 AM, "Markus Jais" wrote: >

Re: Replication Factor question

Hi all, thanks. Very helpful. @Tupshin: With a 3 node cluster and RF 3 isn't it a problem if one node fails (due to hardware problems, for example). According to the C* docs, writes fail if the number of nodes is smaller than the RF. I agree that it will run fine as long as all nodes are up and

Re: Replication Factor question

With 3 nodes, and RF=3, you can always use CL=ALL if all nodes are up, QUORUM if 1 node is down, and ONE if any two nodes are down. The exact same thing is true if you have more nodes. -Tupshin On Apr 14, 2014 7:51 AM, "Markus Jais" wrote: > Hi all, > > thanks. Very helpful. > > @Tupshin: With

Re: clearing tombstones?

I'm still somewhat in the middle of the process, but it's far enough along to report back. 1.) I changed GCGraceSeconds of the CF to 0 using cassandra-cli 2.) I ran nodetool compact on a single node of the nine (I'll call it "1"). It took 5-7 hours, and reduced the CF from ~450 to ~75GG (*). 3.)

Re: bloom filter + suddenly smaller CF

Hello William From the doc: http://www.datastax.com/documentation/cassandra/1.2/cassandra/operations/ops_tuning_bloom_filters_c.html After updating the value of bloom_filter_fp_chance on a table, Bloom filters need to be regenerated in one of these ways: - Initiate compaction

Re: bloom filter + suddenly smaller CF

Bloom filters are built on creation / rebuild of SSTable. If you removed the data, but the old SSTables weren't compacted or you didn't rebuild them manually, bloom filters will stay the same size. M. Kind regards, Michał Michalski, michal.michal...@boxever.com On 14 April 2014 14:44, William O

bloom filter + suddenly smaller CF

I had a thread on this forum about clearing junk from a CF. In my case, it's ~90% of ~1 billion rows. One side effect I had hoped for was a reduction in the size of the bloom filter. But, according to nodetool cfstats, it's still fairly large (~1.5GB of RAM). Do bloom filters ever resize themse

Re: bloom filter + suddenly smaller CF

I didn't cross link my thread, but the basic idea is I've done: 1.) Process that deleted ~900M of ~1G rows from a CF 2.) Set GCGraceSeconds to 0 on CF 3.) Run nodetool compact on all N nodes And I checked, and all N nodes have bloom filters using 1.5 +/- .2 GB of RAM (I didn't explicitly write do

Re: bloom filter + suddenly smaller CF

Did you set Bloom Filter's FP chance before or after the step 3) above? If you did it before, C* should build Bloom Filters properly. If not - that's the reason. Kind regards, Michał Michalski, michal.michal...@boxever.com On 14 April 2014 15:04, William Oberman wrote: > I didn't cross link my

Re: bloom filter + suddenly smaller CF

Sorry, I misread the question - I thought you've also changed FP chance value, not only removed the data. Kind regards, Michał Michalski, michal.michal...@boxever.com On 14 April 2014 15:07, Michal Michalski wrote: > Did you set Bloom Filter's FP chance before or after the step 3) above? If > y

Re: bloom filter + suddenly smaller CF

Ah, so I could change the chance value to "poke it". Good to know! On Mon, Apr 14, 2014 at 10:12 AM, Michal Michalski < michal.michal...@boxever.com> wrote: > Sorry, I misread the question - I thought you've also changed FP chance > value, not only removed the data. > > Kind regards, > Michał M

Re: bloom filter + suddenly smaller CF

Hi Will, You can run 'nodetool upgradesstables', this will rewrite the SSTables and regenerate the bloom filters for those tables, This will reduce their usage. Mark On Mon, Apr 14, 2014 at 3:16 PM, William Oberman wrote: > Ah, so I could change the chance value to "poke it". Good to know! >

Re: C* 1.2.15 Decommission issues

Russell, The hinted handoff manager is checking for hints to see if it needs to pass those off during the decommission so that the hints don't get lost. You most likely have a lot of hints, or a bunch of tombstones, or something in the table causing the query to timeout. You aren't seeing any

Re: Cassandra Strange behaviour

Adding some more log: INFO [FlushWriter:22] 2014-04-14 19:23:13,443 Memtable.java (line 254) Completed flushing /opt/cassandra/data/USER_DATA/freeNumbers-g-1074-Data.db (37824462 bytes) WARN [CompactionExecutor:258] 2014-04-14 19:23:31,915 CompactionManager.java (line 509) insufficient space to co

Cassandra Strange behaviour

Hello to all I have cassandra cluster with 3 nodes and RF=3 writing with Quorum. Application wrote today several millions of records to specific CF. After that one of servers went wild , he eats up the disk. As i see from logs hinted handoff from 2 other servers are occuring to disk server. On this

Re: Replication Factor question

On Mon, Apr 14, 2014 at 2:25 AM, Markus Jais wrote: > "It is generally not recommended to set a replication factor of 3 if you > have fewer than six nodes in a data center". > I have a detailed post about this somewhere in the archives of this list (which I can't seem to find right now..) but br

Logs of commitlog files

1. With cassandra 2.0.6, we have 547G of files in /var/lib/commitlog/. I started a "nodetool flush" 65 minutes ago; it's still running. The 17536 commitlog files have been created in the last 3 days. (The node has 2.1T of sstables data in /var/lib/cassandra/data/. This is in staging, not pro

Re: Replication Factor question

tl;dr make sure you have enough capacity in the event of node failure. For light workloads, that can be fulfilled with nodes=rf. -Tupshin On Apr 14, 2014 2:35 PM, "Robert Coli" wrote: > On Mon, Apr 14, 2014 at 2:25 AM, Markus Jais wrote: > >> "It is generally not recommended to set a replicatio

Re: Intermittent long application pauses on nodes

My searching my list archives shows this thread evaporated. Was a root cause ever found? Very curious. On Mon, Feb 3, 2014 at 11:52 AM, Benedict Elliott Smith < belliottsm...@datastax.com> wrote: > Hi Frank, > > The "9391" under RevokeBias is the number of milliseconds spent > synchronising

RE: Lots of commitlog files

Another thing. cassandra.yaml says: # Total space to use for commitlogs. Since commitlog segments are # mmapped, and hence use up address space, the default size is 32 # on 32-bit JVMs, and 1024 on 64-bit JVMs. # # If space gets above this value (it will round up to the next nearest # segment m