Read exceptions after upgrading to 3.0.10

Hello, We have a 6 node cluster which was recently upgraded from 2.2.5 to 3.0.10. Since then, we have been facing a lot of these exceptions. What could be the possible cause for this exception? INFO [SharedPool-Worker-2] 2017-02-23 20:14:04,984 Message.java:611 - Unexpected exception during

RE: 2.1 to 3.0 upgrade problems

client is on an older incompatible java driver. Upgrade the java driver to be compatible with your Cassandra version. Hope that helps. Thanks, Meg Mara -Original Message- From: Eric Yablonowitz [mailto:er...@jana.com] Sent: Tuesday, March 28, 2017 9:48 PM To: user@cassandra.apache.org

Error Exception in Repair Thread

] at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116) ~[guava-18.0.jar:na] at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:261) ~[apache-cassandra-3.0.10.jar:3.0.10] ... 5 common frames omitted Thank you, Meg Mara

RE: Hints files are not getting truncated

but we have never faced any major issues apart from some dropped mutation messages from time to time. I will consider your advice about turning off hints. Thank you, Meg Mara From: Hannu Kröger [mailto:hkro...@gmail.com] Sent: Tuesday, June 27, 2017 11:37 AM To: Meg Mara <mm...@digitalriver.

RE: Hints files are not getting truncated

the performance improvement of increasing the threads for the hint delivery. Thank you, Meg Mara From: Anuj Wadehra [mailto:anujw_2...@yahoo.co.in.INVALID] Sent: Tuesday, June 27, 2017 11:56 AM To: user@cassandra.apache.org Subject: Re: Hints files are not getting truncated Hi Meg

Hints files are not getting truncated

or recommendations would be much appreciated. Thanks for your time. Meg Mara

RE: Tombstone warnings in log file

Simon, It means that in processing your queries, Cassandra is going through that many tombstone cells in order to return your results. It is because some of the partitions that you are querying for have already expired. The warning is just cassandra's way of letting you know that your reads

inc repairs aren't updating repairedat timestamp

-at timestamp never getting updated? What is the solution to this apart from moving to Cassandra 3.0.14 (not feasible for me at the moment.)? I'd appreciate any answers. Thank you, Meg Mara

RE: how to identify the root cause of cassandra hang

to see if your GC pauses are happening too often. Grep for GCInspector in system.log. Could be a possibility. Meg Mara From: Peng Xiao [mailto:2535...@qq.com] Sent: Thursday, October 26, 2017 9:24 AM To: user <user@cassandra.apache.org> Subject: how to identify the root cause of cassandr

RE: cassandra non-super user login fails but super user works

You should probably verify if the ‘can_login’ field of the non-superuser role is set to true. You can query the column family system_auth.roles to find out. Thanks, Meg Mara From: Justin Cameron [mailto:jus...@instaclustr.com] Sent: Sunday, October 22, 2017 6:21 PM To: user@cassandra.apache.org

RE: how to check C* partition size

Nodetool tablestats gives you a general idea. Meg Mara From: Peng Xiao [mailto:2535...@qq.com] Sent: Sunday, January 07, 2018 9:26 AM To: user <user@cassandra.apache.org> Subject: how to check C* partition size Hi guys, Could anyone please help on this simple question? How to c

RE: TWCS: Repair create new buckets with old data

ent with the application. The repair is started each day on one of ten hosts with command : nodetool --host hostname_# repair –pr Regards Maik From: Meg Mara [mailto:mm...@digitalriver.com] Sent: Dienstag, 23. Oktober 2018 17:05 To: user@cassandra.apache.org<mailto:user@cassandra.apache.org>

RE: TWCS: Repair create new buckets with old data

Hi Maik, I noticed in your table description that your default_time_to_live = 0, so where is your TTL property set? At what point do your sstables get tombstoned? Also, could you please mention what kind of repair you performed on this table? (Incremental, Full, Full repair with -pr option)

RE: TWCS: Repair create new buckets with old data

ss you're dropping a lot of mutations. It's not perfect but should cause less headache than incremental repair will. Hope this helps. Jon On Thu, Oct 25, 2018 at 4:21 AM Meg Mara mailto:mm...@digitalriver.com>> wrote: Hi Maik, I have a similar Cassandra env, with similar table requirements. So

Commit Log sync problems

: /cassandra/log commitlog_segment_size_in_mb: 32 commitlog_sync: periodic commitlog_sync_period_in_ms: 1 commitlog_total_space_in_mb: 4096 Thank you, Meg Mara