11016
Обсуждаем ClickHouse
А подскажете ситуацию в которой случилось у вас так что упал кипер кластер ? Хочу себе закинуть в disaster recover plan
Читать полностью…
>Вопрос в контексте задачи по написанию скриптов
вообще это экстренные ситуации, какие скрипты вы можете писать? или вы про runbook-и?
SYSTEM DROP REPLICA выполняют на ноде где есть таблица, чтобы взять ее зукипер путь, ну и там можно просто дропнуть разом для всех таблиц, т.е. drop replica находит все zk пути и в цикле вычищает удаляемую реплику по этим путям, естественно это другая нода, не та которую удаляют, в ногу выстрелить не получится.
если использовать SYSTEM DROP REPLICA ZKPATH то можно выполнять с любой ноды, вообще даже из clickhouse-local, там просто нужен доступ к зукиперу и она удалит все из replicas/{replica} по конкретному указанному пути
Добрый день!
Вопрос в контексте задачи по написанию скриптов
В случае:
- “Zookeeper loss metadata” предлагается выполнить
system restore replica … оn cluster
https://clickhouse.com/docs/sql-reference/statements/system#restore-replica
detach table, system drop, attach table, system restore, system sync
https://altinity.com/blog/a-new-way-to-restore-clickhouse-after-zookeeper-metadata-is-lost
из 22.5 переезжаем на 25.5. Селект из 25.5 (SELECT * FROM remote() ) не срабатываете с ошибкой
Читать полностью…
вы 25.5 -> 22.5 качаете?
ну на приемнике тогда
INSERT INTO db.table SELECT .. FROM remote()Читать полностью…
он позволит вставить данные в любом порядке... и оно корректно заменит при FINAL
Читать полностью…
да, я как раз хочу туда поставить временную метку (DateTime), чтобы нормально схлопывать
Читать полностью…
хай чат, есть 2 кх версий 22.5 и 25.5, есть ли какой-то способ завести remote() между ними, чтобы данные перекачать, без апгрейда 22.5 ? Если нет, есть ли какие-то другие способы данные перетащить ?
Читать полностью…
у вас всегда комбинация id1, id2, date_check одинаковая?
вам что нужно ? чтобы id1, id2 всегда последний date_check хранили или что?
а что конкретно таймаутит? вставку или что?
Читать полностью…
вот про это не слышал, у меня
PARITION BY (date_check)
ORDER BY (id1, id2, date_check)
это является противоречием?
то есть обычно информация нужна по id1/id2, но при этом диапазон дат большой, поэтому в фильтре select-a накладываем where date_check >= '' and date_check < ''
может, мне нужно сделать
ORDER BY (date_check, id1, id2)?
да, Final обязательно будет. А старые записи будут в фоне сами удаляться, верно?
Читать полностью…
Collapsing нужен если еще хотите eventually "удалять"
Читать полностью…
SYSTEM DROP REPLICA 'имя_реплики' FROM TABLE db.table
Нельзя сделать если в текущем сервере есть живая (пусть и readonly) таблица
поэтому рекомендуют DETACH чтобы данные почистить
вы делаете from remote
вам предлагали наоборот INSERT INTO FUNCTION remote()
если инициатором будет 22.5 то ошибки про allow_experimental_analyzer не будет
судя по интернету, это лечится апдейтом 22.5 клика
Читать полностью…
remote не работаетDB::Exception: Unknown setting allow_experimental_analyzer.
Читать полностью…
ну простейшееINSERT INTO FUNCTION remote() SELECT ...
да
Replacing при объединении двух партов
берет все записи с одним ORDER BY ...
и делает из них одну...
при этом если ReplacingMergeTree(version_field_name)
тогда с максимальным значением version_field
нет, это у меня ключ сортировки, поля, которые мы обычно указываем в WHERE для какой-либо агрегации, для каждой комбинации id1, id2 есть тысячи разных date_check. А мне нужно чтобы другие поля записи (которых нет в ключе) можно было бы апдейтить. Я, кажется, все понял, у меня все "апдейтящие" записи будут находиться в рамках одной партиции (они будут включать в себя полный ключ сортировки, = будут схлопываться), спасибо вам большое!
Читать полностью…
ну у вас проблема с зукипером, я думаю по логам зукипера все будет понятно
у вас КХ сервер не может сделать инсерт потому что зукипер отваливается
order by (id1, id2, date_check) -- нормально
комбинация (id1, id2, date_check) только в одной партиции
парты мержатся внутри партиции
да, ну еще главное чтобы PARTITION BY не противоречил sorting key (ORDER BY) ... а то парты из разных партиций не мержатся между собой
Читать полностью…
и не забудьте использовать
SELECT ... FROM db.table FINALЧитать полностью…
добрый день! вопрос концептуальный: есть таблица, около 20млн записей в сутки, на 4 нодах (+ по одной реплике на каждую ноду). Для каждой записи будет делаться апдейт, один раз. Какой движок в таком случае лучше использовать - Collapsing, или Replacing с условным полем "время записи"?
хочу делать вставку полностью записи с измененными нужными полями
День добрый. Подскажите, в чем может быть проблема. Кластер 6 реплик, 3 шарда. Вставляю батч 1млн строк в distributed таблицу.
каждая вставка следующая ошибка
Code: 319. DB::Exception: Unknown status of part 202302_240_240_0 (Reason: Session moved to another server, so operation is ignored). Data was written locally but we don't know the status in keeper. The status will be verified automatically in ~300 seconds (the part will be kept if present in keeper or dropped if not). (UNKNOWN_STATUS_OF_INSERT) (version 25.4.3.22 (official build))
и данные укладываются в distributed таблицу по 5 минут(имею в виду,что только через 5 минут появятся все строки в таблице)
Использую данные параметры
SET async_insert = 1;
SET wait_for_async_insert = 0;
SET async_insert_max_data_size = 10485760;
SET async_insert_busy_timeout_ms = 1000;