кх? есть отдельный сервер с данными аналитики, к нему нужно поднять реплику, есть возможность это сделать безболезненно?
Добрый день. Безболезненно наверное нет, нужно менять движок таблиц на репликейтед
- поднять zookeeper или clickhouse-keeper (он пока экспериментальный) https://www.howtoforge.com/tutorial/how-to-install-apache-zookeeper-on-ubuntu-2004/ - прописать его на обоих нодах в секции конфига <yandex><zookeeper> /etc/clickhouse/config.d/zookeeper.xml https://clickhouse.tech/docs/en/operations/server-configuration-parameters/settings/#server-settings_zookeeper - прописать <remote_servers> на обоих нодах тоже через config.d https://clickhouse.tech/docs/en/operations/server-configuration-parameters/settings/#server-settings-remote-servers см. пример кластера тут https://clickhouse.tech/docs/en/engines/table-engines/special/distributed/ это нужно для того когда появится ВТОРОЙ шард - прописать <yandex><macros> правильно на обоих нодах то же через config.d https://clickhouse.tech/docs/en/operations/server-configuration-parameters/settings/#macros см. как макросы прописываются в доке https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/replication/ - текущие таблицы для одного сервере должны быть с Engine=MergeTree и надо будет конвертировать их в ReplicatedMergeTree на обоих репликах новые таблицы ReplicatedMergeTree надо будет создать РУКАМИ... не забыть правильно макросы задать в параметрах ReplicatedMergeTree https://kb.altinity.com/altinity-kb-setup-and-maintenance/altinity-kb-converting-mergetree-to-replicated - подождать пока данные реплицируются - создать какой то load balancer например chproxy или просто nginx перед этими двумя нодами upstream + proxy_pass - когда потребуется поднять второй шард прочитать еще раз что такое Engine=distributed - установить две новые ноды, прописать на двух новых нодах правильно macros - создать пустые ReplicatedMergeTree таблицы -добавить новый шард из двух реплик на всех 4 нодах в remote_servers - не забыть про zookeeper
в общем это не как MySQL ;) xtrabackup —master-info; который сделает CHANGE MASTER TO ... START MYSQL SLAVE; и алга =)
хм, у меня больше половины таблиц в collapsingmergetree, прям стало любопытно, как оно переживет
разницы между CollapsingMergeTree и обычным MergeTree нет, они как были так и осались это ЛОКАЛЬНЫЕ Таблицы в рамках одного сервера они не реплицируемы чтобы были реплицируемые надо чтобы серверов было УЖЕ ДВА и чтобы был ZK и надо конвертировать в ReplicatedCollapsingMergeTree вы видимо вообще не понимаете как репликация в clickhouse Работает ...
поэтому и спрашиваю) у меня просто бэк в postgres и oracle) пока читаю официальную документацию, попробую на тесте поэксперементировать
ок. тогда попробуйте прочитать несколько раз https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/replication/
Спасибо! А не подскажите, если общий размер базы в КХ порядка 5 Тб и я хочу сделать одну реплику, то, поднимая дополнительные zookeeper на других серверах как понять сколько под него оперативы оптимально будет?
"поднимая дополнительные zookeeper" не очень понятно что имеете ввиду данные в zookeeper не шардятся все инстансы зукипер имеют одинаковые данные и синхронизируют изменения между собой объем оперативы ZK зависит от интенсивности INSERT вставок в clickhouse... ZK используется только для передачи метаданных новых партов и регистрации реплик ну и для Distributed DDL ( запросы которые модицируют структуру и выполнятся на ON CLUSTER ) Сами данные по http забираются репликой самостоятельно с той реплики которая зарегистрировала новый кусок данных (data part, см. system.parts в документации) 5 Терабайт, это прям вам надо отдельно скопировать и потом уже реплику аттачить...
>5 Терабайт, это прям вам надо отдельно скопировать и потом уже реплику аттачить... вот это меня всегда интересовало, если есть клонированные данные на новой ноде, можно ли приаттачить реплику. сработает ли подобный процесс? - создать replicated MT на новой ноде - system stop replica - положить файлы в детачед и аттачнуть - start repiica?
Понял, спасибо, а про доп. ZK имел в виду,что везде же советуют минимум 3 ZK ноды использовать.
по идее да, но фиг знает как на практике я лично 5Tb Не пробовал =) придет denny и скажет что я ерунду говорю
ок, это должны быть 3 одинаковые ноды связанные в ZK кластер и еще они должны быть отдельно от clickhouse чтобы не бороться с ним за диск и CPU потому что ZK при интенсивной вставке (в смысле кол-во запросов INSERT а не строк) вполне себе способен выжирать CPU и диск
да, ждем. у меня вопрос скорее по поводу того что когда диски на массиве, там можно клонировать и благодаря дедупу, это будет в делом секунд.
Сделал всё по этим гайдам, но на обоих серверах КХ не запускается и пишет следующую ошибку в лог: <Error> Application: Not found: remote_servers.logger.shard.replica.host
remote_servers покажите из /var/lib/clickhouse/preprocessed_configs/config.xml?
Как можно автоматически настроить конфиги, если добавил ещё 2 сервера к примеру?
на мастере: <remote_servers> <logger> <shard> <replica> <internal_replication>true</internal_replication> <port>9000</port> <user>мой юзер</user> <password>мой пароль</password> </replica> <replica> <host>айпи слейв сервера тут</host> <port>9440</port> <user>мой юзер</user> <password>мой пароль</password> <secure>1</secure> </replica> </shard> </logger> на слейве: <remote_servers> <logger> <shard> <replica> <internal_replication>true</internal_replication> <port>9000</port> <user>мой юзер</user> <password>мой пароль</password> </replica> <replica> <host>айпи мастер сервера тут</host> <port>9440</port> <user>мой юзер</user> <password>мой пароль</password> <secure>1</secure> </replica> </shard> </logger>
везде host нужен внутри <replica>
шел 13ый час моих тщетных попыток и наконец заработало. Спасибо!)
Обсуждают сегодня