On Tue, Sep 18, 2018 at 10:38 AM Steinmaurer, Thomas <
thomas.steinmau...@dynatrace.com> wrote:
>
> any indications in Cassandra log about insufficient disk space during
> compactions?
>
Bingo! The following was logged around the time compaction was started
(and I only looked around when it was
Allright, coming back after some homeworks. Thank you Alain
About hardware:
m1.xlarge 4vcpu 15GB ram
- 4 spinning disks configured in raid0
#About compactors:
- I 've moved them back to 2 concurrent compactors. I can say in general I
don't see more than 80-ish pending compactions (during
Alex,
any indications in Cassandra log about insufficient disk space during
compactions?
Thomas
From: Oleksandr Shulgin
Sent: Dienstag, 18. September 2018 10:01
To: User
Subject: Major compaction ignoring one SSTable? (was Re: Fresh SSTable files
(due to repair?) in a static table (was Re:
On Mon, Sep 17, 2018 at 4:41 PM Jeff Jirsa wrote:
> Marcus’ idea of row lifting seems more likely, since you’re using STCS -
> it’s an optimization to “lift” expensive reads into a single sstable for
> future reads (if a read touches more than - I think - 4? sstables, we copy
> it back into the
On Mon, Sep 17, 2018 at 4:29 PM Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
>
> Thanks for your reply! Indeed it could be coming from single-SSTable
> compaction, this I didn't think about. By any chance looking into
> compaction_history table could be useful to trace it down?
>
You shouldn’t need to. You just scale up and run ”nodetool cleanup” and that
will take care of it.
Hannu
> onmstester onmstester kirjoitti 18.9.2018 kello 8.52:
>
> By adding new nodes to cluster, should i rebuild SASI indexes on all nodes ?
>
>
Hello,
Thank you ! I appreciate your help.
On Tue, Sep 18, 2018, 17:35 Joseph Arriola wrote:
> Hi, the nodes are still communicating because they have not yet done the
> logical separation, this is done by changing the snitch for each node in
> the cluster in the cassandra.yaml file of the
Hi, the nodes are still communicating because they have not yet done the
logical separation, this is done by changing the snitch for each node in
the cluster in the cassandra.yaml file of the node and then changing the
name of the DC in cassandra-rackdc.properties. It is very important to do a
Hello everyone,
I am facing a problem with my 2 Cassandra Clusters. In fact, I created the
first one and it does contain 5 nodes. After that, I created the second one
as a duplicate of the first. I changed the seeds parameters and I was
assuming that the first cluster will not communicate with
This is because Cassandra sets -XX:+PerfDisableSharedMem JVM option by default.
This prevents tools such as jps to list jvm processes.
See https://issues.apache.org/jira/browse/CASSANDRA-9242 for detail.
You can work around by doing what Riccardo said.
On Tue, Sep 18, 2018 at 9:41 PM Philip Ó
The client should notice this on their side . If you want to see on the
server log one idea may be is to enable the debug mode .
You can set it specifically for org.apache.cassandra.transport
Something like nodetool setlogginglevel org.apache.cassandra.transport
DEBUG
If you are lucky enough :)
On Mon, Sep 17, 2018 at 10:52 PM onmstester onmstester
wrote:
> By adding new nodes to cluster, should i rebuild SASI indexes on all nodes
> ?
>
It isn’t necessary and will result in redundant work. On new nodes the
indexes will be built as data is streamed in. On existing nodes, compaction
or
Hi All,
I need a little advice. I'm trying to access the JMX terminal using
*jmxterm-1.0-alpha-4-uber.jar* with a very simple default install of C*
3.11.3
I keep getting the following:
[cassandra@reaper-1 conf]$ java -jar jmxterm-1.0-alpha-4-uber.jar
Welcome to JMX terminal. Type "help" for
problem would be that for every file you flush, you would recompact all of
L1 - files are flushed to L0, then compacted together with all overlapping
files in L1.
On Tue, Sep 18, 2018 at 4:53 AM 健 戴 wrote:
> Hi,
>
> I have one table having 2T data saved in c* each node.
> And if using LCS, the
Further info:
I would expect to see the following when I list the jvm's:
Welcome to JMX terminal. Type "help" for available commands.
$>jvms
*25815(m) - org.apache.cassandra.service.CassandraDaemon*
17628( ) - jmxterm-1.0-alpha-4-uber.jar
But jmxtem is not picking up the JVM for
You are correct that altering the keyspace replication settings does not
actually move any data. It only affects new writes or reads. System_auth is one
that needs to be repaired quickly OR, if your number of users/permissions is
relatively small, you can just reinsert them after the alter to
Hi Philip,
I've used jmxterm myself without any problems particular problems. On my
systems too, I don't get the cassandra daemon listed when issuing the
`jvms` command but I never spent much time investigating it.
Assuming you have not changed anything relevant in the cassandra-env.sh you
can
Hi Riccardo,
Yes that works for me:
Welcome to JMX terminal. Type "help" for available commands.
$> open localhost:7199
#Connection to localhost:7199 is opened
$>domains
#following domains are available
JMImplementation
ch.qos.logback.classic
com.sun.management
java.lang
java.nio
Wouldn’t you have the same problem with two similar tables with different
primary keys (eg., UserByID and UserByName)? This is a very common pattern in
Cassandra – inserting into multiple tables… That’s what batches are for –
atomicity.
I don’t understand the additional concern here.
Sean
19 matches
Mail list logo
