Re: Issues with Materialized-Views updates during a cluster change?

[Nadav Har'El <ny...@scylladb.com>]

On Mon, Feb 26, 2018 at 2:54 PM, Nadav Har'El <ny...@scylladb.com> wrote:

> When there are permanent inconsistencies though (when the base is
>
>> consistent and the view has extraneous rows), it doesn't really matter
>> if the inconsistency is present on a subset or all view replicas,
>> since the inconsistency is already visible to clients. The only way to
>> fix permanent inconsistencies currently is to drop and re-create the
>> view. CASSANDRA-10346 was created to address this.
>>
>
> So this is why I asked why the view repair, which you suggested in the
> release notes, will help in this case.
>
> I'm also worried that the fact *each* replica sends to the pending node
> (and not the paired replica) will mean that we are more likely to create
> these inconsistencies - if two base replicas have different values, *both*
> values will be sent to the pending view replica, and create an
> inconsistency
> there that cannot be fixed.
>

I think I missed one crucial point, which allows the "each replica sends to
the
same pending view replica" to actually work. The point is that the view
replica keeps not just the view rows, but also (shadowable...) tombstones
for rows that have previously been deleted. So as long as one of the base
replicas had an old value changed and managed to send the tombstone to the
view replica, this old row will be deleted from the view - even if one of
the
base table still has it.

Nadav.