Thanks Rob.
We have disabled firewalls between the nodes and yet getting the same error.
I have one more doubt. In our cluster we configured size tiered compaction
strategy on JBOD and we are facing issues like uneven distribution of data. Is
it possible to change compaction strategy of tables
Hi,
I think only LevelledCompactionStrategy makes sense on JBOD because that
can distribute data more evenly. Although I don't know what is the exact
strategy where each compaction strategy will store sstables. If you use
SizeTieredCompactionStrategy you might run into problems when sstables get
b
Yes Hannu, Initially for one month we didn't face any problem. But once tables
got bigger we are getting the disk space issues.
Can I change the compaction strategy. Will changing compaction strategy have an
impact on data consistency? Will it cause corruption of SSTable .
-Venkat
Date: Fri,
Hi,
Which part of EPEL is actually needed for C*? Is it possible to have only part
of it on machine, instead of whole repository?
Regards,
Basit
You can change it on the fly. That will just compact all the data that you have
so it will take a long time and cause some io load.
Hannu
> On 31.10.2014, at 14.07, venkat sam wrote:
>
>
> Yes Hannu, Initially for one month we didn't face any problem. But once
> tables got bigger we are get
I relaunched my cluster from the scratch (due to another reason). After the
relaunch I could ran nodetool repair -par -inc -pr on the nodes without
issue, but pretty match the moment when I started pushing production load
to the cluster I ran into the same problem again. I opened a ticket first
for
On Fri, Oct 31, 2014 at 8:55 AM, Juho Mäkinen
wrote:
> I can't yet call this conclusive, but it seems that I can't run
> incremental repairs on the current 2.1.1 and I'm still wondering if anybody
> else is experiencing the same problem.
>
You have repro steps, if I were you I would file an JIRA
Hello,
There is currently an issue with the apache debian repo for cassandra.
ASF infrastructure is working on fixing this
https://issues.apache.org/jira/browse/INFRA-8558
Sorry for the inconvenience.
-Jake
Well I tried the SafepointTimeout option, but unfortunately it seems like
the long safepoint syncs don't actually trigger the SafepointTimeout
mechanism, so we didn't get any logs on it. It's possible I'm just doing it
wrong, I used the following options:
JVM_OPTS="$JVM_OPTS -XX:+UnlockDiagnosticV
I have to admit that I haven’t tried the SafepointTimeout (I just noticed that
it was actually a production VM option in the JVM code, after my initial
suggestions below for debugging without it).
There doesn’t seem to be an obvious bug in SafepointTimeout, though I may not
be looking at the sa
10 matches
Mail list logo
