> On Sep 17, 2018, at 2:34 AM, Oleksandr Shulgin <oleksandr.shul...@zalando.de> > wrote: > >> On Tue, Sep 11, 2018 at 8:10 PM Oleksandr Shulgin >> <oleksandr.shul...@zalando.de> wrote: >>> On Tue, 11 Sep 2018, 19:26 Jeff Jirsa, <jji...@gmail.com> wrote: >>> Repair or read-repair >> >> >> Could you be more specific please? >> >> Why any data would be streamed in if there is no (as far as I can see) >> possibilities for the nodes to have inconsistency? > > Again, given that the tables are not updated anymore from the application and > we have repaired them successfully multiple times already, how can it be that > any inconsistency would be found by read-repair or normal repair? > > We have seen this on a number of nodes, including SSTables written at the > time there was guaranteed no repair running. >
Not obvious to me where the sstable is coming from - you’d have to look in the logs. If it’s read repair, it’ll be created during a memtable flush. If it’s nodetool repair, it’ll be streamed in. It could also be compaction (especially tombstone compaction), in which case it’ll be in the compaction logs and it’ll have an sstable ancestor in the metadata.
