In documentation it is given that while running incremental repairs, anti
compaction is done which results in repaired and unrepaired sstables. Since
anti compaction also runs with full repair and primary range repairs, I
have the following
question:
Is anti compaction different in case of full r
Jeff, good to hear from you.
Based on what you're saying, we can avoid regular repairs on these tables.
We can live with the read repairs because the bulk of these tables are
being used strictly for analytics queries by Spark jobs or for ad-hoc
queries by members of the technical team. They're no
> On Nov 5, 2020, at 10:18 AM, Mitch Gitman wrote:
>
Hi!
>
> Now, we could comfortably run all the repairs we need to within our off-hours
> window if we just left out all our tables that are insert-only. By
> insert-only, I mean that we have certain classes of tables that we're only
>
With all the years I've been working with Cassandra, I'm embarrassed that I
have to ask this question.
We have some tables that are taking longer to repair than we're comfortable
with. We're on Cassandra 3.11, so we have to run full repairs as opposed to
incremental repairs, which to my understand
Hello Nicolai,
I am also looking to upgrade to 3.11.8. Is the latency you noticed is only
with TWCS? And others looks good?
On Thursday, November 5, 2020, Ahmed Eljami wrote:
> +1
> I would also be interested to know if the 3.11.9 provide any improvement
> for your case.
> Cheers.
>
> Le mer. 4
+1
I would also be interested to know if the 3.11.9 provide any improvement
for your case.
Cheers.
Le mer. 4 nov. 2020 à 14:53, Johannes Weißl a écrit :
> Hi Nico,
>
> On Mon, Sep 14, 2020 at 03:51PM +0200, Nicolai Lune Vest wrote:
> > after upgrading my Cassandra nodes from version 3.11.6 to ei
