Ddl should block shard rebalancer

Около-начало обсуждения в телеграме: https://t.me/c/1445372156/27378

Суть: если во время ребаланса бакетов будет выполняться кластерный ddl, например drop или truncate, то в результате может остаться неконсистентное состояние.

• первый шаг: написать тесты на ситуацию drop table во время решардинга
• чинить либо с использованием вшардового апи (предположительно map_callrw)
• либо через временную блокировку ребалансера (rebalancer-disable) (при этом нужно позаботить о том, что если ребалансер уже запущен, мы дождёмся его завершения)
• возможно стоит это делать в рамках #760

added 1 deleted label

marked this issue as related to #760

changed the description

changed the description

Базовые шаги видятся следующими:

1. Пометить таблицу в _pico каталоге как подлежащую удалению. снять флаг is_operable.

2) выполнить map_callrw в котором сделать drop space

3) удалить таблицу в pico каталоге окончательно

1. и 3. уже выполнено

Со вторым сложно, т.к. сейчас drop space (конкретно ddl_drop_space_on_master) выолняется в двух случаях:

1. во время изначального применения ddl по RPC запросу proc_ddl_apply от губернатора на мастера репликасета. В этом случае на первый взгляд выглядит так, что губернатор должен делать map_callrw, но для этого придётся сильно менять код применения ddl
2. во время когда ddl уже закомитился, но инстанс догоняется по рафт журналу или рафт снапшоту. В этом случае инстанс теоретически отсутствует в конфигурации вшарда, поэтому возможно map_callrw можно опустить

кажется альтернативный подход с временный выключением ребалансера должно быть проще реализовать

Я тоже поддержу Егора, мы обсудили с ним имплементацию через отключение ребалансера, каких-то принципиальных проблем в этом подходе не нашли

changed the description

assigned to @kusancho

added bug label

added 1 deleted label

changed milestone to %25.1

В рамках реализации TRUNCATE сошлись на том, чтобы починить проблемы с ребалансингом через вызов map_callrw. На этапе обработки Plan::ApplySchemaChange на говерноре вместо вызова proc_apply_schema_change будем дёргать map_callrw пока что конкретно для TRUNCATE. Потом перепишем логику и для DROP TABLE.

См. обновления в ADR по TRUNCATE.

added p/high label

added triaged label

@kusancho обнови статус, пожалуйста. Я помню, что у тебя был план с репро.

Статус:

Застрял на первом шаге, потому что он самый нетривиальный и остальные шаги без него как-будто бы беcсмысленны.

первый шаг: написать тесты на ситуацию drop table во время решардинга"

Проблема: вшард ничего не знает про schema_version. Поэтому есть еще 3 вариант решения проблемы это научить его работать со schema_version. https://git.picodata.io/core/picodata/-/blob/master/doc/adr/2024-11-14-truncate.md последний пункт

Репро: Пусть какой-то бакет/ы переезжают из i1 -> i2. Вшард не заметит смену schema_version(просто пересоздание DROP TABLE T; CREATE TABLE T;) при трансфере бакета. Т.е. "вычитал из таблицы t на i1 с schema_version = 1" и "записал в t на i2 с schema_version = 2".

Воспроизвести ситуацию выше с помощью уже существующих вшардовых инжекшенов не получилось. Они просто про другое. Если добавить свой, то должно получится достаточно просто.

Без вшардовых инжекшенов уж слишком сложно придумать что-то, а если и придумается, то с очень большой вероятностью оно просто не затащится в наш пайтест.

Таким образом, мне понятны все варианты починки, и я бы мог реализовать их, но нужно ли это без первого шага?