Да

оуййййй... больно =_=

Коллеги всем привет! Подскажите, пожалуйста, как через clickhouse-copier организовать резервное копирование моего основного кластера?
Вроде как в документации указанно, что инструмент  clickhouse-copier можно применять для резервного копирования данных вашего кластера.
Я уже выполнил достаточное количество экскрементов, чтобы понять, что после первого копирования всех указанных таблиц для copier он скопирует все данные с моего source_cluster в target_cluster кластер в котором будут лежать мои данные. Но я столкнулся с ситуацией когда спустя сутки я запустил повторный скрипт copier он не перенес на target_cluster новые данные которые появились в главном кластере source_cluster .
Начал делать анализ и понял, что при первом копировании clickhouse-copier отмечает в ZK номера тех партиций что он скопировал а после при последующем копировании данных он не отслеживает изменённый размер ранее скопированных партиций. И последующем выполнении демона clickhouse-copier копирование не выполняется он просто пропускает эти партиции хотя в них появились новые данные.
Подскажите, как в yandex решают эти проблемы с синхронизацией данных своих кластеров?
Или может кто сталкивался с подобной ситуацией и реализовал свой инструмент, который заставляет clickhouse-copier при появлении новых данных заново копировать партиции на target_cluster?
Я понимаю что можно удалить задания copier из ZK и добавить его снова и тогда copier снова прельет все данные FULL . Но если я хочу поддерживать синхронизацию данных между своими кластерами каждый день не буду же я преливать большое кол-во данных FULL каждый день. Или если реализовать скрипт, который будет дропать из БД ZK последние значения партиций чтобы copier преливал данные только этих последних  партиций тем самым у меня будет ежедневный DIFF бекап по всем таблицам. Можно ли задалбливать ZK таким скриптом на ежедневной основе? не станет ли ему плохо ?) и не возникнет ли еше больше проблем)
заранее всем спасибо за консультацию очень буду благодарен!

тут есть много способов решить проблему. Например, из одного кластера в другой можно переливать данные при помощи MaterializedVeiw над реплицируемой таблицей.

Привет!

У меня при выполнении сложного запроса проваливается health check датасорца в спринге: не может установить JDBC-connection.
При этом health check соседнего пода чувствует себя нормально, он точно так же коннектится к той же базе.

Подскажите, пожалуйста, где стоит искать проблему.

Использую clickhouse версии 20.12.3.3, Clickhouse4j от blynk версии 1.4.4.

наверно будет дополнительная нагрузка на считывание этих данных при использовании materializedVeiw Не хотелось бы нагружать пром кластер . Я просто надеялся при помощи copier ночью выполнять копирование данных пришедших за день когда на основном кластере небольшая нагрузка

если нужно просто копирование, то лучше посмотреть на clickhouse-backup бинарь

Мне вот интересно как в yandex реализованно все это репликации межкластерные

Можно же построить MV поверх remote, в целом

Скажите, а можно ли в секции remote использовать одни и те же сервера в нескольких конфигурациях шардов/реплик?

... пробовали вставлять и в реестр и в файл c:\windows\odbc.ini такую строку:
&http_send_timeout=10000&send_timeout=10000&http_receive_timeout=10000&receive_timeout=10000&socketTimeout=10000&dataTransferTimeout=10000
Не "взлетело" :(

Всем привет!
Подскажите, почему при условии ```AND time between parseDateTimeBestEffort('01.01.2021')
AND parseDateTimeBestEffort('01.02.2021’)``` попадает дата 31.12.2020 ?

utc

действительно, спасибо)

guys, кто-нибудь пишет логи из флюентбита в кликхаус?

у меня куча ошибок о его вставках(

тут мне сказали что проблема в Distributed таблицах (на основе логов что я кидал)

но у меня нет таких таблиц

создал issue, может кто сталкивался с такиим? https://github.com/ClickHouse/ClickHouse/issues/20964

увеличение background schedule pool помогло, благодарю. в более новых версиях сервера выделен отдельный пул, но версии не лтс, поэтому пока что решим так проблему.