Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 15 Oct 2015 12:58:06 +0000 (UTC)
From: =?utf-8?Q?Fernando_Gon=C3=A7alves_=28JIRA=29?= <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12742136.1410960604000.47591.1444913886241@Atlassian.JIRA>
In-Reply-To: <JIRA.12742136.1410960604000@Atlassian.JIRA>
References: <JIRA.12742136.1410960604000@Atlassian.JIRA>
 <JIRA.12742136.1410960604025@arcas>
Subject: [jira] [Commented] (CASSANDRA-7953) RangeTombstones not merging
 during compaction
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-7953?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14958849#comment-14958849 ]=20

Fernando Gon=C3=A7alves commented on CASSANDRA-7953:
-----------------------------------------------

We have experienced the same behaviour described on ticket [https://issues.=
apache.org/jira/browse/CASSANDRA-10505]: "Once this happens in multiple sst=
ables, compacting them causes the duplication to grow. The more this occurs=
, the worse the problem gets."

Basically, when we run the repair in the node, the compaction process start=
s and never ends, many pending tasks, and the number of sstables of one tab=
le grows exponentially (reaching 34k sstables). We use one column of the ty=
pe map<text, text>, LeveledStrategyCompaction, and many updates to this col=
umn. The memory consumption grows a lot too. We decide to stop the repair p=
rocess and kill the node, because the latency grown a lot too and impact th=
e whole cluster. But we need to run repair again, because we kill one node =
and put a new node on the cluster, and another node was impacted from this =
bug again, and we need to repeated the process: kill the repair process, ki=
ll the node, start a new node.

So we just created another table without using the collection map, but usin=
g blob type instead, and migrate all the data for it - we are fine now: the=
 repair process and compaction finished successfully without big impact on =
performance.

Please, give attention for this ticket, I think that its a major issue!

> RangeTombstones not merging during compaction
> ---------------------------------------------
>
>                 Key: CASSANDRA-7953
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7953
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Cassandra 2.1
>            Reporter: Marcus Olsson
>            Assignee: Branimir Lambov
>            Priority: Minor
>              Labels: compaction, deletes, tombstone
>             Fix For: 2.1.x, 2.2.x
>
>         Attachments: 0001-7953-v2.patch, CASSANDRA-7953-1.patch, CASSANDR=
A-7953.patch
>
>
> When performing a compaction on two sstables that contain the same RangeT=
ombstone with different timestamps, the tombstones are not merged in the ne=
w sstable.
> This has been tested using cassandra 2.1 with the following table:
> {code}
> CREATE TABLE test(
>   key text,
>   column text,
>   data text,
>   PRIMARY KEY(key, column)
> );
> {code}
> And then doing the following:
> {code}
> INSERT INTO test (key, column, data) VALUES ("1", "1", "1"); // If the ss=
table only contains tombstones during compaction it seems that the sstable =
either gets removed or isn't created (but that could probably be a separate=
 JIRA issue).
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2"); // The inser=
ts are not actually needed, since the deletes create tombstones either way.
> DELETE FROM test WHERE key=3D"1" AND column=3D"2";
> nodetool flush
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2");
> DELETE FROM test WHERE key=3D"1" AND column=3D"2";
> nodetool flush
> nodetool compact
> {code}
> When checking with the SSTableExport tool two tombstones exists in the co=
mpacted sstable. This can be repeated, resulting in more and more tombstone=
s.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)