Т.е. я из ms sql драйвером odbc цепляюсь к кликхаусу? Или наоборот?)

наоборот

Загрузка остановлена.
В каталогах distributed на сервере, через который идёт вставка, почти 1Тб данных
root@dbserver01:/var/lib/clickhouse/data/db1/gate_clicks# du -h --max-depth=1 .
40G ./replicator:blabla@dbserver17:9000#db1,replicator:blabla@dbserver18:9000#db1
40G ./replicator:blabla@dbserver05:9000#db1,replicator:blabla@dbserver06:9000#db1
40G ./replicator:blabla@dbserver27:9000#db1,replicator:blabla@dbserver28:9000#db1
40G ./replicator:blabla@dbserver29:9000#db1,replicator:blabla@dbserver30:9000#db1
40G ./replicator:blabla@dbserver21:9000#db1,replicator:blabla@dbserver22:9000#db1
39G ./replicator:blabla@dbserver31:9000#db1,replicator:blabla@dbserver32:9000#db1
40G ./replicator:blabla@dbserver19:9000#db1,replicator:blabla@dbserver20:9000#db1
40G ./replicator:blabla@dbserver03:9000#db1,replicator:blabla@dbserver04:9000#db1
40G ./replicator:blabla@dbserver33:9000#db1,replicator:blabla@dbserver34:9000#db1
40G ./replicator:blabla@dbserver01:9000#db1,replicator:blabla@dbserver02:9000#db1
39G ./replicator:blabla@dbserver09:9000#db1,replicator:blabla@dbserver10:9000#db1
40G ./replicator:blabla@dbserver25:9000#db1,replicator:blabla@dbserver26:9000#db1
39G ./replicator:blabla@dbserver13:9000#db1,replicator:blabla@dbserver14:9000#db1
39G ./replicator:blabla@dbserver35:9000#db1,replicator:blabla@dbserver36:9000#db1
40G ./replicator:blabla@dbserver15:9000#db1,replicator:blabla@dbserver16:9000#db1
39G ./replicator:blabla@dbserver23:9000#db1,replicator:blabla@dbserver24:9000#db1
39G ./replicator:blabla@dbserver07:9000#db1,replicator:blabla@dbserver08:9000#db1
40G ./replicator:blabla@dbserver11:9000#db1,replicator:blabla@dbserver12:9000#db1
/replicator:blabla@dbserver17:9000#db1,replicator:blabla@dbserver18:9000#db1
40G ./replicator:blabla@dbserver05:9000#db1,replicator:blabla@dbserver06:9000#db1
40G ./replicator:blabla@dbserver27:9000#db1,replicator:blabla@dbserver28:9000#db1
40G ./replicator:blabla@dbserver29:9000#db1,replicator:blabla@dbserver30:9000#db1
40G ./replicator:blabla@dbserver21:9000#db1,replicator:blabla@dbserver22:9000#db1
39G ./replicator:blabla@dbserver31:9000#db1,replicator:blabla@dbserver32:9000#db1
40G ./replicator:blabla@dbserver19:9000#db1,replicator:blabla@dbserver20:9000#db1
40G ./replicator:blabla@dbserver03:9000#db1,replicator:blabla@dbserver04:9000#db1
40G ./replicator:blabla@dbserver33:9000#db1,replicator:blabla@dbserver34:9000#db1
40G ./replicator:blabla@dbserver01:9000#db1,replicator:blabla@dbserver02:9000#db1
39G ./replicator:blabla@dbserver09:9000#db1,replicator:blabla@dbserver10:9000#db1
40G ./replicator:blabla@dbserver25:9000#db1,replicator:blabla@dbserver26:9000#db1
39G ./replicator:blabla@dbserver13:9000#db1,replicator:blabla@dbserver14:9000#db1
39G ./replicator:blabla@dbserver35:9000#db1,replicator:blabla@dbserver36:9000#db1
40G ./replicator:blabla@dbserver15:9000#db1,replicator:blabla@dbserver16:9000#db1
39G ./replicator:blabla@dbserver23:9000#db1,replicator:blabla@dbserver24:9000#db1
39G ./replicator:blabla@dbserver07:9000#db1,replicator:blabla@dbserver08:9000#db1
40G ./replicator:blabla@dbserver11:9000#db1,replicator:blabla@dbserver12:9000#db1

В логах на этом и других серверах кластера периодически вылазят
DB::Exception: Too many partitions for single INSERT block (more than 100). The limit is controlled by 'max_partitions_per_insert_block' setting. Large number of partitions is a common misconception. It will lead to severe negative performance impact, including slow server startup, slow INSERT queries and slow SELECT queries. Recommended total number of partitions for a table is under 1000..10000. Please note, that partitioning is not intended to speed up SELECT queries (ORDER BY key is sufficient to make range queries fast). Partitions are intended for data manipulation (DROP PARTITION, etc). (version 20.3.9.70 (official build)) (from SOME-IP:49642) (in query: INSERT INTO db1.clicks (...)
20.3.9.70 (official build)) (from SOME-IP:49642) (in query: INSERT INTO db1.clicks (...)

В директории distributed-таблицы на других серверах почти пусто, иногда в субдиректории broken пару МБ лежат.

Как побороть ошибки в логах и что делать с данными на сервере вставки?

в КХ есть engine MySQL

прочти в доке - там примитив

Единственно - на каждый селект от побежит коннектиться, поэтому лучше если серваки "рядом"

всем привет, подскажи кто как бэкапит данные КХ, сейчас данные на двух серверах, настроено шардирование таблиц, общий объем данных 2,5ТБ, брать сервер с большими дисками или куда-то в облако лучше заливать или какие-то есть другие варианты?

Подскажите плиз
1) На ноуте настроен ipv4 и ipv6
2) Есть кликхаус поднятый в докере. Порты замаплены на порты хост машины по ipv4. То есть подключиться к кликхаусу можно только по ipv4.
3) clickhouse-client по умолчанию ресолвит localhost как ipv6 адрес и не может подключиться к серверу по имени "localhost" но может по ipv4 адресу 127.0.0.1.
4) localhost ресолвится и в ipv4 и в ipv6

Можно как-то клиента упросить пробовать и ipv4 и ipv6 адрес? Или только ipv4 при подключении?

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

ну самое простое - freese и скопировать куда-то
https://ruhighload.com/%D0%91%D0%B5%D0%BA%D0%B0%D0%BF+%D0%B8+%D0%B2%D0%BE%D1%81%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5+%D0%B2+clickhouse

это если народ может подождать "если что".  А если нет, то еще один сервак и копия там.
Я этим путем пошел - без всяких зукиперов. ПРосто раз в час новые данные копирую с боевого на резерв. Если что - просто переключу народ на резерв

Спасибо за ответ!

В продолжение темы, судя по логам получается что  

v21.2.5.5

CreatingSetsTransform: Created Join with 373687112 entries from 478629836 rows in 7633.870237821 sec.

против  вчерашних в версии

v 20.9.2.20

CreatingSetsTransform: Created Join with 373553015 entries from 468733575 rows in 147.141437101 sec.

Запрос вида

INSERT INTO default.users_data 
SELECT *
FROM
(
    SELECT
           categories,
           user_id
    FROM temp.users_data
)
ANY INNER JOIN
(
    SELECT
           user_id,
           custom_user_id
    FROM default.user_mapping
    WHERE map_id = 1
)
USING user_id

Подскажите пожалуйста в чем может быть дело ?

Копируете через скрипт по крону?

да

на бакапе selec from remote(.  
ремоте по вьюшке, а там данные за последний час

понял, спасибо
в облака кто-то бэкапит? Или дорого и лучше сервер с большими дисками?

именно в облако

ну у меня правда только полтерабайта пока

Привет! Будет ли работать LowCardinality в массиве? Array(LowCardinality(String))

v21.2.5.5

v 20.9.2.20

INSERT INTO default.users_data 
SELECT *
FROM
(
    SELECT
           categories,
           user_id
    FROM temp.users_data
)
ANY INNER JOIN
(
    SELECT
           user_id,
           custom_user_id
    FROM default.user_mapping
    WHERE map_id = 1
)
USING user_id

Может какие изменения были в поведении ALL INNER JOIN или JOIN? По changelog не нашла ничего подходящего (может не увидела, извиняюсь).
Подскажите куда с этой проблемой копать?