We have some cassandra tables that have undergone extensive modification
over the life of our application. This has lead to a significant alter
table history. It is my understanding that this history is necessary to
process sstables that may contain columns that might have been removed.
Due to
Did you roll back to OpenJDK 1.7u181 or did you upgrade to a more recent
version?
On Thu, 16 May 2019 at 13:43, keshava wrote:
> The java version that we were using and which turns out to be causing this
> issue was OpenJdk 1.7 u191
>
> On 16-May-2019 06:02, "sankalp kohli" wrote:
>
>> which
I've decreased bloom_filter_fp_chance from 0.01 to 0.001. The
sstableupgrade took 3 days to complete. And this is a result:
node1
Bloom filter false positives: 380965
Bloom filter false ratio: 0.46560
Bloom filter space used: 27.1 MiB
The issue is fixed with nodetool scrub, now both rows are under the same
clustering.
I'll open a jira to analyze the source of this issue with Cassandra 3.11.3
Thanks.
Le jeu. 16 mai 2019 à 04:53, Jeff Jirsa a écrit :
> I don’t have a good answer for you - I don’t know if scrub will fix this
