серверов zookeeper в конфиги), после чего рестартовать каждую ноду кластера кликхауса по очереди, можете подсказать - грозит ли такой порядок действий какой то недоступностью кликхауса?
речь о файле конфигураций conf.d/zookeeper-servers.xml
Никто никогда не обновлял конфиги кликхауса?
рестарт не нужен. remote_servers обновляется без рестарта. алгоритм такой, у вас есть кластер из 4 серверов 2 шарда 2 реплики, s1, s2, s3, s4, вы добавляете еще 1/2/n сервера s5, s6 1. ставите КХ на s5, s6, конфигурите макросы shard, replica, запускаете 2. создаете все таблицы на s5, s6 3. если s5 s6 это новые реплики, дожидаетесь конца репликации, select * from system.replication_queue, смотрите размеры таблиц, что они наполнились и имеют все данные 4. обновляете remote_servers на s1 s2 s3 s4 5. добавляете s5 , s6 в dns / haproxy /nginx -- короче в свою entry_point
Спасибо за инфу! Вскоре тоже пригодится, но я имел ввиду изменение конфигурации при добавлении новых серверов zookeeper, а не кликхаус
вам надо заменить ноды зукипера или вы хотите из 3 zk сделать 5 ?
Из 3 сделали 5, теперь надо в конфиги кликхауса дописать две недостающие
сразу скажу что 5 это плохая идея, это медленее чем 3. просто пропишите новые ноды ZK в конфиг КХ, в современных версиях КХ рестарт КХ не нужен
Спасибо! А насчёт скорости, спасибо за информацию, попробую что нибудь найти/почитать на эту тему. Делаем для отказоустойчивости, было 3 в одном цоде, добавили 2 в другом
и сколько пинг между цодами? сколько летенси в милисекундах?
Avg latency в пределах 3мс, но это тест - он не показателен, до прода ещё не доехал конфиг, как раз разбираюсь как обновлять этот конфиг, чтобы без потерь
Обсуждают сегодня