You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @adejanovski, just wondering, what is the reason we want to make sure that we do not have 2 repair sessions of different types running at the same time? Is it just to avoid overstreaming?
Hi @kzalys, having multiple threads working concurrently on the same sstables is a good way to shoot yourself in the foot and opens the door to race conditions in Cassandra itself. An sstable cannot be compacted and anticompacted at the same time, which is one type of conflict that can happen.
The overstreaming and additional pressure put on the cluster is another good reason not to do this indeed.
We are running incremental repairs for one set of tables in a keyspace but full for another set. Should disallow happen on per table basis instead - or are we doing something bad?
Project board link
Currently we disallow running twice the same repair, but an incremental could start even if a full is already running for the same keyspace.
We should prevent that from happening and make the scheduler check if another repair is running for the same keyspace before starting a new repair.
┆Issue is synchronized with this Jira Story by Unito
┆Issue Number: REAP-15
The text was updated successfully, but these errors were encountered: