Hi, Full repair triggers anticompaction as well. Only subrange repair doesn't trigger anticompaction, and in 4.0, AFAIK, full repairs won't involve anticompaction anymore.
Cheers, Le lun. 10 févr. 2020 à 19:17, Krish Donald <gotomyp...@gmail.com> a écrit : > Thanks Jeff, But we are running repair using below command , how do we > know if incremental repair is enabled? > > repair -full -pr > > Thanks > KD > > On Mon, Feb 10, 2020 at 10:09 AM Jeff Jirsa <jji...@gmail.com> wrote: > >> Incremental repair is splitting the data it repaired from the data it >> didnt repair so it can mark the repaired data with a repairedAt timestamp >> annotation on the data file / sstable. >> >> >> On Mon, Feb 10, 2020 at 9:39 AM Krish Donald <gotomyp...@gmail.com> >> wrote: >> >>> Hi, >>> >>> I noticed few messages in system.log like below: >>> INFO [CompactionExecutor:21] 2020-02-08 17:56:16,998 >>> CompactionManager.java:677 - [repair #fb044b01-4ab5-11ea-a736-a367dba4ed71] >>> SSTable BigTableReader(path='xyz/mc-79976-big-Data.db') >>> ((-8828745000913291684,8954981413747359495]) will be anticompacted on range >>> (1298637302462891853,1299655718091763872] >>> >>> And compactionstats was showing below . >>> id compaction type >>> keyspace table completed total unit progress >>> 82ee9720-3c86-11ea-adda-b11edeb80235 Anticompaction after repair >>> customer profile 182882813624 196589990177 bytes 93.03% >>> >>> We are on 3.11. >>> >>> What is the meaning of this compaction type "nticompaction after repair >>> "? >>> Havent noticed this in 2.x version >>> >>> Thanks >>> KD >>> >>>
