ничего страшного, там не критичный апдейт был)

ну тогда надо как то старые парты стриггерить Merge
какую нибудь мутацию чтоли сделайте на ту колонку которая не MATERIALIZED

что нибудь типа

SET mutations_sync=2;
ALTER TABLE db.table UPDATE column=column;
попробовать

сервер один? если ReplicatedMergeTree то в system.replicas поглядите не встала ли репликация для таблицы

Попробуйте ограничить мутацию партицией или мельче,  а потом optimize table... partition...
Проальтерите другие части данных

сработало
спасибо большое

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

вряд ли наливка тормозит, скорее всего тормозят мерджи )

после того как удостоверитесь можете поменять это
max_replicated_merges_in_queue  16

ну а если фетчи то вот эти:
replicated_max_parallel_fetches
replicated_max_parallel_fetches_for_table
replicated_max_parallel_fetches_for_host
replicated_max_parallel_sends
replicated_max_parallel_sends_for_table

спасибо, попробуем

Скажите, а в kafka engine косюмер поднимается и висит постоянно и поллит, или же когда больше нечего читать из топика, освобождает место в backgroundSchedule пуле для других консюмеров? (речь о ситуаци когда консюмеров больше чем background_schedule_size)
Мы часто стали ловить ошибку при попытке закомитить оффсеты от брокера и консюмер группа постоянно ребалансится.

Clickhouse Server v 20.4.

2021.02.08 15:48:57.944984 [ 41516 ] {} <Error> StorageKafka (kafka_table_name): Exception during commit attempt: Broker: Unknown member
2021.02.08 15:48:57.963076 [ 41516 ] {} <Error> void DB::StorageKafka::threadFunc(): Code: 518, e.displayText() = DB::Exception: All commit attempts failed. Last block was already written to target table(s), but was not commited to Kafka.,

Подскажите пожалуйста - есть ли какая-то возможность повлиять на то в каком порядке кликхаус читает данные с диска(порядок чтения партиций)?

Проблема в чем, есть запрос:

insert select * from <very_big_table> any inner join <medium_table> using id

Именно в таком варианте оно работает, но нет понимания есть ли гарантия повторяемости результатов - any join при параллельном чтении выдает результаты того потока который первее нашел пару для правой части, верно?
Нужно получить гарантированное поведение данного запроса, а именно - чтоб к каждому элементу малого множества клеялась либо самая старая запись(самая старая партиция) либо самая новая. Хотя бы какой-то один из этих вариантов.
Добавляя какую-либо сортировку в very_big_query - сразу вылетаем по памяти( (здесь кстати не понятно почему - если сортируем по ключу партиционирования - все равно вылетает - хотя казалось бы выдавай партици по очереди и ок).

Срезав кол-во потоков через max_threads=1 можно убрать параллелизм и судя по логам вроде как чтение идет в один поток и в порядке партиций от меньшей к большей. Т.е. выглядит как подходящий вариант, но нигде не могу найти подтверждения этой теории - гарантирован ли в данном варианте повтор результата на одних и тех же данных, может кто-нибудь подсказать?

Ну и может есть рычаг заставить читать партиции в обратном порядке? тогда при условии того что предыдущий абзац верный - можно было бы получить вариант _join с самым свежим_.

insert select * from <very_big_table> any inner join <medium_table> using id

гарантий нет никогда, ни в одной нормальной SQL базе.

с памятью можете попробовать max_bytes_before_external_sort выставить

Ребята, патовая ситуация, добавлили новую (следующую) ноду в кластер, а тут длинна имени папки для бинов уложила его (кластер), срочно вывели.
при анализе оказалось что имя ее более 255 симовлов.
Вручную проверили
mkdir 'replica:xxxxxxxxxx@clickhouse%2Dnode1......node27:9000/statistics' : File name too long
Как с минимальными потерями сократить есть идеи?

укоротить имена и пароли 🙂
какая версия КХ?
В новых есть use_compact_format_in_distributed_parts_names

20.3.19.4 (official build).

в этой наверное нету
поищите в system.settings на всякий случай

есть такое
│ use_compact_format_in_distributed_parts_names │ 0     │       0 │ Changes format of directories names for distributed table insert parts. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │        0 │
Но есть и такое
https://github.com/ClickHouse/ClickHouse/issues/14130

Подскажите по update_field для словарей:

- Имеем таблицу в Postgres, в ней поле updated (timestamp with time zone, not null).
 Какой тип updated поля ожидает ClickHouse (timestamp / timestamp with time zone)?
- Конфиг словаря такой:
 <source>
   <name>test</name>
   <odbc>
     <table>table_name</table>
     <connection_string>DSN=...</connection_string>
     <update_field>updated</update_field>
   </odbc>
 </source>
 <layout>
   <ssd_cache>
   ...
   </ssd_cache>
 </layout>
 <lifetime>
   <min>30</min>
   <max>45</max>
 </lifetime>
 <structure>
   <id>
     <name>id</name>
     <type>UInt64</type>
   </id>
   <attribute>
     <name>status_id</name>
     <type>UInt8</type>
     <null_value />
   </attribute>
   <attribute>
     <name>updated</name>
     <type>UInt64</type>
     <null_value />
   </attribute>
 </structure>
- Делаем system reload dictionary test; select dictGet('test', 'status_id', toUInt64(1))
- Видим зарос в Postgres: SELECT "id", "status_id", "updated" FROM "test_table" WHERE "id" IN (1)
- Повторяем через минуту - снова такой же запрос в Postgres

Почему нет запроса вида updated >= {$last_check}?
Словарь наполняется выборками по ID, не сразу все / изменившиеся выгружаются?

остановите инсерты, удалите старые папки, поставьте настройку в 1 в default профиле и рестартаните

Будем пробовать, но баг-то открыт...