ну меньше 16 должно быть, хотя бы, желательно 0

--background_pool_size arg                                       Number of threads performing background work for tables (for example, merging in merge tree). Only has meaning at server startup.
 --background_move_pool_size arg                                  Number of threads performing background moves for tables. Only has meaning at server startup.
 --background_schedule_pool_size arg                              Number of threads performing background tasks for replicated tables. Only has meaning at server startup.

мутации есть?
number_of_free_entries_in_pool_to_execute_mutation

Ну нет, никакие запросы с альтером/делетом не делаю

С таблицами только инсерт/селект ну и drop partition раз в сутки.

Как настроить автоматическую репликацию из MySQL, работает только если в консоли прописать, как добавить новую задачу под репликацию. Куда искать?

Скорее всего только через стороннюю программк, если я правильно понял вопрос

Всем привет! КТо нибудь сталкивался со следующей ошибкой?

Sorting key cannot contain nullable columns

CREATE MATERIALIZED VIEW limits
            ENGINE = AggregatingMergeTree() PARTITION BY toYYYYMM(timestamp) PRIMARY KEY (timestamp,skin_id) ORDER BY (timestamp,skin_id)
AS select
     skin_id
     ,timestamp
     ,quantileExactWeighted(.8)(c_price,c_offers) as max
     ,quantileExactWeighted(0.2)(c_price,c_offers) as min
from states
GROUP BY skin_id, timestamp;

Исходная таблица:

CREATE TABLE states
(
    timestamp          DateTime,
    skin_id          Int64,
    c_classid          Int64,
    c_instanceid       Int64,
    c_price            Int32,
    c_offers           UInt32,
    c_market_hash_name String
)
    ENGINE = ReplacingMergeTree()
        PARTITION BY toYYYYMMDD(timestamp)
        ORDER BY (timestamp,c_classid,c_instanceid)
        TTL timestamp + INTERVAL 1 MONTH;

Не мойму почему он считает столбцы  timestamp,skin_id nullable если они таковыми не являются?

Sorting key cannot contain nullable columns

CREATE MATERIALIZED VIEW limits
            ENGINE = AggregatingMergeTree() PARTITION BY toYYYYMM(timestamp) PRIMARY KEY (timestamp,skin_id) ORDER BY (timestamp,skin_id)
AS select
     skin_id
     ,timestamp
     ,quantileExactWeighted(.8)(c_price,c_offers) as max
     ,quantileExactWeighted(0.2)(c_price,c_offers) as min
from states
GROUP BY skin_id, timestamp;

CREATE TABLE states
(
    timestamp          DateTime,
    skin_id          Int64,
    c_classid          Int64,
    c_instanceid       Int64,
    c_price            Int32,
    c_offers           UInt32,
    c_market_hash_name String
)
    ENGINE = ReplacingMergeTree()
        PARTITION BY toYYYYMMDD(timestamp)
        ORDER BY (timestamp,c_classid,c_instanceid)
        TTL timestamp + INTERVAL 1 MONTH;

и где skin_id в исходной таблице?

Поправил, не то скопировал

вот попробовал в 3 разных кх , все создается

Эм, нашёл проблему)

SHOW CREATE TABLE states;

CREATE TABLE default.states
(
    `timestamp` DateTime, 
    `c_classid` Int64, 
    `c_instanceid` Int64, 
    `c_price` Int32, 
    `c_offers` UInt32, 
    `skin_id` Nullable(Int64)
)
ENGINE = ReplacingMergeTree()
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY (timestamp, c_classid, c_instanceid)
TTL timestamp + toIntervalMonth(1)
SETTINGS index_granularity = 8192

Не верь IDE)

она умудряется подвирать даже с postgresql, так что с кликхаусом вообще не стоит верить всяким DDL )

Мдэ, пол часа искал косяк(

не, они не раскидываются на разных подах, в settings.CLICKHOUSE_HOST не указан отдельно взятый под,
но как раз надо попробовать отдельно на каждом поде запустить миграции

Ага. Так должно заработать.

Доброе утро, подскажите в кликхаусе есть какой-нибудь готовый инструмент для автоматической очистки данных по партициям?

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

Добрый день, коллеги и спящие неботовские гуру. Может ли оптимизация таблицы в которую внесли блум фильтр на несколько полей с гранулярностью 1 привести к проблеме: слишком много открытых файлов? Партиция не была изменена и почти каждая из них содержит несколько десятков милионов записей...