It could also be https://issues.apache.org/jira/browse/CASSANDRA-2503
On Mon, Sep 17, 2018 at 4:04 PM Jeff Jirsa <jji...@gmail.com> wrote: > > > 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. > > >
