я не смотрел, наверное как в кафке, ack после успеха инсерта, блок в памяти, зачем на диске

все неправильно поняли. Дедупликация инсертов это вообще не про это, читайте доку про репликацию.

кстати точно такую же дедупликацию вроде уже должны были присобачить в обычной mergetree, поищу

о как, больше года раскопки https://github.com/ClickHouse/ClickHouse/pull/8467 , чудеса такая мелкая фича

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

вот 2 запроса с агрегацией по часам - до и после пересоздания
версия 19.8.3.8

events_importance
┌─count─┬───────────────start─┐
│   194 │ 2021-02-02 06:00:00 │
│     7 │ 2021-02-02 04:00:00 │
└───────┴─────────────────────┘

 events_importance после пересоздания
 ┌─count─┬───────────────start─┐
│   122 │ 2021-02-02 10:00:00 │
│    16 │ 2021-02-02 08:00:00 │
│    10 │ 2021-02-02 07:00:00 │
│    12 │ 2021-02-02 06:00:00 │
│    21 │ 2021-02-02 04:00:00 │
│     8 │ 2021-02-02 03:00:00 │
│     4 │ 2021-02-02 02:00:00 │
│     4 │ 2021-02-02 01:00:00 │
│     4 │ 2021-02-02 00:00:00 │
└───────┴─────────────────────┘

итоговое число записей одинаковое, но распределение совершенно разное

матвьюшка AggregatingMergeTree, основная таблица MergeTree
матвьюшка считается как

SELECT
    countState() AS count,
    toStartOfMinute(toDateTime(time)) AS time,
    importance,
    toDate(time) AS _date
FROM events
GROUP BY time, importance

Спасибо

добрый вечер. сервер КХ был перезапущен. штатно.таблица реплицируемая. сейчас сервер не запускается с ошибкой DB::Exception: Suspiciously many (152) broken parts to remove.: Cannot attach table. правильно я понимаю, что я могу эти куски <Warning> DB.TABLE: Detaching stale part /var/lib/clickhouse/data/DB/TABLE/610766fc0a3e72b7376196f9f9251b7a_1024111_1024332_7_1024651, which should have been deleted after a move. That can only happen after unclean restart of ClickHouse after move of a part having an operation blocking that stale copy of part. перетащить в другую папку?

Добрый вечер! нет ли в КХ готовых конструкций для 7 day rolling average?

тапа avg(value)
   over (order by date asc
         rows between 6 preceding and current row) as avg,

/stat@combot

Total messages: 202692

Это всё ещё в разработке. https://github.com/ClickHouse/ClickHouse/issues/17623

понятно, тогда через подзапросы

Этого не может быть, потому что не может быть никогда?! Но есть.

Здравствуйте! Столкнулся с воспроизводимой ситуацией, когда запросы через Distributed таблицу к system.settings  соседних серверов ClickHouse возвращают значение параметра(ов), которое когда-то на этом сервере было установлено, но с тех пор давно изменилось.
Как будто бы старое значение где-то залипло или закешировалось.

Подробнее.
Тестовый кластер из 3 серверов.
Над часто востребованными таблицами (system.merges, system.replication_queue и т.д.) из system у меня Distributed таблицы (самое простое - 3 шарда по штуке на сервер, без реплицирования), чтобы из любой точки стенда одним запросом получить полную картину.

Разбирался с причинами неких неполадок с межсерверным взаимодействием (в логах непрерывным спам много раз в секунду события <Trace> HTTPCommon: Failed communicating with {ANOTHER_HOST} with error 'connect timed out: {IP}.61:9009' will try to reconnect session .  на стенд идёт фоновая нагрузка примерно 100-200 тыс. событий в секунду).

Предположил, что надо покрутить параметры http_%_timeout, в частности значительно увеличить http_connection_timeout. (Поиск по этой группе показал, что некоторые его c 1 и до 15 поднимали).

На одном из серверов сперва установил (в конфиге профиля default-пользователя) http_connection_timeout в 10, потом в 2, потом закомментировал, тем самым восстановив значение по умолчанию - 1.
И локальный запрос этого параметра подтверждает, что значение параметра теперь дефолтное.

Но с соседних серверов запрос через Distributed таблицу возвращает давно не актуальное состояние, которое было час назад! (Точнее какое-то время неверное значение возвращалось при запросе с обоих соседних серверов, сейчас уже только с одного).

это из-за pooling.

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