Re: Recommended num_tokens setting for small cluster

Hi for best performance you can start form node that has lower disk capacity and set it to 256 and for other nods use proportion to this node to find num of tokens. > On Shahrivar 9, 1397 AP, at 10:40, Max C. wrote: > > Jeff/Kurt/Alex — thanks so much for your feedback on this issue, and than

Re: Recommended num_tokens setting for small cluster

Jeff/Kurt/Alex — thanks so much for your feedback on this issue, and thanks for all of the help you guys have lent to people on this list over the years. :-) - Max > On Aug 29, 2018, at 11:38 pm, Oleksandr Shulgin > wrote: > > On Thu, Aug 30, 2018 at 12:05

1.2.19: AssertionError when running compactions on a CF with TTLed columns

Hi everyone, I'm running a Cassandra 1.2.19 cluster of 40 nodes and compactions of a specific column family are sporadically raising an AssertionError like this (full stack trace visible under https://gist.github.com/rborer/46862d6d693c0163aa8fe0e74caa2d9a): ERROR [CompactionExecutor:9137] 2018-0

unsubscribe

Re: Large sstables

Hi,Dear Vitali The best option for you is migrating data to the new table and change portion key patterns to a better distribution of data and you sstables become smaller but if your data already have good distribution and your data is really big you must add new server to your datacenter, if yo

Re: Bootstrap streaming issues

thank you On Thu, Aug 30, 2018 at 11:58 AM Jeff Jirsa wrote: > This is the closest JIRA that comes to mind (from memory, I didn't search, > there may be others): https://issues.apache.org/jira/browse/CASSANDRA-8150 > > The best blog that's all in one place on tuning GC in cassandra is > actually

Re: [EXTERNAL] Re: Nodetool refresh v/s sstableloader

Thank you, everyone, for responding. Rajath Subramanyam On Thu, Aug 30, 2018 at 8:38 AM Carl Mueller wrote: > - Range aware compaction strategy that subdivides data by the token range > could help for this: you only bakcup data for the primary node and not the > repli

Re: Bootstrap streaming issues

This is the closest JIRA that comes to mind (from memory, I didn't search, there may be others): https://issues.apache.org/jira/browse/CASSANDRA-8150 The best blog that's all in one place on tuning GC in cassandra is actually Amy's 2.1 tuning guide: https://tobert.github.io/pages/als-cassandra-21-

Re: Bootstrap streaming issues

Hi Jeff, Is there any JIRA that talks about increasing the HEAP will help? Also, any other alternatives than increasing the HEAP Size? last time when I tried increasing the heap, longer GC Pauses caused more damage in terms of latencies while gc pause. On Wed, Aug 29, 2018 at 11:07 PM Jai Bheemse

Re: commitlog content

Thank you for the excellent response Alain! On Thu, Aug 30, 2018 at 5:25 PM Alain RODRIGUEZ wrote: > > Hello Vitaly. > > This sounds weird to me (unless we are speaking about a small size MB, a few > GB maybe). Then the commit log size is limited, by default (see below) and > the data should gr

Re: [EXTERNAL] Re: Nodetool refresh v/s sstableloader

- Range aware compaction strategy that subdivides data by the token range could help for this: you only bakcup data for the primary node and not the replica data - yes, if you want to use nodetool refresh as some sort of recovery solution, MAKE SURE YOU STORE THE TOKEN LIST with the sstables/snapsh

Re: Large sstables

Either of those are options, but there’s also sstablesplit to break it up a bit Switching to LCS can be a problem depending on how many sstables /overlaps you have -- Jeff Jirsa > On Aug 30, 2018, at 8:05 AM, Vitali Dyachuk wrote: > > Hi, > Some of the sstables got too big 100gb and more s

Large sstables

Hi, Some of the sstables got too big 100gb and more so they are not compactiong any more so some of the disks are running out of space. I'm running C* 3.0.17, RF3 with 10 disks/jbod with STCS. What are my options? Completely delete all data on this node and rejoin it to the cluster, change CS to LC

Re: commitlog content

Hello Vitaly. This sounds weird to me (unless we are speaking about a small size MB, a few GB maybe). Then the commit log size is limited, by default (see below) and the data should grow bigger in most cases. According to the documentation ( http://cassandra.apache.org/doc/latest/architecture/sto