I suspect you're approaching this problem from the wrong side.
The decision of MySQL vs Cassandra isn't usually about performance, it's
about the other features that may impact/enable that performance.
- Will you have a data set that won't fit on any single MySQL Server?
- Will you want to write
What's the "one-year gossip bug" in this context?
On Thu, Mar 22, 2018 at 3:26 PM, Carl Mueller
wrote:
> Thanks. The rolling restart triggers the gossip bug so that's a no go.
> We'lre going to migrate off the clsuter. Thanks!
>
>
>
> On Thu, Mar 22, 2018 at 5:04 PM, Nate McCall
> wrote:
>
>>
Subrange repair of only the neighbors is sufficient
Break the range covering the dead node into ~100 splits and repair those splits
individually in sequence. You don’t have to repair the whole range all at once
--
Jeff Jirsa
> On Mar 22, 2018, at 8:08 PM, Peng Xiao <2535...@qq.com&
Why .14? I would consider 3.0.16 to be production worthy.
--
Jeff Jirsa
> On Mar 23, 2018, at 2:01 PM, Nitan Kainth wrote:
>
> Hi All,
>
> Our repairs are consuming CPU and some research shows that moving to 3.0.14
> will help us fix them. I just want to know community&
Probably closer to https://issues.apache.org/jira/browse/CASSANDRA-13289
Will be in 4.0
--
Jeff Jirsa
> On Mar 25, 2018, at 4:44 PM, Christophe Schmitz
> wrote:
>
> Hi Jeronimo,
>
> I am not sure that will address your exact request, but did you look at this
> i
--
Jeff Jirsa
> On Mar 26, 2018, at 7:56 PM, Xiangfei Ni wrote:
>
> Hi Cassandra experts,
> I am facing an issue,a node downs every day in a 6 nodes cluster,the
> cluster is just in one DC,
> Every node has 4C 16G,and the heap configuration is MAX_HEAP_SIZE=8192m
&
+86 13797007811 <+86%20137%209700%207811>|Tel: + 86 27 5024 2516
> <+86%2027%205024%202516>
>
>
>
> *发件人:* Jeff Jirsa
> *发送时间:* 2018年3月27日 11:03
> *收件人:* user@cassandra.apache.org
> *主题:* Re: A node down every day in a 6 nodes cluster
>
>
>
> That wa
Tombstones probably aren't clearing because the same partition exists with
older timestamps in other files (this is the "sstableexpiredblockers"
problem, or "overlaps").
If you're certain you are ok losing that data, then you could stop the
node, remove lb-143951-big-* , and start the node. This i
CDC may also work for newer versions, but it’ll happen after the mutation is
applied
--
Jeff Jirsa
> On Mar 27, 2018, at 5:31 PM, Christophe Schmitz
> wrote:
>
> Hi Earl,
>
> You probably want to check Cassandra triggers:
> http://cassandra.apache.org/doc/latest/cq
java.lang.OutOfMemoryError: Java heap space
You’re oom’ ing
--
Jeff Jirsa
> On Mar 27, 2018, at 6:45 PM, Xiangfei Ni wrote:
>
> Hi Jeff,
> Today another node was shutdown,I have attached the exception log
> file,could you please help to analyze?Thanks.
>
> Be
expanded the cluster over time and you see an imbalance of disk
usage on the oldest hosts, “nodetool cleanup” will likely free up some of that
data
--
Jeff Jirsa
> On Apr 4, 2018, at 4:32 AM, Jürgen Albersdorfer
> wrote:
>
> Hi,
>
> I have an urgent Problem. - I will run
There is zero reason to believe a full repair would make this better and a lot
of reason to believe it’ll make it worse
For casual observers following along at home, this is probably not the answer
you’re looking for.
--
Jeff Jirsa
> On Apr 4, 2018, at 4:37 AM, Rahul Singh wr
Compressing server side and validating checksums is hugely important in the
more frequently used versions of cassandra - so since you probably want to run
compression on the server anyway, I’m not sure why you’d compress it twice
--
Jeff Jirsa
> On Apr 4, 2018, at 6:23 AM, DuyHai D
May see more isolation for our atomic operations with tickets like (for
example) https://issues.apache.org/jira/browse/CASSANDRA-7056
I don't know of any foreign key tickets off the top of my head, and I'm
almost positive nobody plans on working on that type of concept soon.
On Thu, Apr 12, 20
Pretty sure Ben meant that datastax produces DSE, not Cassandra, and since the
questions specifically mentions DSE in the subject (implying that the user is
going to be running either solr or spark within DSE to talk to cassandra),
Ben’s recommendation seems quite reasonable to me.
--
Jeff
This isn’t really an error and shouldn’t be logged because so few people
understand it well enough to find it useful. Some number of digest mismatches
are expected if you read as you write. I wouldn’t worry about it unless you’re
having a problem.
--
Jeff Jirsa
> On Apr 17, 2018, at 12
It's probably not ideal, but also not really a bug. We need to create the
table in the schema to see if it exists on disk so we know whether or not
to migrate it, and when we learn it's empty, we remove it from the schema
but we dont delete the directory. It's not great, but it's not going to
cause
r each performs: nodetool flush
> ${keyspace} ${cf} and then nodetool snapshot ${keyspace} -cf ${cf}
> Does 3.0.16 not having this "bug"?
> Regards
> L.
>
> On Tue, Apr 17, 2018 at 1:50 PM, Jeff Jirsa wrote:
>
>> It's probably not ideal, but also not really a bu
Many drivers have a downgrading consistency feature that does it for you, but
really you probably want to catch the timeout or unavailable exception and
handle it in your app
--
Jeff Jirsa
> On Apr 19, 2018, at 5:52 AM, Venkata Hari Krishna Nukala
> wrote:
>
> Hi,
>
> I
It doesn’t answer your question, but I’m obligated to point out that Datastax’s
product is Datastax Enterprise / DSE, not “Datastax Cassandra”, as Cassandra is
a trademark of the Apache software foundation.
--
Jeff Jirsa
> On Apr 19, 2018, at 9:42 AM, Chandan Goel wrote:
>
snapshot,
but that may be better than nothing
--
Jeff Jirsa
> On Apr 19, 2018, at 9:48 AM, Durity, Sean R
> wrote:
>
> This answer surprises me, because I would expect NOT to be able to downgrade
> if there are any changes in the sstable structure. I assume:
> -
There have also been a few sstable ref counting bugs that would over report
load in nodetool ring/status due to overlapping normal and incremental repairs
(which you should probably avoid doing anyway)
--
Jeff Jirsa
> On Apr 19, 2018, at 9:27 AM, Rahul Singh wrote:
>
> I’ve seen
a version of Cassandra with bugs in short read protection
--
Jeff Jirsa
> On Apr 21, 2018, at 2:05 PM, Soheil Pourbafrani wrote:
>
> I consume data from Kafka and insert them into Cassandra cluster using Java
> API. The table has 4 keys including a timestamp based on millisecond.
2018 at 1:04 AM, Jinhua Luo wrote:
> >>
> >> You're assuming per DC has same total num_tokens, right?
> >> If I add a new node into DC1, will it change the tokens owned by DC2 and
> >> DC3?
> >>
> >> 2018-04-12 0:59 GMT+08:00 Jeff Jirsa :
> >
The second node will fail to start because of concurrent movement concerns
There’s a flag to override this if you know when it’s safe (for advanced users
only)
--
Jeff Jirsa
> On Apr 28, 2018, at 3:10 AM, Jinhua Luo wrote:
>
> HI All,
>
> For example, if at the same
the losing range
--
Jeff Jirsa
> On Apr 30, 2018, at 8:57 PM, Jinhua Luo wrote:
>
> Hi All,
>
> When a new node added, due to the even distribution of the new tokens,
> the current nodes of the ring should migrate data to this new node.
>
> So, does it requires all
Cluster. The overhead is per cluster.
There are two places you'll run into scaling pain here.
1) Size of the schema (which we have to serialize to send around) - too
many tables, or too many columns in tables, can cause serializing schema to
get really expensive and cause problems
2) Too many mem
hen we should stop ..say 100 ?
>
>
> On Friday, May 4, 2018, Jeff Jirsa wrote:
>
>> Cluster. The overhead is per cluster.
>>
>> There are two places you'll run into scaling pain here.
>>
>> 1) Size of the schema (which we have to serialize to send around
It works fine, and there can be meaningful performance benefits if you have
a sufficiently large machine where either you have so much RAM or so much
disk that a single instance would likely underutilize those resources. You
can configure it by adding multiple IPs to the servers, and running one
in
If you backup the current state of the sstables at the time you upload the
new sstables, you can keep a running point-in-time view without an explicit
snapshot. This is similar to what tablesnap does (
https://github.com/JeremyGrosser/tablesnap )
On Thu, May 10, 2018 at 12:30 PM, Ben Slater
wrote
Which minor version of 3.0
--
Jeff Jirsa
> On May 11, 2018, at 2:54 AM, kooljava2 wrote:
>
>
> Hello,
>
> Upgraded Cassandra 2.1 to 3.0. We see certain data in few columns being set
> to "null". These null columns were created during the row creation time.
There's no single right answer. It depends a lot on the read/write patterns
and other settings (onheap memtable, offheap memtable, etc).
One thing that's probably always true, if you're using ParNew/CMS, 16G heap
is a bit large, but may be appropriate for some read heavy workloads, but
you'd want
This usually happens when you’ve got weird timestamps or a delete in the future
- check your clocks, make sure your timestamp resolution uses the same units in
all applications (likely microseconds), make sure you’re running NTP everywhere
--
Jeff Jirsa
> On May 11, 2018, at 5:37
That looks like Cassandra 3.10 not 3.11.2
It’s also just the auth cache failing to refresh - if it’s transient it’s
probably not a big deal. If it continues then there may be an issue with the
cache refresher.
--
Jeff Jirsa
> On May 12, 2018, at 5:55 AM, Abdul Patel wrote:
>
&g
The read is timing out - is the cluster healthy? Is it fully upgraded or mixed
versions? Repeated isn’t great, but is the application impacted?
--
Jeff Jirsa
> On May 12, 2018, at 6:17 AM, Abdul Patel wrote:
>
> Seems its coming from 3.10, got bunch of them today for 3.11.2, so i
ter replacement (true in general)
--
Jeff Jirsa
> On May 12, 2018, at 5:27 AM, onmstester onmstester
> wrote:
>
> Thank you Nitan,
> That's exactly my case (RF > CL). But as long as there is no node outage,
> shouldn't the hinted handoff handle data cons
RF of one means all auth requests go to the same node, so they’re more likely
to time out if that host is overloaded or restarts
Increasing it distributed the queries among more hosts
--
Jeff Jirsa
> On May 12, 2018, at 6:11 AM, Abdul Patel wrote:
>
> Yeah found that all had 3 re
9:50 GMT-7, kooljava2
> wrote:
>
>
> Hello Jeff,
>
> 2.1.19 to 3.0.15.
>
> Thank you.
>
> On Thursday, 10 May 2018, 17:43:58 GMT-7, Jeff Jirsa
> wrote:
>
>
> Which minor version of 3.0
>
> --
> Jeff Jirsa
>
>
> On May 11, 2018, at 2:54
Interesting!
I suspect I know what the increased disk usage in TWCS, and it's a solvable
problem, the problem is roughly something like this:
- Window 1 has sstables 1, 2, 3, 4, 5, 6
- We start compacting 1, 2, 3, 4 (using STCS-in-TWCS first window)
- The TWCS window rolls over
- We flush (sstable
On Mon, May 14, 2018 at 11:04 AM, Lucas Benevides <
lu...@maurobenevides.com.br> wrote:
> Thank you Jeff Jirsa by your comments,
>
> How can we do this: "fix this by not scheduling the major compaction
> until we know all of the sstables in the window are available to be
Column index size in the yaml (increase it to trade GC pressure for disk IO)
If you’re on anything other than 3.11.x, upgrade to 3.11.newest
--
Jeff Jirsa
> On May 19, 2018, at 8:42 PM, onmstester onmstester
> wrote:
>
> Hi,
> Due to some unpredictable behavior in inpu
In versions before 3.0, sstables were written with a -tmp filename and
copied/moved to the final filename when complete. This changes in 3.0 - we
write into the file with the final name, and have a journal/log to let uss
know when it's done/final/live.
Therefore, you can no longer just watch for a
https://issues.apache.org/jira/browse/CASSANDRA-13983 was added to
cassandra 4.0
On Fri, May 25, 2018 at 8:24 AM, Nitan Kainth wrote:
> Hi,
>
> I would like to log all C* queries hitting cluster. Could someone please
> tell me how can I do it at cluster level?
> Will nodetool setlogginglevel w
There’s a third option which is doing bucketing by time instead of by hash,
which tends to perform quite well if you’re using TWCS as it makes it quite
likely that a read can be served by a single sstable
--
Jeff Jirsa
> On May 29, 2018, at 6:49 AM, sujeet jog wrote:
>
> Folks,
, it’s possible a bad disk or bit flip could have corrupted
some of your data, but hard to say much beyond that.
--
Jeff Jirsa
> On May 30, 2018, at 3:42 PM, Charulata Sharma (charshar)
> wrote:
>
> Hi,
>
> I am observing a very strange behavior in our cluster. Metadata is
277 TB/day seems like the type of task I'd not trust to random mailing list
advice.
Cassandra can do that, but it's nontrivial. MongoDB may be able to do it,
too (not sure). A lot of it will depend on how you're trying to query the
data.
On Thu, May 31, 2018 at 9:00 AM, Sudhakar Ganesan <
sudha
There have been a few people who have reported it, but nobody (yet) has
offered a patch to fix it. It would be good to have a reliable way to
repro, and/or an analysis of a heap dump demonstrating the problem (what's
actually retained at the time you're OOM'ing).
On Mon, Jun 4, 2018 at 6:52 AM, Ab
On Thu, Jun 7, 2018 at 9:12 AM, Nitan Kainth wrote:
> Riccardo,
>
> Simplest method can be is to add VPC as an additional datacenter to
> existing cluster; once New DC has synced up all data, just switch over your
> application. Only caveat is that there should be enough network bandwidth
> betwe
up new snitch
> protocol right?
>
> On Thu, Jun 7, 2018 at 12:15 PM, Jeff Jirsa wrote:
>
>>
>>
>>
>> On Thu, Jun 7, 2018 at 9:12 AM, Nitan Kainth
>> wrote:
>>
>>> Riccardo,
>>>
>>> Simplest method can be is to add VPC a
> On Jun 9, 2018, at 10:28 PM, onmstester onmstester
> wrote:
>
>
> I'm using RF=2 (i know it should be at least 3 but i'm short of resources)
> and WCl=ONE and RCL=ONE in a cluster of 10 nodes in a insert-only scenario.
> The problem: i dont want to use nodetool repair because it would pu
- repair is a smaller problem than RF=2 and writing at
ONE
--
Jeff Jirsa
> On Jun 9, 2018, at 10:52 PM, onmstester onmstester
> wrote:
>
> Thanks Jeff,
> If i run repair every 10 days, then, would there be a chance of losing data
> by losing one node (data inserted exactly
Let's talk about what the real limitations are. There are two here that you
should care about:
1) Cassandra runs in the JVM. When you read and write to Cassandra, those
objects end up in the heap as byte arrays. If you're regularly reading and
writing 100MB byte arrays, it's easy to see situations
No
--
Jeff Jirsa
> On Jun 11, 2018, at 7:49 AM, Fd Habash wrote:
>
> I will check for both.
>
> On a different subject, I have read some user testimonies that running
> ‘nodetool cleanup’ requires a C* process reboot at least around 2.2.
JBOD before 3.6 or so mixed data between disks in a way that if one disk
failed, you needed to treat them all as failed and replace the host
--
Jeff Jirsa
> On Jun 12, 2018, at 1:53 AM, Kyrylo Lebediev wrote:
>
> Also it worth noting, that usage of JBOD isn't recomme
The most likely explanation is tombstones in files that won’t be collected as
they potentially overlap data in other files with a lower timestamp (especially
true if your partition key doesn’t change and you’re writing and deleting data
within a partition)
--
Jeff Jirsa
> On Jun 19, 2
young gen size, the first example is probably no
problem even with dozens of concurrent reads, but the second will trigger a
young gc every 10-15 reads (could be promotion, depending on how many
concurrent reads you’re doing).
--
Jeff Jirsa
> On Jun 19, 2018, at 1:53 AM, Vsevolod Filare
It's in the middle of trying to replay the unfinished compaction logs -
there's a file in your data directories that will end with .log - can you
paste the contents somewhere like pastebin/gist?
On Tue, Jun 19, 2018 at 7:42 AM, Deniz Acay wrote:
> I checked file system integrity and contents.
rsync while running. Stop. Rsync again. Start.
--
Jeff Jirsa
> On Jun 24, 2018, at 1:05 PM, Nitan Kainth wrote:
>
> Yeah you are right Pradeep. I overlooked the point there.
>
> Sent from my iPhone
>
>> On Jun 24, 2018, at 1:10 PM, Pradeep Chhetri wrote:
&g
hard caps (unless you know
what you’re doing).
--
Jeff Jirsa
> On Jun 27, 2018, at 3:11 PM, ZAIDI, ASAD A wrote:
>
> With Leveled compaction strategy , you can set target size with
> sstable_size_in_mb attribute however actual size can still be larger than
> target given
Try again and this time don’t remove tables during bootstrap (the streaming
code doesn’t handle removing tables very well).
--
Jeff Jirsa
> On Jun 27, 2018, at 7:30 PM, dayu wrote:
>
> Hi everyone
> I am joining a new node to a cluster. but it failed even if I use
> nod
That log message says you did:
CF 53f6d520-2dc6-11e8-948d-ab7caa3c8c36 was dropped during streaming
If you’re absolutely sure you didn’t, you should look for schema mismatches in
your cluster
--
Jeff Jirsa
> On Jun 27, 2018, at 7:49 PM, dayu wrote:
>
> CF 53f6d520-2dc6-
any real tables?
--
Jeff Jirsa
> On Jun 27, 2018, at 7:58 PM, dayu wrote:
>
> That sound reasonable, I have seen schema mismatch error before.
> So any advise to deal with schema mismatches?
> Dayu
>
> At 2018-06-28 09:50:37, "Jeff Jirsa" wrote:
> >That
The single node in 1e will be a replica for every range (and you won’t be able
to tolerate an outage in 1c), potentially putting it under significant load
--
Jeff Jirsa
> On Jun 28, 2018, at 7:02 AM, Randy Lynn wrote:
>
> I have a 6-node cluster I'm migrating to the new i3 t
No - they'll hardlink into the snapshot folder on each data directory. They
are true hardlinks, so even if you could move it, it'd still be on the same
filesystem.
Typical behavior is to issue a snapshot, and then copy the data out as
needed (using something like https://github.com/JeremyGrosser/t
3.0.14.10 reads like a Datastax version - I know there’s a few reports of
recyclers not working great in 3.11.x but haven’t seen many heap related leak
concerns with 3.0.14
--
Jeff Jirsa
> On Jun 30, 2018, at 5:49 PM, Tunay Gür wrote:
>
> Dear Cassandra users,
>
> I'm observ
Dropped mutations are load shedding - somethings not happy.
Are you seeing GC pauses?
What heap size and version?
What memtable settings ?
--
Jeff Jirsa
> On Jul 2, 2018, at 12:48 AM, Hannu Kröger wrote:
>
> Yes, there are timeouts sometimes but more on the read side. And y
Its a stable API - the project doesn’t ship a Kafka connector but certainly
people have written them
--
Jeff Jirsa
> On Jul 2, 2018, at 6:50 PM, Kant Kodali wrote:
>
> Hi Justin,
>
> Thanks, Looks like a very early stage feature and no integration with Kafka
> yet I su
resolution you’re
using on writes
--
Jeff Jirsa
> On Jul 4, 2018, at 11:08 AM, Anshul Rathore wrote:
>
>
> Hi
>
> We are using 4 node cassandra 3.10 cluster.
> For some reason autocompaction is not running on one of the table which uses
> DTCS. TTL on this tabl
Either of those solutions are fine, you just need to consider
throttling/limiting the number of concurrent queries (either in the
application, or on the server side) to avoid timeouts.
On Thu, Jul 5, 2018 at 11:16 AM, Goutham reddy
wrote:
> Hi users,
> Querying multiple primary keys can be ach
steps to repro
--
Jeff Jirsa
> On Jul 5, 2018, at 6:39 PM, James Shaw wrote:
>
> other concerns:
> there is no replication between 2.11 and 3.11, store in hints, and replay
> hints when remote is same version. have to do repair if over window. if read
> quorum 2/3, will
> On Jul 5, 2018, at 12:45 PM, Anuj Wadehra
> wrote:
>
> Hi,
>
> I woud like to know how people are doing rolling upgrade of Casandra clustes
> when there is a change in native protocol version say from 2.1 to 3.11.
> During rolling upgrade, if client application is restarted on nodes, the
You probably have a very large partition in that file. Nodetool cfstats
will show you the largest compacted partition now - I suspect it's much
higher than before.
On Thu, Jul 5, 2018 at 9:50 PM, atul atri wrote:
> Hi Chris,
>
> Compaction process finally finished. It took long time though.
>
>
On Tue, Jul 10, 2018 at 8:29 AM, Code Wiget wrote:
> Hi,
>
> I have been tasked with picking and setting up a database with the
> following characteristics:
>
>- Ultra-high availability - The real requirement is uptime - our whole
>platform becomes inaccessible without a “read” from the d
For tracking delay in very recent versions, this exists:
https://issues.apache.org/jira/browse/CASSANDRA-13289
--
Jeff Jirsa
> On Jul 11, 2018, at 1:05 AM, Simon Fontana Oscarsson
> wrote:
>
> I thought you just wanted to test how big delay you have, that's why I
Probably close - maybe file handles or map counts. ulimit -a and/or
cat /proc/sys/vm/max_map_count
Would be useful
--
Jeff Jirsa
> On Jul 12, 2018, at 3:47 AM, Hannu Kröger wrote:
>
> Could the problem be that the process ran out of file handles? Recommendation
> is to tune
if you have multiple (lots of) disks and are running Cassandra before
CASSANDRA-6696 (which made jbod safer).
--
Jeff Jirsa
> On Jul 12, 2018, at 7:37 AM, Vitaliy Semochkin wrote:
>
> Hi,
>
> Which amount of data Cassandra 3 server in a cluster can serve at max?
> The doc
Should not need regular reboots for Cassandra’s sake, but you should be
regularly patching your servers
--
Jeff Jirsa
> On Jul 17, 2018, at 2:09 AM, Vsevolod Filaretov wrote:
>
> Good time of day everyone;
>
> Does Cassandra have a "recommended uptime"? I.e., do
--
Jeff Jirsa
> On Jul 17, 2018, at 5:35 PM, Eunsu Kim wrote:
>
> Can I ask you an additional question here?
>
> How much free space should I have if most tables use
> TimeWindowCompactionStrategy?
>
>
>> On 13 Jul 2018, at 10:09 PM, Vitaliy Semochkin wrote:
&g
There are 4+ implementations of CQL in addition to Apache Cassandra - the
ones I can think of off the top of my head include DSE, Yugabyte, CosmosDB,
and Scylla.
You'll want to define "popular". If by popular you mean "which
implementation of CQL has the most installed servers", nobody knows for
s
It will (did) slow, but it didn’t (won’t) stop. There’s some really interesting
work in the queue, like
https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-14404 ,
that should make a lot of users very happy.
--
Jeff Jirsa
> On Jul 19, 2018, at 6:59 AM, Vitaliy Semoch
Anything in non-Cassandra logs? Dmesg?
--
Jeff Jirsa
> On Jul 21, 2018, at 11:07 PM, onmstester onmstester
> wrote:
>
> Cassandra in one of my nodes, crashed without any error/warning in
> system/gc/debug log. All jmx metrics is being monitored, last fetched values
> fo
If I were you I’d disable that warning (or set it much higher).
--
Jeff Jirsa
> On Jul 25, 2018, at 7:32 PM, R1 J1 wrote:
>
> cassandro nodes restarts
>
>
>
> we see errors typically like these
>
>
> WARN [Native-Transport-Requests-3] 2018-07-25 20:51:38,
sstables? How big is your heap? Are you already serving
traffic?
--
Jeff Jirsa
> On Jul 29, 2018, at 3:43 PM, Rahul Singh wrote:
>
> What does “hash” Data look like?
>
> Rahul
>> On Jul 24, 2018, 11:30 AM -0400, Arpan Khandelwal ,
>> wrote:
>> I need to clone
This is safe (and normal, and good) in all versions except those impacted
by https://issues.apache.org/jira/browse/CASSANDRA-13004
So if you're on 2.1, 2.2, or 3.11 you're fine
If you're on 3.0 between 3.0.0 and 3.0.13, you should upgrade first (to
newest 3.0, probably 3.0.17)
If you're on a vers
EBS encryption worked well on gp2 volumes (never tried it on any others)
--
Jeff Jirsa
> On Aug 1, 2018, at 7:57 AM, Rahul Reddy wrote:
>
> Hello,
>
> Any one tried aws ec2 volume encryption for Cassandra instances?
>
>> On Tue, Jul 31, 2018, 12:25 PM Rahu
think you should be afraid of either)
--
Jeff Jirsa
> On Aug 1, 2018, at 6:43 PM, Visa wrote:
>
> Thanks for all the inputs! We’ll stick to the current approach then.
>
> How about dropping columns - If we also stop writes beforehand, we should be
> safe from data ali
; there are 4 strategies but size
tiered is default and easiest to understand.
You’re seeing mostly writes because the reads are likely in page cache (the
kernel doesn’t need to go to disk to read the files, it’s got them in memory
for serving normal reads).
--
Jeff Jirsa
> On Aug 3, 2
Are you using materialized views or secondary indices?
--
Jeff Jirsa
> On Aug 6, 2018, at 3:49 PM, Laszlo Szabo
> wrote:
>
> Hello All,
>
> I'm having JVM unstable / OOM errors when attempting to auto bootstrap a 9th
> node to an existing 8 node cluster (256 tok
objects, we may be able to figure out what’s going on
--
Jeff Jirsa
> On Aug 6, 2018, at 5:42 PM, Jeff Jirsa wrote:
>
> Are you using materialized views or secondary indices?
>
> --
> Jeff Jirsa
>
>
>> On Aug 6, 2018, at 3:49 PM, Laszlo Szabo
>> wrote:
d latency: 6.094 ms
> Local write count: 250971
> Local write latency: 0.024 ms
> Pending flushes: 0
> Percent repaired: 0.0
> Bloom filter false positives: 0
> Bloom filter false ratio: 0.0
> Bloom filter space used: 1709848
> Bloom filter off heap memory used: 1709824
&
You could toggle off the tombstone compaction to see if that helps, but that
should be lower priority than normal compactions
Are the lots-of-little-files from memtable flushes or repair/anticompaction?
Do you do normal deletes? Did you try to run Incremental repair?
--
Jeff Jirsa
>
May be worth seeing if any of the sstables got promoted to repaired - if so
they’re not eligible for compaction with unrepaired sstables and that could
explain some higher counts
Do you actually do deletes or is everything ttl’d?
--
Jeff Jirsa
> On Aug 7, 2018, at 5:09 PM, Brian Spind
Agreed about deflate.
Also you can adjust your chunk size, which may help ratios as well,
especially if you expect your data to compress well - often larger chunks
will compress better, but it depends on the nature of your data.
In the near future, look for work from Sushma @ Instagram to make av
disk and run repair - 6696 will
keep data for a given token range all on the same disks, so the resurrection
problem is solved.
--
Jeff Jirsa
> On Aug 14, 2018, at 6:10 AM, Christian Lorenz
> wrote:
>
> Hi,
>
> given a cluster with RF=3 and CL=LOCAL_ONE and applicatio
3.0 has a (optional?) feature to guarantee better distribution, and the blog
focuses on 2.2.
Using fewer will minimize your risk of unavailability if any two hosts fail.
--
Jeff Jirsa
> On Aug 29, 2018, at 11:18 AM, Max C. wrote:
>
> Hello Everyone,
>
> Datastax recomm
Is the bootstrap plan succeeding (does streaming start or does it crash before
it logs messages about streaming starting)?
Have you capped the stream throughput on the existing hosts?
--
Jeff Jirsa
> On Aug 29, 2018, at 5:02 PM, Jai Bheemsen Rao Dhanwada
> wrote:
>
> Hello
that’s awful. Hopefully either of the two above JIRAs lands to make this
less awful.
--
Jeff Jirsa
> On Aug 29, 2018, at 6:29 PM, Jai Bheemsen Rao Dhanwada
> wrote:
>
> It fails before bootstrap
>
> streaming throughpu on the nodes is set to 400Mb/ps
>
>> On
CMS is fine at 12G for sure, likely up to 16G
You’ll want to initiate CMS a bit earlier (55-69%), and you likely want new gen
to be larger - perhaps 3-6G
You’ll want to manually set the memtable size - it scales with heap by default
After bootstrap you can lower it again
--
Jeff Jirsa
You’re seeing an OOM, not a socket error / timeout.
--
Jeff Jirsa
> On Aug 29, 2018, at 10:56 PM, Jai Bheemsen Rao Dhanwada
> wrote:
>
> Jeff,
>
> any idea if this is somehow related to :
> https://issues.apache.org/jira/browse/CASSANDRA-11840?
> does
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 10
1 - 100 of 1035 matches
Mail list logo
