Re: Stale value appears after consecutive TRUNCATE

Hi Yuji, ok, perhaps you are seeing a different issue than I do. Have you tried with durable_writes=False? If the issue is caused by the commitlog, then it should work if you disable durable_writes. Cheers, Christian On Tue, Aug 9, 2016 at 3:04 PM, Yuji Ito wrote: >

migrating from 2.1.2 to 3.0.8 log errors

Hi guys, We have migrated our cluster (5 nodes in DC1 and 5 nodes in DC2) from cassandra 2.1.2 to 3.0.8, all seems fine, executing nodetool status shows all nodes UN, but in each node's log there is this log error continuously: java.io.IOException: Error while read(...): Connection reset by peer

Re : Default values in Cassandra YAML file

hi; if there are any missed attributes in the YAML file, will Cassandra pick up default values for those attributes. thanks

Re: migrating from 2.1.2 to 3.0.8 log errors

That just means that a client/driver disconnected. Those log messages are supposed to be suppressed, but perhaps that stopped working in 3.x due to another change. On Wed, Aug 10, 2016 at 10:33 AM, Adil wrote: > Hi guys, > We have migrated our cluster (5 nodes in DC1 and

Re: migrating from 2.1.2 to 3.0.8 log errors

Another thing to note is that according to NEWS.txt upgrade from 2.1.x is only supported from version 2.1.9, so if this is not an effect of that I'm actually surprised upgrade from 2.1.2 worked without any issues. 2016-08-10 15:48 GMT-03:00 Tyler Hobbs : > That just means

Re: Re : Default values in Cassandra YAML file

thanks Romain, this had been a doubt for quiet a while. thanks On Wed, Aug 10, 2016 at 4:59 PM, Romain Hardouin wrote: > Yes. You can even see that some caution is taken in the code > https://github.com/apache/cassandra/blob/trunk/ >

Re: nodetool repair with -pr and -dc

ok thanks, so if we want to use -pr option ( which i suppose we should to prevent duplicate checks) in 2.0 then if we run the repair on all nodes in a single DC then it should be sufficient and we should not need to run it on all nodes across DC's ? On Wed, Aug 10, 2016 at 5:01 PM, Paulo Motta

Re: Re : Default values in Cassandra YAML file

Yes. You can even see that some caution is taken in the code  https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/Config.java#L131 (But if I were you I would not rely on this. It's always better to be explicit.) Best, Romain Le Mercredi 10 août 2016 17h50,

Re: migrating from 2.1.2 to 3.0.8 log errors

Thank you for your response, we have updated datastax driver to 3.1.0 using V3 protocol, i think there are still some webapp that still using the 2.1.6 java driver..we will upgrade thembut we noticed strange things, on web apps upgraded to 3.1.0 some queries return zero results even if data

nodetool repair with -pr and -dc

Hello, We have 2.0.17 cassandra cluster(*DC1*) with a cross dc setup with a smaller cluster(*DC2*). After reading various blogs about scheduling/running repairs looks like its good to run it with the following -pr for primary range only -st -et for sub ranges -par for parallel -dc to make sure

Re: Incremental repairs leading to unrepaired data

Not yet. Right now I have it set at 16. Would halving it more or less double the repair time? On Tue, Aug 9, 2016 at 7:58 PM, Paulo Motta wrote: > Anticompaction throttling can be done by setting the usual > compaction_throughput_mb_per_sec knob on cassandra.yaml or

Re: nodetool repair with -pr and -dc

On 2.0 repair -pr option is not supported together with -local, -hosts or -dc, since it assumes you need to repair all nodes in all DCs and it will throw and error if you try to run with nodetool, so perhaps there's something wrong with range_repair options parsing. On 2.1 it was added support to

Re: Incremental repairs leading to unrepaired data

That's pretty low already, but perhaps you should lower to see if it will improve the dropped mutations during anti-compaction (even if it increases repair time), otherwise the problem might be somewhere else. Generally dropped mutations is a signal of cluster overload, so if there's nothing else

Re: Incremental repairs leading to unrepaired data

That's what I was thinking. Maybe GC pressure? Some more details: during anticompaction I have some CFs exploding to 1K SStables (to be back to ~200 upon completion). HW specs should be quite good (12 cores/32 GB ram) but, I admit, still relying on spinning disks, with ~150GB per node. Current