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: 
 <CA+1dbhM=v7fwbrPrf7jnDDi4M6_pNp7vO2xRdGLzq6SGyOvCxw@mail.gmail.com>
References: <565DADBA.9080605@akamai.com>
	<CA+1dbhM=v7fwbrPrf7jnDDi4M6_pNp7vO2xRdGLzq6SGyOvCxw@mail.gmail.com>
Date: Tue, 1 Dec 2015 13:58:05 -0800
Message-ID: 
 <CANeMN=-9gYxjjv1SdPtAqwJC7SUR_7+EPn6sAefdwH7OF=_36A@mail.gmail.com>
Subject: Re: Transitioning to incremental repair
From: Bryan Cheng <bryan@blockcypher.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=089e0111c3c0a3d76a0525dd40ac

--089e0111c3c0a3d76a0525dd40ac
Content-Type: text/plain; charset=UTF-8

Sorry if I misunderstood, but are you asking about the LCS case?

Based on our experience, I would absolutely recommend you continue with the
migration procedure. Even if the compaction strategy is the same, the
process of anticompaction is incredibly painful. We observed our test
cluster running 2.1.11 experiencing a dramatic increase in latency and not
responding to nodetool queries over JMX while anticompacting the largest
SSTables. This procedure also took several times longer than a standard
full repair.

If you absolutely cannot perform the migration procedure, I believe 2.2.x
contains the changes to automatically set the RepairedAt flags after a full
repair, so you may be able to do a full repair on 2.2.x and then transition
directly to incremental without migrating (can someone confirm?)

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

<div dir=3D"ltr"><div class=3D"gmail_extra">Sorry if I misunderstood, but a=
re you asking about the LCS case?</div><div class=3D"gmail_extra"><br></div=
><div class=3D"gmail_extra">Based on our experience, I would absolutely rec=
ommend you continue with the migration procedure. Even if the compaction st=
rategy is the same, the process of anticompaction is incredibly painful. We=
 observed our test cluster running 2.1.11 experiencing a dramatic increase =
in latency and not responding to nodetool queries over JMX while anticompac=
ting the largest SSTables. This procedure also took several times longer th=
an a standard full repair.</div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">If you absolutely cannot perform the migration procedu=
re, I believe 2.2.x contains the changes to automatically set the RepairedA=
t flags after a full repair, so you may be able to do a full repair on 2.2.=
x and then transition directly to incremental without migrating (can someon=
e confirm?)</div></div>

--089e0111c3c0a3d76a0525dd40ac--