У меня не собрался odbc с utf8 на той версии дистрибутива clickhouse, с которой я работал, когда пытался использовать odbc

что?
КХ работает с odbc через odbc-bridge.
odbc-bridge -- это отдельный процесс КХ который запускается автоматически
odbc-bridge -- использует odbc драйвера которые установлены в системе

ничего собирать не надо

Отмечу, что четко сказал о ТОЙ ВЕРСИИ, с которой пробовал это сделать это было несколько лет назад.

никогда не надо было пересобирать КХ.

odbc-bridge поддерживает все типы данных PG?

не все, только те что умеет (для каждой бд свой список внутри бриджа)

И в чем тогда его профит в моем случае?

jdbc бридж нужен для баз у которых нет odbc драйверов, но есть jdbc

Разницу между ними я знаю. Я спросил про выигрыш при использовании odbc перед jdbc

odbc быстрее и удобнее и jvm память не жрет

У меня тут вопрос затерялся, но он ещё актуален. Сталкивался кто?
Если заводить для таблицы ещё одну реплику, но в DDL не указать пару колонок, то будет ошибка:
Received exception from server (version 20.4.2):
Code: 122. DB::Exception: Received from localhost:9000. DB::Exception: Table columns structure in ZooKeeper is different from local table structure.

А можно ли создать реплику для таблицы не зная её DDL? Ну т.е. "дорогой, Clickhouse, у меня вот эта таблица имеет движок ReplicatedMergeTree, вот на этой машине сделай для неё реплику, пожалуйста".

>А можно ли создать реплику для таблицы не зная её DDL?
нет

вот и поговорили)) спасибо

А как обычно добавляют ещё одну реплику для всей машины? У меня допустим уже есть две реплики с 50 таблицами и я хочу третью добавить, чтоб на ней аналитики игрались. Какие средства есть это сделать? Или просто заводят машину и на ней выполняют create table 50 раз?

Всем привет! Ребят мож кто сталкивался... Внезапно любой запрос с ON CLUSTER (пример:

CREATE TABLE tmp.example_table ON CLUSTER cluster1 (
 field1 String,
 field2 DateTime,
 ver UInt64 MATERIALIZED toUInt64(now())
) ENGINE = ReplicatedReplacingMergeTree(
 '/clickhouse/tables/{shard}/tmp_example_table',
 '{replica}',
 ver
)
ORDER BY field1
SETTINGS index_granularity = 8192
)
Начал возвращать:
DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000019072 is executing longer than distributed_ddl_task_timeout

я запускаю chef-client через 30 сек. все готово.

рецепт идет в cmdb узнает что этот сервер часть кластера, реплика шард 17, дальше берет из другой реплики из metadata attach, переделывает в create выполняет и еще 20 тыщ строк на баше

для всех нод ?
что показыает clickhouse-client в табличке которая выводится когда выполняем ON CLUSTER ?

о, пасибо за наводку на metadata/ каталог. Дальше суть ясна.

тогда не знаю, логи надо на всех читать