мы фризим все партишны раз в сутки (см. FREEZE в доках по кликхаусу) - это делается очень быстро, т.к. данные не копируются, а просто создаются hard link'и на файлы с кусками данных из MergeTree таблиц. Такой "бэкап"-снэпшот работает нормально, т.к. кликхаус никогда не меняет созданные файлы - он может только мержить их в более крупные файлы. Такой бэкап также не занимает дополнительное место до тех пор, пока кликхаус не смержил файлы, присутствующие в бэкапе. Такие снэпшоты позволяют быстро откатиться на рабочую версию данных, если они как-нибудь повредились - неправильно сделали неправильный alter table, залили неправильные данные, обновили кликхаус и он почему-то испортил данные :). После создания снэпшота можно спокойно в любое время скопировать его в дешевый бэкап-сторейдж вроде amazon s3 или google cloud storage. Если этого не делать, то данные из снэпшота могут испортиться по двум причинам: 1) при выходе из строя хранилища, на котором лежат данные кликхауса 2) если кто-то случайно или специально удалит / испортит эти данные

Если я правильно понимаю то нельзя одним alter table freeze заыризить сразу все таблицы? Он на каждый новый фриз создаст свою директорию 1,2,3... в /shadow вопрос в том, как это грамотно автоматизировать. Что бы например фриз всех таблиц за сегодня лежал в директории 1

там ничего сложного - четыре режима работы - бэкап / восстановление из бэкапа / архивирование в cloud storage / листинг имеющихся бэкапов. Для каждого режима минимальный набор дополнительных настроек вроде имени таблицы, пути к бэкапу, имени партишна или пути к архиву в cloud storage

Ну например есть 2 источника запросов, один суперважный а второй может подождать

Ну например есть 2 источника запросов, один суперважный а второй может подождать

Нигде маленького примерчика не завалялось?

кстати подскажите, к графане алерты еще не подвезли для КХ?

Скажите пожалуйста кто как мониторит Кликхаус. Возможно у кликхауса есть какой-то порт, при обращении к которому можно собирать метрики? Может быть кто-то использует datadog для мониторинга и написан вотчер соответствующий.

КХ из коробки умеет отправлять метрики по своей работе в Графит. Эти же метрики вы можете получить запросом из таблиц : 'system.asynchronous_metrics', 'system.metrics', 'system.events'

а их же самому можно делать или там проблемы в чем-то?

Скажите пожалуйста кто как мониторит Кликхаус. Возможно у кликхауса есть какой-то порт, при обращении к которому можно собирать метрики? Может быть кто-то использует datadog для мониторинга и написан вотчер соответствующий.

кстати подскажите, к графане алерты еще не подвезли для КХ?

так себе дашборды

поделитесь с комьюнити своими наработками

для себя я отметил 2 самые важные метрики по которым видна деградация КХ: MemoryTracking и QueryThread проблемы с репликацией хорошо отображает : ZooKeeperTransactions

''Это же ОЧЕВИДНО" ©

Привет всем, как такой запрос выполнить SELECT count() as c, vendor FROM storage WHERE c > 100000 GROUP BY vendor?

Судя по интернету и документации - такой возможности нет, возможно, это стоит в недалеких планах?

Avro в планах есть, когда не ясно, возможно уже кто-то занимается.

Всем привет. У меня проблема с подключением внешних словарей, чтобы здесь не дублировать см. на SO: https://stackoverflow.com/questions/51008445/clickhouse-doesnt-see-external-dictionary-config Понимаю, что где-то есть очевидный косяк, но не понимаю где. Есть идеи?

Может в конфиге параметр dictionaries_config изменён?

Нет, более того, я суффикс файла копипастил из него

сделайте посуточные партиции и делайте фриз

попробуй заменить внешний тег yandex на dictionaries

что значит тяжело , они все тут )

До разрабов с которыми я работаю) К этим ребятам я не имею ничего плохого=)

ну тут либо нужен бекап либо нет , особо достукиваться нет смысла

сделайте посуточные партиции и делайте фриз

мы написали собственную утилитку, облегчающую бэкап / восстановление из бэкапа, а также архивирование на google cloud storage. Но она только для внутреннего пользования - в опенсорс не собираемся выкладывать (

А у меня посылка для вас. Но я вам её не дам... Кто ещё что для себя написал?

полистайте в чате тут это обсуждали

@stufently вы про это? так здесь человек просто фризит месячные партиции каждый день, а у меня был вопрос как сделать партиции не месячными, а суточными)

ага нашёл. https://clickhouse.yandex/docs/en/table_engines/custom_partitioning_key/ спасибо

а как изменение временной длительности партиции скажется на производительности селектов? если изменить с месяца до суток. сильно просядет?

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

Как и остальные настройки можно 1) в профиле пользователя указать 2) если используете сессии и пользователь не readonly, то можно просто выполнить set priority=1 перед запросом 3) если используете протокол http - можно просто в урл передать как параметр (снова если пользователь не readonly).

сделайте посуточные партиции и делайте фриз

Дату создания можно пожалуй по modify папки смотреть, но в таком случае имхо будут какие-то дополнительные оверхеды на хранение неоптимизированной разницы промежуточных суточных фризов с финальной месячной партицией

Не нужно делать суточные партиции только ради бекапов, можно фризить каждый день и все фризы что старше N дней удалять

Коллеги, привет; Столкнулись с зависаниями КХ в интеграционных автотестах приложения. Для интеграции используем docker-compose. Между тесткейсам происходит DROP таблиц и создание новых. Столкнулись с проблемой, при которй после некоторого количества тестов КХ перестает обрабатывать запросы. Новые коннекшены отваливаются по таймауту, при этом внутри заранее подключенного clickhose client кх не отвечает на примитивный запрос выборки из system.config. strace -p показывает что КХ висит в futex. Исключили все что могли, подскажите, куда можно копнуть? версия КХ 1.1.54304