Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
MIME-Version: 1.0
In-Reply-To: <CAKy_EwYd2+GM+aJtpo_j6YCctMLQqFYFD6dWMFYT97BsC+3-Vw@mail.gmail.com>
References: <CAKy_EwYd2+GM+aJtpo_j6YCctMLQqFYFD6dWMFYT97BsC+3-Vw@mail.gmail.com>
From: Paulo Motta <pauloricardomg@gmail.com>
Date: Tue, 9 Aug 2016 15:58:23 -0300
Message-ID: <CAKaZCX6KEFfM7XHCP_m1z5fJDj4MV5cUvrNTBupQKMFFMkFhsw@mail.gmail.com>
Subject: Re: Incremental repairs leading to unrepaired data
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Content-Type: multipart/alternative; boundary=94eb2c09248c3352980539a81fd3
archived-at: Tue, 09 Aug 2016 18:58:48 -0000

--94eb2c09248c3352980539a81fd3
Content-Type: text/plain; charset=UTF-8

Anticompaction throttling can be done by setting the usual
compaction_throughput_mb_per_sec knob on cassandra.yaml or via nodetool
setcompactionthroughput. Did you try lowering that  and checking if that
improves the dropped mutations?

2016-08-09 13:32 GMT-03:00 Stefano Ortolani <ostefano@gmail.com>:

> Hi all,
>
> I am running incremental repaird on a weekly basis (can't do it every day
> as one single run takes 36 hours), and every time, I have at least one node
> dropping mutations as part of the process (this almost always during the
> anticompaction phase). Ironically this leads to a system where repairing
> makes data consistent at the cost of making some other data not consistent.
>
> Does anybody know why this is happening?
>
> My feeling is that this might be caused by anticompacting column families
> with really wide rows and with many SStables. If that is the case, any way
> I can throttle that?
>
> Thanks!
> Stefano
>

--94eb2c09248c3352980539a81fd3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Anticompaction throttling can be done by setting the usual=
 compaction_throughput_mb_per_sec knob on cassandra.yaml or via nodetool se=
tcompactionthroughput. Did you try lowering that=C2=A0 and checking if that=
 improves the dropped mutations?<br></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">2016-08-09 13:32 GMT-03:00 Stefano Ortolani <span =
dir=3D"ltr">&lt;<a href=3D"mailto:ostefano@gmail.com" target=3D"_blank">ost=
efano@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>Hi all,</div><div><br></div><div>I am running incremental rep=
aird on a weekly basis (can&#39;t do it every day as one single run takes 3=
6 hours), and every time, I have at least one node dropping mutations as pa=
rt of the process (this almost always during the anticompaction phase). Iro=
nically this leads to a system where repairing makes data consistent at the=
 cost of making some other data not consistent.</div><div><br></div><div>Do=
es anybody know why this is happening?</div><div><br></div><div>My feeling =
is that this might be caused by anticompacting column families with really =
wide rows and with many SStables. If that is the case, any way I can thrott=
le that?</div><div><br></div><div>Thanks!</div><span class=3D"HOEnZb"><font=
 color=3D"#888888"><div>Stefano</div></font></span></div>
</blockquote></div><br></div>

--94eb2c09248c3352980539a81fd3--