Добрый день! после обновления до 20.5.2.7 , перестал работать UNION ALL, с ошибкой DB::Exception: Block structure mismatch in  function connect between Converting and Concat stream: different number of columns
Может кто-то сталкивался?

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

У юзера есть возможность самостоятельно менять свой пароль или только через админа?

попробую спасибо!

чекните наличие колонок в разных репликах, если не найдется реплики без колонки то это не тот кейс наверное

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

Привет, создаем временную таблицу. Движок memory. Заполняем данными, дропаем таблицу. Бывает проскакивает ошибка, что ошибка дропа таблицы не существует.

привет всем, проблема с ReplicatedMergeTree и вставкой в неё, мб кто-то то знает в чём проблема:

КХ раскатан в кубике, стоит 3 шарда по 2 реплики, перед ними кубиковский loadBalancer

есть disribibuted таблица, настроенная на локальные ReplicatedMergeTree

в качестве теста заливаем 125 строк,
партиция по time_key и hash, time_key на все 125 строк константа, 75 строк с одним хешом, 50 с другим,  можно считать что данные сортированы (лежат в отдельных папках по хешу, вставляем содержимое сначала одной, потом другой)

заливаем даныне через нативный клиент (cat | clickhouse-client)

в одном из шардов стабильный 0 данных, в двух других всё ок.
Примерно в 1 случае из 5 все данные заливаются ок.
В логах того шардра, где 0, только ошибка, что слишком много партиций

Если кто может подсказать в чём проблема, буду премного благодарен

буфферные таблицы это если вам данные не жалко потерять

Так буферная таблица ведь скидывает все данные в *MergeTree

скидывает не сразу, и если кх умрёт пока данные не скинулись, то данные пропадут

т.к. они в оперативке хранятся

Доброго дня. В таблице используется движок CollapsingMergeTree.. Мне чтобы оттуда удалить полностью некоторые строки, то надо просто добавить строку с параметрами из ORDER BY и Sign = -1?

Пока не сделаете
OPTIMIZE TABLE ... FINAL
строки не удалятся и работать  с ними до этого (и спосле)
стоит через агрегацию
count() -> sum(Sign)
...

спасибо

Подскажите, простой запрос "select * from table limit 10" ложит сервер (забивается вся озу). В таблице 10 столбцов и 14 миллионов записей

какой размер строки, какой размер блока, какая ошибка

Всем привет. Подскажите пожалуйста, почему может не аттачится партишн?

SELECT *
FROM system.detached_parts
LIMIT 1

┌─database─┬─table─┬─partition_id─┬─name────────────────────┬─disk────┬─reason───┬─min_block_number─┬─max_block_number─┬─level─┐
│ test    │ foo │ 20181219     │ 20181219_20181219_0_1_1 │ default │ 20181219 │                0 │                1 │     1 │
└──────────┴───────┴──────────────┴─────────────────────────┴─────────┴──────────┴──────────────────┴──────────────────┴───────┘

Делаю аттач

ALTER TABLE test.foo
    ATTACH PARTITION ID '20181219'


Ok.

0 rows in set. Elapsed: 0.001 sec.

А он из detached не уезжает. Что я делаю не так?

Немного не понял что значит размер строки.

примерная структура таблицы:
datetime datetime64,
t_id uint,
o_id uint,
from string,
subject string,
level string,
message string,
context json,
exception json,
ip string,
request json,
response json,
diff json,

вся таблица занимает 2.5 Гб на hdd

Настройки сервера по-умолчанию.

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

запустите с send_logs_level='trace' и покажите че там интересного