Does ScyllaDB support incremental repair?

[Xiang Zhou]

Hi, 

During the test, I found that repair is a very heavy operation. 

When the cluster stores a large amount of data, it takes a long time to execute repair. 

If ScyllaDB supports incremental repair, it should shorten the repair execution time and reduce the impact on the business, am I right？

By the way, I did not see the '-inc' option in `nodetool help repair`, does it mean that it is not supported?

[Tzach Livyatan]

No, Sylla does not support Apache Cassandra style incremental repair

Scylla did implement other optimizations which greatly improved the repair time.

Most significant will be Row level repair, in particular when the difference between nodes is small (which is typical)

https://www.scylladb.com/2019/08/13/scylla-open-source-3-1-efficiently-maintaining-consistency-with-row-level-repair/

by @Asias He 

Tzach

--
You received this message because you are subscribed to the Google Groups "ScyllaDB users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scylladb-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scylladb-users/adb4291b-a965-40df-a070-4299284ac4acn%40googlegroups.com.

[Nadav Har'El]

On Mon, Feb 8, 2021 at 9:16 AM Xiang Zhou <feixia...@gmail.com> wrote:

Yes, we do not support incremental repair - we have a very old issue about it: https://github.com/scylladb/scylla/issues/83

When incremental repair came out in Cassandra, it had so many problems (as a Google search for "cassandra incremental repair" can still demonstrate) that we judged that nobody will want to use it, and it wasn't worth our attention. As Tzach noted, improvements in the regular repair made it perform much better, and adding to that the Scylla Enterprise feature of the repair manager - which can do repairs piece by piece and handle errors gracefully - so for most users the regular repair became good enough.

But recently Cassandra fixed most of the major issues of incremental repair, and it still has some interesting use cases. In particular, use cases where the database grows slowly over time, so after a year we only 2% new data each week, so it is wasteful to repair the same 98% old data every week. So it would be good to eventually implement incremental repair (based on how Cassandra redid it in Cassandra 4.0). But to justify such non-trivial development we will probably need a customer with a use case where this is important.

  

Nadav.

[Xiang Zhou]

Thanks for your reply.