On Mon, Feb 26, 2018 at 2:54 PM, Nadav Har'El <n...@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.
