Race between tablet split and repair about scylladb

[raphaelsc]

@tgrabiec please comment.

[raphaelsc]

Alternatively, we do it all in replica. 'split prepare' waits for ongoing (streaming) sstable writes, and newer ones will use the mutation splitter (used by split compaction) during split mode.

[raphaelsc]

@tgrabiec I suggest we fix it like this

diff --git a/streaming/consumer.cc b/streaming/consumer.cc
index fda6ee66de..9f2717a3da 100644
--- a/streaming/consumer.cc
+++ b/streaming/consumer.cc
@@ -65,6 +65,8 @@ std::function<future<> (mutation_reader)> make_streaming_consumer(sstring origin
                         cf->enable_off_strategy_trigger();
                     }
                     return cf->add_sstable_and_update_cache(sst, offstrategy);
+                }).then([cf, sst] {
+                    return cf->maybe_split_compaction_group_of(sst);
                 }).then([cf, s, sst, use_view_update_path, &vb]() mutable -> future<> {
                     if (!use_view_update_path) {
                         return make_ready_future<>();

that's essentially the same way when we guarantee split of a tablet that is being migrated during prepare phase.

by waiting on that split, we guarantee repair won't move on until new sstable produced is split, and given that repair holds erm, that will synchronize with split execution. what do you think?

[temichus]

last time seen in SCT tier1 2024-07-06