Привет! При подобного рода dml: update id = 1 where dt

> 'YYYY-MM-DD' and dt < 'YYYY-MM-DD'
в system.mutations в столбце latest_fail_reason вижу следующее:
'Code: 226. DB::Exception: No length.null.mrk2 file checksum for column length in part /var/lib/clickhouse/data/db/table/tmp_clone_20210730_30090_30777_4_30787/. (NO_FILE_IN_DATA_PART) (version 22.1.2.2 (official build))'
И, конечно, все застряло. Куда смотреть? Что пошло не так?
вижу есть файл в директории который называется length.mrk2, но length.null.mrk2 там нет

Ни у кого нет идей? Еще увидел, что колонка length только недавно была изменена на nullable, может старые парты просто не обновились и не содержат файла length.null.mrk2?

ну , такое ощущение что у вас были ALTER TABLE... которые не завершились... видимо была нормальная колонка, а вы сделали Nullable и не все парты успели слиться... а ваша мутация про этот ALTER ничего не знает

Это баг в 22.1 он давно исправлен,ьеще в январе. Обновляйтесь сразу до 22.3.9

Ах! Понял, а есть ссылка? Начальству показать.

Привет. В итоге починилось при обновлении? Или может быть нашелся другой вариант? У меня такая же проблема) Мутацию я удалил, но в replication_queue эта штука так же осталась.

Привет. А почему может replcation_queue оставаться висеть с ошибками после удаления мутаций? В моем случае вот такая. Хочу разобраться на что это может повлиять вообще 🙂 ``` Code: 226. DB::Exception: No widgets_metrics%2Erender_time.null.mrk2 file checksum for column widgets_metrics.render_time in part /ch_data1/clickhouse/store/6f1/6f124df3-0d12-4168-8fe3-5d1cbf61ebf9/tmp_clone_20220720_0_3810_63_3814/. (NO_FILE_IN_DATA_PART) (version 22.3.2.1) ```

удаление мутации данных на репликацию никак не влияет у вас мутация или изменение структуры таблицы через ALTER TABLE?

ага. делал через ALTER

что ага? первое или второе? мутация данных тоже через ALTER TABLE Делается

изменение структуры таблицы делалась через ALTER TABLE. Мутация руками не создавалась.

тогда перестаньте называть это мутацией это DDL ок. что значит "удаление" вы делали ALTER TABLE .. ON CLUSTER ? а потом внезапно почистили zookeeper?

к сожалению не знаю был ли указан ON CLUSTER (скорее всего да). После выполнения DDL я обнаружил созданную мутацию)) Zookeeper вообще не трогал. Просто выполнялся DDL

а что тогда значит "удаление" вы сделали KILL QUERY ?

Я сделал KILL MUTATION where mutation_id = ***. Сделал это потому что у мутации не было is_done, а в replication_queue были ошибки.

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

при чем там ошибки по нескольким партам (явно не по всем), которые не могу смерджиться по причине, которую указывал чуть выше.

вы сказали что у вас был ALTER TABLE изменение СХЕМЫ данных а не ALTER TABLE ... UPDATE... который мутация так что у вас было и что вы сделали? как мутация в system.mutations выглядела? какая команда была?

Было сделано нечто ALTER TABLE table MODIFY COLUMN render_time Array(Nullable(UInt16)) (Только не знаю, как и сказал, было ли ON CLUSTER) В мутации была command = MODIFY COLUMN render_time Array(Nullable(UInt16)) Т.е. раньше эта колонка была Array(UInt16)

Немного не в тему - а зачем делать nullable столбец типа UInt16? Не лучше было бы сделать его просто Int16 DEFAULT -1 ?

ок. понял... меняем тип, да это мутация с конвертацией данных когда вы ее кильнули, часть партов у вас стала с новым типом , часть со старым... и файл .null.mrk2 не создался... а на другой реплике создался.. советую заново мутацию запустить... вообще Nullable типы медленные луше бы вам просто 0 или -1 в качестве null использовать...

О. точно. и nullable колонки не будет. Спасибо.

ага. отличная идея. 0 к сожалению по бизнес логике не подходит, а вот -1

ок. а нужно ли что-то сделать с replication_queue? А то там до сих пор висят некоторые проблемные парты.

вот только когда начнешь считать всякие avg и quantile по render_time, надо не забывать потом исключать эти -1 ) -1 на dimensions хорош, на метриках — чреват )

они уйдут когда мутация завершиться, потому что станут Inactive

тэкс… спасибо. Сейчас попробую.

У меня, к счастью, агрегации простые - sum, count )

так -1 их тоже сломает )

sum по массиву? что кстати мешает для массива просто пустой массив хранить ? вместо Null ?

Для массивов мы храним тоже []. А суммы по массиву считаем как length после arrayFilter, если надо.

я так понимаю, что лучше не использовать ON CLUSTER при изменении схемы данных, а лучше накатывать на каждой реплике каждого шарда?

как раз лучше наоборот ON CLUSTER это мое IMHO просто надо понимать как он работает почитайте про distributed_ddl

благодарю.

ну и не надо увлекаться... есть люди которые фигачат ALTER TABLE ...ON CLUSTER ADD COLUMN IF NOT EXISTS ... каждую секунду... чем убивают всю производительность

В итоге пришлось очистить таблицу и заново всё перезаливать. А потом апгрейд сделали. В моменте другого решения не было, надо было что-то предпринимать.