Skip to main content
В этом примере вы узнаете, как настроить простой кластер ClickHouse с репликацией данных. Настроено пять серверов. Два из них используются для хранения копий данных. Остальные три сервера используются для координации репликации данных.
Ниже показана архитектура кластера, который вы будете настраивать:
Хотя ClickHouse Server и ClickHouse Keeper можно запускать вместе на одном сервере, мы настоятельно рекомендуем использовать выделенные хосты для ClickHouse Keeper в производственных средах — именно этот подход мы и продемонстрируем в данном примере.Серверы Keeper могут быть менее мощными, и 4 ГБ оперативной памяти обычно достаточно для каждого сервера Keeper до тех пор, пока ваши серверы ClickHouse не станут достаточно крупными.

Предварительные требования

1

Настройка структуры каталогов и тестовой среды

Файлы с примерамиСледующие шаги помогут вам с нуля настроить кластер. Если вы хотите пропустить их и сразу перейти к запуску кластера, файлы с примерами можно взять из репозитория examples каталог «docker-compose-recipes».
В этом руководстве вы будете использовать Docker compose для настройки кластера ClickHouse. Данную конфигурацию можно адаптировать для работы на отдельных локальных машинах, виртуальных машинах или облачных инстансах.Выполните следующие команды, чтобы создать структуру каталогов для этого примера:
Добавьте следующий файл docker-compose.yml в каталог cluster_1S_2R:
docker-compose.yml
Создайте следующие подкаталоги и файлы:
  • Каталог config.d содержит файл конфигурации сервера ClickHouse config.xml, в котором задаётся пользовательская конфигурация для каждого узла ClickHouse. Эта конфигурация объединяется с файлом конфигурации ClickHouse config.xml по умолчанию, который входит в состав каждой установки ClickHouse.
  • Каталог users.d содержит файл пользовательской конфигурации users.xml, в котором задаётся пользовательская конфигурация для пользователей. Эта конфигурация объединяется с файлом конфигурации ClickHouse users.xml по умолчанию, который входит в состав каждой установки ClickHouse.
Пользовательские каталоги конфигурацииРекомендуется использовать каталоги config.d и users.d при создании собственной конфигурации, а не изменять напрямую конфигурацию по умолчанию в /etc/clickhouse-server/config.xml и etc/clickhouse-server/users.xml.Строка
обеспечивает, что разделы конфигурации, определённые в каталогах config.d и users.d, переопределяют разделы конфигурации по умолчанию, заданные в стандартных файлах config.xml и users.xml.
2

Настройка узлов ClickHouse

Настройка сервера

Теперь измените каждый пустой файл конфигурации config.xml, расположенный по пути fs/volumes/clickhouse-{}/etc/clickhouse-server/config.d. Выделенные ниже строки необходимо изменить так, чтобы они соответствовали параметрам конкретного узла:
Каждый раздел приведённого выше конфигурационного файла подробно описан ниже.

Сеть и логирование

Возможность внешних подключений через сетевой интерфейс включается при активации настройки listen host. Это гарантирует, что хост сервера ClickHouse доступен с других хостов:
Порт HTTP API установлен на 8123:
TCP-порт для взаимодействия по собственному протоколу ClickHouse между clickhouse-client и другими инструментами ClickHouse, а также между clickhouse-server и другими clickhouse-servers, установлен в 9000:
Логирование настраивается в блоке <logger>. Приведённая ниже конфигурация создаёт отладочный лог с ротацией по достижении 1000 МБ, выполняемой трижды:
Дополнительные сведения о конфигурации логирования см. в комментариях в стандартном файле конфигурации ClickHouse.

Конфигурация кластера

Конфигурация кластера задаётся в блоке <remote_servers>. Здесь определяется имя кластера cluster_1S_2R.Блок <cluster_1S_2R></cluster_1S_2R> определяет структуру кластера с помощью настроек <shard></shard> и <replica></replica> и служит шаблоном для распределённых DDL-запросов — запросов, выполняемых по всему кластеру с использованием предложения ON CLUSTER. По умолчанию распределённые DDL-запросы разрешены, однако их можно отключить с помощью параметра allow_distributed_ddl_queries.internal_replication установлен в true, чтобы данные записывались только в одну из реплик.
Для каждого сервера указываются следующие параметры:

Конфигурация Keeper

Секция <ZooKeeper> указывает ClickHouse, где запущен ClickHouse Keeper (или ZooKeeper). Поскольку мы используем кластер ClickHouse Keeper, необходимо указать каждый узел (<node>) кластера вместе с его hostname и номером порта — с помощью тегов <host> и <port> соответственно.Настройка ClickHouse Keeper рассматривается на следующем шаге руководства.
Хотя ClickHouse Keeper можно запускать на том же сервере, что и ClickHouse Server, в промышленной среде мы настоятельно рекомендуем запускать ClickHouse Keeper на выделенных хостах.

Конфигурация макросов

Кроме того, раздел <macros> используется для определения подстановок параметров для реплицированных таблиц. Они перечислены в system.macros и позволяют использовать подстановки вида {shard} и {replica} в запросах.
Они будут определяться по-разному в зависимости от конфигурации кластера.

Конфигурация пользователя

Теперь внесите следующие изменения в каждый пустой файл конфигурации users.xml, расположенный по пути fs/volumes/clickhouse-{}/etc/clickhouse-server/users.d:
/users.d/users.xml
В этом примере пользователь по умолчанию настроен без пароля для простоты. На практике такой подход не рекомендуется.
В этом примере файл users.xml одинаков для всех узлов кластера.
3

Настройка ClickHouse Keeper

Настройка Keeper

Чтобы репликация работала, необходимо развернуть и настроить кластер ClickHouse Keeper. ClickHouse Keeper обеспечивает систему координации для репликации данных, выступая в качестве замены ZooKeeper, который также можно использовать. Однако рекомендуется использовать ClickHouse Keeper, так как он обеспечивает более строгие гарантии и надежность, а также потребляет меньше ресурсов, чем ZooKeeper. Для Высокой доступности и сохранения кворума рекомендуется запускать как минимум три узла ClickHouse Keeper.
ClickHouse Keeper может работать на любом узле кластера вместе с ClickHouse, однако рекомендуется запускать его на выделенном узле, что позволяет масштабировать кластер ClickHouse Keeper и управлять им независимо от кластера базы данных.
Создайте файлы keeper_config.xml для каждого узла ClickHouse Keeper, выполнив следующую команду из корневой папки примера:
Измените пустые файлы конфигурации, созданные в каждом каталоге узла fs/volumes/clickhouse-keeper-{}/etc/clickhouse-keeper. Выделенные ниже строки нужно изменить для каждого узла:
/clickhouse-keeper/keeper_config.xml
Каждый файл конфигурации должен содержать следующую уникальную конфигурацию (показана ниже). Используемый server_id должен быть уникальным для соответствующего узла ClickHouse Keeper в кластере и совпадать с <id> сервера, заданным в разделе <raft_configuration>. tcp_port — порт, используемый клиентами ClickHouse Keeper.
Следующий раздел используется для настройки серверов, которые участвуют в кворуме алгоритма консенсуса Raft:
ClickHouse Cloud упрощает администрированиеClickHouse Cloud снимает операционную нагрузку, связанную с управлением сегментами и репликами. Платформа автоматически обеспечивает высокую доступность, репликацию и масштабирование. Вычислительные ресурсы и хранилище разделены и масштабируются по мере необходимости без ручной настройки и постоянного обслуживания.Подробнее
4

Проверьте настройку

Убедитесь, что Docker запущен на вашем компьютере. Запустите кластер командой docker-compose up из корневого каталога cluster_1S_2R:
Вы должны увидеть, как Docker начинает скачивать образы ClickHouse и Keeper, а затем запускает контейнеры:
Чтобы проверить, что кластер запущен, подключитесь к clickhouse-01 или clickhouse-02 и выполните следующий запрос. Ниже показана команда для подключения к первому узлу:
Если всё прошло успешно, будет отображено приглашение клиента ClickHouse:
Выполните следующий запрос, чтобы проверить, какие топологии кластеров заданы для каких хостов:
Query
Response
Выполните следующий запрос, чтобы проверить состояние кластера ClickHouse Keeper:
Query
Response
Команда mntr также часто используется, чтобы убедиться, что ClickHouse Keeper запущен, и получить информацию о состоянии и ролях трёх узлов Keeper. В конфигурации, используемой в этом примере, вместе работают три узла. Они выберут leader, а остальные узлы будут followers.Команда mntr предоставляет информацию о производительности, а также о том, является ли конкретный узел follower или leader.
Возможно, вам потребуется установить netcat, чтобы отправить команду mntr в Keeper. Информацию о загрузке см. на странице nmap.org.
Выполните приведённую ниже команду в оболочке на clickhouse-keeper-01, clickhouse-keeper-02 и clickhouse-keeper-03, чтобы проверить состояние каждого узла Keeper. Команда для clickhouse-keeper-01 показана ниже:
Ниже приведён пример ответа от узла-реплики:
Response
Ниже приведён пример ответа от узла-лидера:
Response
Итак, вы успешно настроили кластер ClickHouse с одним сегментом и двумя репликами. На следующем шаге вы создадите таблицу в кластере.
5

Создайте базу данных

Теперь, когда вы убедились, что cluster настроен правильно и работает, вам предстоит заново создать ту же table, которая использовалась в обучающем примере набора данных UK property prices. Он содержит около 30 миллионов строк с ценами сделок с недвижимостью в Англии и Уэльсе начиная с 1995 года.Подключитесь к клиенту на каждом хосте, выполнив следующие команды в отдельных вкладках или окнах терминала:
Вы можете выполнить приведённый ниже запрос в clickhouse-client на каждом хосте, чтобы убедиться, что пока не создано никаких баз данных, кроме баз данных по умолчанию:
Query
Response
На клиенте clickhouse-01 выполните следующий распределённый DDL-запрос с предложением ON CLUSTER, чтобы создать новую базу данных uk:
Вы можете снова выполнить тот же запрос, что и раньше, в клиенте на каждом хосте, чтобы убедиться, что база данных была создана во всём кластере, хотя запрос был выполнен только на clickhouse-01:
6

Создайте таблицу на кластере

Теперь, когда база данных создана, создайте таблицу на кластере. Выполните следующий запрос на любом из клиентских хостов:
Обратите внимание, что он идентичен запросу, использованному в исходном операторе CREATE в руководстве по примеру набора данных UK property prices, за исключением предложения ON CLUSTER и использования движка ReplicatedMergeTree.Предложение ON CLUSTER предназначено для распределённого выполнения DDL-запросов (Data Definition Language), таких как CREATE, DROP, ALTER и RENAME, и гарантирует, что эти изменения схемы будут применены на всех узлах кластера.Движок ReplicatedMergeTree работает так же, как обычный движок таблицы MergeTree, но также обеспечивает репликацию данных.Вы можете выполнить приведённый ниже запрос из клиента clickhouse-01 или clickhouse-02, чтобы убедиться, что таблица создана на всём кластере:
Query
Response
7

Вставка данных

Поскольку набор данных велик и его полный приём занимает несколько минут, для начала мы вставим лишь небольшое подмножество.Вставьте меньшее подмножество данных, используя приведённый ниже запрос на clickhouse-01:
Обратите внимание, что данные полностью реплицированы на каждом хосте:
Чтобы продемонстрировать, что происходит при отказе одного из хостов, создайте простую тестовую базу данных и тестовую таблицу на любом из хостов:
Как и в случае с таблицей uk_price_paid, данные можно вставлять с любого хоста:
Но что произойдёт, если один из хостов недоступен? Чтобы смоделировать эту ситуацию, остановите clickhouse-01, выполнив команду:
Убедитесь, что хост недоступен, выполнив команду:
Response
Теперь, когда clickhouse-01 недоступен, вставьте ещё одну строку данных в тестовую таблицу и выполните запрос к ней:
Response
Теперь перезапустите clickhouse-01 с помощью следующей команды (после можно снова выполнить docker-compose ps для проверки):
Снова выполните запрос к тестовой таблице из clickhouse-01, предварительно запустив docker exec -it clickhouse-01 clickhouse-client:
Query
Response
Если на данном этапе вы хотите загрузить полный набор данных о ценах на недвижимость в Великобритании, чтобы поэкспериментировать с ним, выполните следующие запросы:
Выполните запрос к таблице из clickhouse-02 или clickhouse-01:
Query
Response

Заключение

Преимущество этой топологии кластера в том, что при наличии двух реплик данные хранятся на двух отдельных узлах. Если один узел выйдет из строя, другая реплика продолжит обслуживать запросы без какой-либо потери данных. Это исключает единичные точки отказа на уровне хранения. Когда один узел отключается, оставшаяся реплика по-прежнему может:
  • Обрабатывать запросы на чтение без прерываний
  • Принимать новые записи (в зависимости от ваших настроек согласованности)
  • Поддерживать доступность сервиса для приложений
Когда вышедший из строя узел снова становится доступен, он может:
  • Автоматически синхронизировать недостающие данные с исправной реплики
  • Возобновить нормальную работу без ручного вмешательства
  • Быстро восстановить полную избыточность
В следующем примере мы рассмотрим, как настроить кластер с двумя сегментами, но только одной репликой.
Последнее изменение 23 июля 2026 г.