о, почти мой случай, только у меня на серваках разные версии кх, а тут, как я понимаю, у чувака 19.13 на обоих

аа, я не туда cast написал.

я просто не пишу обычно у MV описания полей, использую выведение типов из селекта

CREATE MATERIALIZED VIEW klmn
ENGINE = SummingMergeTree()  order by (ts) as
select ts, toDate(a.ts) dt, toUInt32(sum(1)) cntx, sum(a.size * a.cnt) sumx
from pqrs
group by ts;

Коллеги, такой вопрос, кто нибудь знает как устанавливать сервер кликхауса в "тихом" режиме? что бы пароль для default пользователя задавался автоматически или брался из переменной?

дело в том что кликхаус нужно тиражировать большим кол-вом и из за этого с новой версией клика моя автоматизация ломается =(

Коллеги, такой вопрос, кто нибудь знает как устанавливать сервер кликхауса в "тихом" режиме? что бы пароль для default пользователя задавался автоматически или брался из переменной?

дело в том что кликхаус нужно тиражировать большим кол-вом и из за этого с новой версией клика моя автоматизация ломается =(

env DEBIAN_FRONTEND=noninteractive \
       apt-get install --allow-unauthenticated --yes --no-install-recommends \
           clickhouse-common-static=$version \
           clickhouse-client=$version \
           clickhouse-server=$version \

при этом варианте пароль для default будет пустой?

Коллеги, такой вопрос, кто нибудь знает как устанавливать сервер кликхауса в "тихом" режиме? что бы пароль для default пользователя задавался автоматически или брался из переменной?

дело в том что кликхаус нужно тиражировать большим кол-вом и из за этого с новой версией клика моя автоматизация ломается =(

а какая разница-то? , вы же подложите свои конфиги, ну подложите какой надоэ

мне разницы ни какой. просто для понимания

Всем привет.
Регулярно возникает проблема с переименованием таблиц.

Есть CH версии 20.5.4. Есть таблица MergeTree. В неё каждый час загружается текущее состояние данных из mysql - таблица выгружается полностью, так как по ней в мускуле идёт большое количество апдейтов.
Чтобы для пользователей кликхауса таблица не моргала, скрипт перегрузки данных делает вот так:
1) Данные из TSV грузит в {table}_new;
2) Как только данные влились, делает рокировку: RENAME TABLE  {table} TO {table}_old, {table}_new TO {table};
3) DROP TABLE {table}_old;
Проблема в том, что по факту в 2/3 случаев получается очень плохо:
- целевая таблица мигает - исчезает на сотни секунд;
- иногда вообще валится ошибка WRITE locking attempt on "{table}_new" has timed out! (120000ms) Possible deadlock avoided. Client should retry. IN:RENAME TABLE {table} TO {table}_old, {table}_new TO {table}

Увеление lock_acquire_timeout ни к чему не привело - в большей части случаев RENAME всё равно не успевает выполниться, плюс целевая таблица оказывается невидна на время куполнения RENAME.
Судя по system.query_log у нас нет запросов, которые выполнялись бы более 30 секунд.
Сама по себе таблица, на которой происходит проблема - небольшая, буквально 20ГБ в Clickhouse.

Собственно вопросы:
1) Что можно еще попробовать, чтобы решить проблемы с а)  видимостью таблицы во время RENAME б) больщим временем выполнения RENAME?
2) Возможно, схема с RENAME  TABLE вообще не рабочая, и не надо пытаться сейчас реашать проблему из предыдущего пункта, а есть работающие устоявшиеся практики для полной перегрузки таблиц?

вы про какой final ? select from final  как раз не глядя на партиции работает

create table f (a Int64, d date, s String) engine=ReplacingMergeTree partition by d order by a
insert into f values(1, 11, '1')
insert into f values(1, 11, '2')
select * from f final;
┌─a─┬──────────d─┬─s─┐
│ 1 │ 1970-01-12 │ 2 │
└───┴────────────┴───┘

Это в какой версии так работает? В вашем случае все работает верно потому что поле d, по которому вы проводите партицирование не изменилось. Вставьте в d=12 второй транзакцией и постройте два запроса WHERE d=11 и WHERE d=12. Вы увидете одну и ту же запись в обоих резальтатах, только d у них будет отличаться. Ну и s разумеется.

>ClickHouse also automatically cuts off the partition data where the partitioning key is specified in the query.
https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/

Я так понимаю и сужу по полученным данным, что это общее свойство для всех mergetree. Допустим у вас есть один товар с id=1, который был создан 15 июля - он попадает в партицию 15-го июня, затем этому же товару изменили дату создания на 15 августа. Когда вы будете искать список товаров созданных в июне, вы найдете товар с id = 1, когда вы будете искать товар созданный в августе найдете этот же товар. Потому что FINAL видит первичный ключ, по которому происходит секционирование и отрубает все остальные данные.