Репликация + Масштабирование
В этом примере вы научитесь настраивать простой кластер ClickHouse, который как реплицирует, так и масштабируется. Он состоит из двух шардов и двух реплик с 3-узловым кластером ClickHouse Keeper для управления координацией и поддержанием кворума в кластере.
Архитектура кластера, который вы будете настраивать, показана ниже:

Хотя возможно запускать ClickHouse Server и ClickHouse Keeper на одном и том же сервере, мы настоятельно рекомендуем использовать выделенные хосты для ClickHouse Keeper в производственных средах, что является подходом, который мы продемонстрируем в этом примере.
Серверы Keeper могут быть меньшими, и обычно 4 ГБ ОП достаточно для каждого сервера Keeper, пока ваши серверы ClickHouse не вырастут в размерах.
Предварительные условия
- Вы уже настраивали локальный сервер ClickHouse
- Вы знакомы с основными концепциями конфигурации ClickHouse, такими как файлы конфигурации
- У вас на машине установлен docker
Установить структуру каталогов и тестовую среду
Следующие шаги помогут вам настроить кластер с нуля. Если вы предпочитаете пропустить эти шаги и сразу перейти к запуску кластера, вы можете получить примерные файлы из репозитория примеров
В этом уроке вы будете использовать Docker compose для настройки кластера ClickHouse. Эта настройка может быть изменена для работы на отдельных локальных машинах, виртуальных машинах или облачных инстансах.
Выполните следующие команды для настройки структуры каталогов для этого примера:
Добавьте следующий файл docker-compose.yml
в директорию clickhouse-cluster
:
Создайте следующие подпапки и файлы:
- Директория
config.d
содержит файл конфигурации сервера ClickHouseconfig.xml
, в котором определяется пользовательская конфигурация для каждого узла 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
.
Настройка узлов ClickHouse
Настройка сервера
Теперь измените каждый пустой файл конфигурации config.xml
, расположенный в fs/volumes/clickhouse-{}/etc/clickhouse-server/config.d
. Строки, выделенные ниже, необходимо изменить, чтобы они были специфичны для каждого узла:
Директория | Файл |
---|---|
fs/volumes/clickhouse-01/etc/clickhouse-server/config.d | config.xml |
fs/volumes/clickhouse-02/etc/clickhouse-server/config.d | config.xml |
fs/volumes/clickhouse-03/etc/clickhouse-server/config.d | config.xml |
fs/volumes/clickhouse-04/etc/clickhouse-server/config.d | config.xml |
Каждый раздел вышеуказанного файла конфигурации объясняется более подробно ниже.
Сетевая конфигурация и логирование
Внешняя связь с сетевым интерфейсом включается активацией настройки listen host. Это гарантирует, что хост сервера ClickHouse доступен для других хостов:
Порт для HTTP API установлен на 8123
:
TCP-порт для взаимодействия по нативному протоколу ClickHouse между clickhouse-client и другими нативными инструментами ClickHouse, а также clickhouse-server и другими clickhouse-server установлен на 9000
:
Конфигурация логирования определяется в блоке <logger>
. Эта примерная конфигурация дает вам отладочный журнал, который будет рождаться при достижении 1000M трижды:
Для получения дополнительной информации о конфигурации логирования смотрите комментарии, включенные в стандартный файл конфигурации ClickHouse configuration file.
Конфигурация кластера
Конфигурация кластера устанавливается в блоке <remote_servers>
.
Здесь задается имя кластера cluster_2S_2R
.
Блок <cluster_2S_2R></cluster_2S_2R>
определяет структуру кластера,
используя настройки <shard></shard>
и <replica></replica>
, и выступает в качестве
темплейта для распределенных DDL запросов, которые выполняются по всему
кластеру с использованием оператора ON CLUSTER
. По умолчанию распределенные DDL запросы
разрешены, но также могут быть отключены с помощью настройки allow_distributed_ddl_queries
.
internal_replication
установлен в true, чтобы данные записывались только в одну из реплик.
Раздел <cluster_2S_2R></cluster_2S_2R>
определяет структуру кластера
и выступает в качестве шаблона для распределенных DDL запросов, которые выполняются
по всему кластеру с использованием оператора ON CLUSTER
.
Конфигурация Keeper
Секция <ZooKeeper>
указывает ClickHouse, где работает ClickHouse Keeper (или ZooKeeper).
Поскольку мы используем кластер ClickHouse Keeper, каждый <node>
кластера должен быть указан,
вместе с его именем хоста и номером порта, используя теги <host>
и <port>
соответственно.
Настройка ClickHouse Keeper объясняется на следующем шаге урока.
Хотя возможно запустить ClickHouse Keeper на том же сервере, что и сервер ClickHouse, в производственных средах мы настоятельно рекомендуем, чтобы ClickHouse Keeper работал на выделенных хостах.
Конфигурация макросов
Кроме того, секция <macros>
используется для определения параметров замещения для
реплицируемых таблиц. Они перечислены в system.macros
и позволяют использовать замещения
такие как {shard}
и {replica}
в запросах.
Конфигурация пользователей
Теперь измените каждый пустой файл конфигурации users.xml
, расположенный в
fs/volumes/clickhouse-{}/etc/clickhouse-server/users.d
следующим образом:
В этом примере пользователь по умолчанию настраивается без пароля для простоты. На практике это не рекомендуется.
В этом примере каждый файл users.xml
идентичен для всех узлов в кластере.
Настройка ClickHouse Keeper
Далее вы настроите 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
. Выделенные строки ниже необходимо изменить так, чтобы они были специфичны для каждого узла:
Директория | Файл |
---|---|
fs/volumes/clickhouse-keeper-01/etc/clickhouse-server/config.d | keeper_config.xml |
fs/volumes/clickhouse-keeper-02/etc/clickhouse-server/config.d | keeper_config.xml |
fs/volumes/clickhouse-keeper-03/etc/clickhouse-server/config.d | keeper_config.xml |
Каждый файл конфигурации будет содержать следующую уникальную конфигурацию (представленную ниже).
server_id
, используемый для этого конкретного узла ClickHouse Keeper в кластере, должен быть уникальным и соответствовать значению <id>
, определенному в разделе <raft_configuration>
.
tcp_port
— это порт, используемый клиентами ClickHouse Keeper.
Следующий раздел используется для настройки серверов, которые участвуют в квorum для алгоритма Raft:
ClickHouse Cloud устраняет операционную нагрузку, связанную с управлением шардами и репликами. Платформа автоматически обрабатывает задачи высокой доступности, репликации и принятия решений о масштабировании. Вычисления и хранилище разделены и масштабируются в зависимости от спроса без необходимости в ручной настройке или постоянном обслуживании.
Протестируйте настройку
Убедитесь, что docker работает на вашем компьютере.
Запустите кластер, используя команду docker-compose up
из корневого каталога директории cluster_2S_2R
:
Вы должны увидеть, как docker начинает загружать образы ClickHouse и Keeper, а затем запускать контейнеры:
Чтобы убедиться, что кластер работает, подключитесь к любому из узлов и выполните следующий запрос. Команда для подключения к первому узлу показана:
Если все прошло успешно, вы увидите подсказку клиента ClickHouse:
Выполните следующий запрос, чтобы проверить, какие топологии кластера определены для каких хостов:
Выполните следующий запрос, чтобы проверить статус кластера ClickHouse Keeper:
Команда mntr
также часто используется для проверки того, что ClickHouse Keeper работает, и для получения информации о состоянии отношений между тремя узлами Keeper. В конфигурации, используемой в этом примере, три узла работают совместно. Узлы будут выбирать лидера, а оставшиеся узлы станут последователями.
Команда mntr
предоставляет информацию, связанную с производительностью, а также о том, является ли конкретный узел последователем или лидером.
Возможно, вам потребуется установить netcat
, чтобы отправить команду mntr
в Keeper. Пожалуйста, смотрите страницу nmap.org для информации о загрузке.
Запустите команду ниже из командной строки на clickhouse-keeper-01
, clickhouse-keeper-02
и clickhouse-keeper-03
, чтобы проверить статус каждого узла Keeper. Команда для clickhouse-keeper-01
показана ниже:
Ответ ниже показывает пример ответа от узла-последователя:
Ответ ниже показывает пример ответа от узла-лидера:
Таким образом, вы успешно настроили кластер ClickHouse с двумя шардми и двумя репликами. На следующем шаге вы создадите таблицу в кластере.
Создать базу данных
Теперь, когда вы убедились, что кластер правильно настроен и работает, вы воссоздадите ту же таблицу, что использовалась в учебнике по примеру набора данных Цены на недвижимость в Великобритании. Она состоит примерно из 30 миллионов строк цен, уплаченных за недвижимость в Англии и Уэльсе с 1995 года.
Подключитесь к клиенту каждого хоста, выполнив каждую из следующих команд из отдельных терминалов вкладок или окон:
Вы можете выполнить запрос ниже из клиента clickhouse каждого хоста, чтобы подтвердить, что базы данных еще не созданы, кроме стандартных:
Из клиента clickhouse-01
выполните следующий распределенный DDL запрос с использованием
оператора ON CLUSTER
, чтобы создать новую базу данных под названием uk
:
Вы снова можете выполнить тот же запрос из клиента каждого хоста
чтобы подтвердить, что база данных была создана по всему кластеру, несмотря на выполнение
запроса только из clickhouse-01
:
Создать распределенную таблицу в кластере
Теперь, когда база данных была создана, следующим шагом будет создание распределенной таблицы.
Распределенные таблицы - это таблицы, которые имеют доступ к шардам, расположенным на различных
узлах и определяются с помощью движка таблицы Distributed
. Распределенная таблица
служит интерфейсом через все шард в кластере.
Выполните следующий запрос из любого клиента хоста:
Обратите внимание, что он идентичен запросу, использованному в первоначальном операторе CREATE
учебника по
примеру набора данных Цены на недвижимость в Великобритании,
за исключением оператора ON CLUSTER
и использования движка ReplicatedMergeTree
.
Оператор ON CLUSTER
предназначен для распределенного выполнения DDL (язык определения данных)
запросов, таких как CREATE
, DROP
, ALTER
и RENAME
, гарантируя, что эти
изменения схемы будут применены на всех узлах в кластере.
Движок ReplicatedMergeTree
работает так же, как и обычный движок таблицы MergeTree
, но также будет реплицировать данные.
Он требует указания двух параметров:
zoo_path
: Путь Keeper/ZooKeeper к метаданным таблицы.replica_name
: Имя реплики таблицы.
Параметр zoo_path
может быть установлен на любое значение, которое вы выберете, хотя рекомендуется следовать
конвенции использования префикса
где:
{database}
и{table}
будут автоматически заменены.{shard}
и{replica}
- это макросы, которые были определены ранее в файлеconfig.xml
каждого узла ClickHouse.
Вы можете выполнить запрос ниже из клиента каждого хоста, чтобы подтвердить, что таблица была создана по всему кластеру:
Вставка данных в распределенную таблицу
Чтобы вставить данные в распределированную таблицу, оператор ON CLUSTER
не может быть использован, так как он не применяется к DML (язык манипуляции данными) запросам, таким как INSERT
, UPDATE
,
и DELETE
. Для вставки данных необходимо использовать
Distributed
движок таблицы.
Из любого клиента хоста выполните следующий запрос, чтобы создать распределенную таблицу
с использованием существующей таблицы, которую мы создали ранее с ON CLUSTER
и использованием
ReplicatedMergeTree
:
На каждом хосте вы теперь увидите следующие таблицы в базе данных uk
:
Данные могут быть вставлены в таблицу uk_price_paid_distributed
из любого клиента хоста с использованием следующего запроса:
Выполните следующий запрос, чтобы подтвердить, что вставленные данные были равномерно распределены по узлам нашего кластера: