11238
Обсуждаем ClickHouse
интересно, при чем тут версия КХ, если на одной ноде rmdir не может сделать. файлы поди там ?
Читать полностью…
Система резервного копирования. Вроде в обиходе уже везде распространилась абривеатура.
Читать полностью…
Добрый день, коллеги!
Просьба подсказать, при тестировании скриптов СРК на одной реплике все отрабатывает нормально, а на второй падает с такими ошибками
Code: 49. DB::Exception: Table {} has its shared ID to be different from one from the create query:
While collecting tables for backup in database db1. (LOGICAL_ERROR)
2:
Code: 566. DB::ErrnoException: Cannot rmdir /backups/clickhouse/, errno: 39, strerror: Directory not empty. (CANNOT_RMDIR)
Конфиги идентичные, УЗ те же
Добрый вечер, хочу немного прояснить как работают мержи, есть такая ситуация: есть 9к колонок(знаю, что это плохо, но к сожалению такая дата модель была построена, они создаются динамически). Приходит значит инсерт, который по факту затрагивает все лишь 100 колонок, когда будут происходить мержи, он все равно все 9к колонок в память кладёт? Или же все таки которые в инсерте? Вижу такую картину, что мержи отваливаются по памяти
Читать полностью…
Replicated* ничего про шарды не знают, там только {shard} макрос в пути может использоваться чтобы реплики разных шардов данные между собой не репилицировали...
суммирование происходит при объединении дата партов (ну и при вставке тоже)
MERGE_PART событие регается на одной из реплик в очередь репликации в ZK и потом уходит на остальные...
реплики независимо мержат одни и теже парты и попутно аггрегируют...
Да, сорри, конкретный текст ошибки потерял, поэтому пришлось вспоминать по смыслу. В любои случае спасибо :)
Читать полностью…
Всем привет, кто в теме вопроса!
Уже писал, проблему так и не решил....
В движке ReplicatedSummingMergeTree суммирование происходит на каждом шарде отдельно?
Если да, то может ли это влиять на то как данные отражаются в Distributed таблице (кол-во строк = кол-ву шардов) и в итоге не 1 строка, а столько строк, на сколько шардов раскидал данные КХ ?
что-то кто-то не понимает.
вот есть у вас большая таблица X
и есть маленькая meta_local созданная на всех нодах и без макроса shard в zk_path
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{uuid}/not-sharded', '{replica}')
если вы будете делать инсерт в meta_local, на любой ноде, записи разреплицируются на все ноды
если вы будете использовть meta_local в запросах, с join, с in, .... , результат будет правильный всегда, никаких ошибок про double не будет.
ВНИМАНИЕ ВОПРОС: зачем вам distributed таблица meta ? не проще-ли удалить meta и переименовать meta_local в meta ?
так вот вопрос зачем вам distributed таблица meta, если meta_local разреплицированна на все ноды
Читать полностью…
Это улучшило временные показатели.
Благодарю!
Приветствую,
хотел бы узнать статус баги, запларировано ли исправление и если есть сроки?
https://github.com/ClickHouse/ClickHouse/issues/79916
Про join с distributed: если я правильно понял идею того что вы говорите, вы предлагаете иметь тот же самый sharding key на meta и на том, что с ней джойнится, тогда можно всегда просто делать join с локальной метой и не знать проблем. Если да, то так изначально и хотели сделать, но есть пачка DS таблиц, в которых натурально не получилось сделать точно такой же sharding key, а join метой всё же нужен.
Читать полностью…
Попробую, спасибо! Там да, опечатка :)
Читать полностью…
Пробуете правильно, ошибка возникает потому что альтерите больше чем на одной реплике, может даже с ON CLUSTER, не подозревая что оно не учитывает топологию в remote_servers и всё равно командует на каждой.
Просто кидайте альтер на ОДНУ реплику, без ON CLUSTER, на остальные доедет по репликации.
Когда табличка станет побольше и вы всё таки захотите её пошардировать, просто пошардируйтесь по тому же ключу, по которому схлопываете в Replacing, чтобы каждый уник падал всегда в свой же шард, и нормально будет схлопывать.
я никогда не слышал.
проверьте select uuid, table from system.tables where table = ....татаблица
на обоих репликах
одинаковый uuid или нет
Общая память 256гб, строк примерно 1 миллиард, 800гб, replicatedreplacingmergetree
Читать полностью…
СРК?
гугл говорит Irritable bowel syndrome
Синдром раздражённого кишечника
даже инсерт создает 9к колонок.
сколько памяти у вас?
сколько строк в таблице? и какой размер таблицы в ГБ ?
какой движок у таблицы?
понял, без группировок в запросе не обойтись будет
Читать полностью…
да, все так,
все запросы надо делать c groupby чтобы схлопнуть шарды и не смерженные до конца записи
аа вопрос про alter, у думал ошибка про doule apply в join
Читать полностью…
Понятно, не был ясен контекст вопроса изначально. Согласен, distributed таблица не нужна в таком случае.
На всякий случай, сетап из примера выше работал корретно до момента первого alter table, который падал на double apply, на что мне уже был дан ответ "почему".
Потому что мне надо как-то писать во все ноды
Читать полностью…
Нет, meta - это и есть distributed таблица. meta_local - это её локальная версия. Джойню я с meta.
нет не правильно. У вас используется distributed таблица поверх meta ? или вы делаете join прямо с meta ?
Читать полностью…
Кстати, любопытно, а что именно произойдёт, если сразу после миграции сделать какой-нибудь INSERT, например, копирующий таблицу, или выполняющий вставку с новым DDL, пока миграция ещё не доехала до всех реплик? Например:
-- <meta migration code here>
CREATE TABLE meta_v2_local (...)
CREATE TABLE meta_v2_dist (...) ENGINE = Distributed(...)
INSERT INTO meta_v2_dist SELECT * FROM meta
так вам не нужна дистрибьютид таблица, у вас таблица на каждом шарде
>с ошибками double apply
это про джойн с distributed
а, ну и тут забыли очевидно дописать ReplicatedReplacing
Читать полностью…