When is ViewMutationStage ever used? I am trying to have a test that will
result in tasks getting executed in this stage to verify metrics for
ViewMutuationStage.
I been going through the code and see in StorageProxy::mutateMV it will
call:
asyncWriteBatchedMutations(wrappers, localDataCenter,
Have had multiple customer hit this CASSANDRA-15081 issue now, where
upgrading from older versions the sstables contain an unknown column (its
not present in the dropped_columns in the schema)
This bug is serious as reads return incorrect results and if you run scrub
it will drop the row. So
> When you perform a non-incremental repair data is repaired but not marked
as repaired since this require anti-compaction to be run.
Not sure since what version, but in 3.10 at least (I think its since 3.x
started) full repair does do anti-compactions and marks sstables as
repaired.
On 23 June
The main issue I see with this is "Read all the SSTables and detect which
partition keys are present in more than the compaction minimum threshold
value" . This is quite expensive and will be using quite a lot of I/O to
calculate. What makes writing a compaction strategy so difficult is
on't see any reason why you couldn't add this
> functionality to the existing RepairService mbean. That said, before
> getting into mbean names, it's probably best to come up with a plan for
> cancelling validation and sync on each of the replicas involved in a given
> repair. As far as I
I am looking to improve monitoring and management of repairs (so far I have
patch for adding ActiveRepairs to table/keyspace metrics) and come across
ActiveRepairServiceMBean but this appears to be limited to incremental
repairs. Is there a reason for this?
I was looking to add something very
