Jean, Have you considered nodetool repair -pr (primary range) OR reaper? With Reaper you can throttle repair load on system. These two uses ranges anyway, so you may not run into anti-compaction.
Regards, Nitan K. Cassandra and Oracle Architect/SME Datastax Certified Cassandra expert Oracle 10g Certified On Thu, May 24, 2018 at 5:44 AM, Jean Carlo <jean.jeancar...@gmail.com> wrote: > > Thanks alain and Lerh, It is clear now. > > In order to avoid problems and charge in the cluster doing > anticompactions, I am going to use repair by sub ranges. > > I studied this tool called cassandra-list-subranges > <https://github.com/pauloricardomg/cassandra-list-subranges> it seems it > still works for the versions 3.11.2. And I will take a look also to > cassandra_range_repair > <https://github.com/BrianGallew/cassandra_range_repair> which it is more > recent > > Do you have any remarks for cassandra-list-subranges > <https://github.com/pauloricardomg/cassandra-list-subranges> ? > > > > Saludos > > Jean Carlo > > "The best way to predict the future is to invent it" Alan Kay > > On Thu, May 24, 2018 at 11:12 AM, Alain RODRIGUEZ <arodr...@gmail.com> > wrote: > >> Hi Jean, >> >> Here is what Alexander wrote about it, a few months ago, in the comments >> of the article mentioned above: >> >> "A full repair is an incremental one that doesn't skip repaired data. >>> Performing anticompaction in that case too (regardless it is a valid >>> approach or not) allows to mark as repaired SSTables that weren't before >>> the full repair was started. >>> >>> It was clearly added with the intent of making full repair part of a >>> routine where incremental repairs are also executed, leaving only subrange >>> for people who do not want to use incremental. >>> >>> One major drawback is that by doing so, the project increased the >>> operational complexity of running full repairs as it does not allow >>> repairing the same keyspace from 2 nodes concurrently without risking some >>> failures during validation compaction (when an SSTable is being >>> anticompacted, it cannot go through validation compaction)." >>> >>> >> I hope this helps, >> >> C*heers, >> ----------------------- >> Alain Rodriguez - @arodream - al...@thelastpickle.com >> France / Spain >> >> The Last Pickle - Apache Cassandra Consulting >> http://www.thelastpickle.com >> >> 2018-05-23 21:48 GMT+01:00 Lerh Chuan Low <l...@instaclustr.com>: >> >>> Hey Jean, >>> >>> I think it still does anticompaction by default regardless, it will not >>> do so only if you do subrange repair. TLP wrote a pretty good article on >>> that: http://thelastpickle.com/blog/2017/12/14/should-you-us >>> e-incremental-repair.html >>> >>> On 24 May 2018 at 00:42, Jean Carlo <jean.jeancar...@gmail.com> wrote: >>> >>>> Hello >>>> >>>> I just want to understand why, if I run a repair non incremental like >>>> this >>>> >>>> nodetool -h 127.0.0.1 -p 7100 repair -full -pr keyspace1 standard1 >>>> >>>> Cassandra does anticompaction as the logs show >>>> >>>> INFO [CompactionExecutor:20] 2018-05-23 16:36:27,598 >>>> CompactionManager.java:1545 - Anticompacting [BigTableReader(path='/home/jr >>>> iveraura/.ccm/test/node1/data0/keyspace1/standard1-36a6ec405 >>>> e9411e8b1d1b38a73559799/mc-2-big-Data.db')] >>>> >>>> As far as I understood the anticompactions are used to make the repair >>>> incremantals possible, so I was expecting no having anticompactions making >>>> repairs with the options -pr -full >>>> >>>> Anyone knows why does cassandra make those anticompactions ? >>>> >>>> Thanks >>>> >>>> Jean Carlo >>>> >>>> "The best way to predict the future is to invent it" Alan Kay >>>> >>> >>> >> >
