Репликация для отказоустойчивости
Описание
В этой архитектуре настроены пять серверов. Два из них используются для хранения копий данных. Оставшиеся три сервера используются для координации репликации данных. На этом примере мы создадим базу данных и таблицу, которые будут реплицироваться на обеих узлах данных, используя движок таблиц ReplicatedMergeTree.
Уровень: Базовый
Terminology
Replica
A copy of data. ClickHouse always has at least one copy of your data, and so the minimum number of replicas is one. This is an important detail, you may not be used to counting the original copy of your data as a replica, but that is the term used in ClickHouse code and documentation. Adding a second replica of your data provides fault tolerance.
Shard
A subset of data. ClickHouse always has at least one shard for your data, so if you do not split the data across multiple servers, your data will be stored in one shard. Sharding data across multiple servers can be used to divide the load if you exceed the capacity of a single server. The destination server is determined by the sharding key, and is defined when you create the distributed table. The sharding key can be random or as an output of a hash function. The deployment examples involving sharding will use rand()
as the sharding key, and will provide further information on when and how to choose a different sharding key.
Distributed coordination
ClickHouse Keeper provides the coordination system for data replication and distributed DDL queries execution. ClickHouse Keeper is compatible with Apache ZooKeeper.
Среда
Диаграмма архитектуры

Узел | Описание |
---|---|
clickhouse-01 | Данные |
clickhouse-02 | Данные |
clickhouse-keeper-01 | Распределенная координация |
clickhouse-keeper-02 | Распределенная координация |
clickhouse-keeper-03 | Распределенная координация |
В производственных средах мы настоятельно рекомендуем использовать выделенные хосты для ClickHouse Keeper. В тестовой среде приемлемо запускать ClickHouse Server и ClickHouse Keeper на одном и том же сервере. Другой базовый пример, Горизонтальное масштабирование, использует этот метод. В этом примере мы представляем рекомендованный метод разделения Keeper и ClickHouse Server. Сервера Keeper могут быть меньшими, 4 ГБ ОЗУ обычно достаточно для каждого сервера Keeper, пока ваши сервера ClickHouse не станут очень большими.
Установка
Установите сервер и клиент ClickHouse на два сервера clickhouse-01
и clickhouse-02
, следуя инструкциям для вашего типа архива (.deb, .rpm, .tar.gz и т.д.).
Установите ClickHouse Keeper на три сервера clickhouse-keeper-01
, clickhouse-keeper-02
и clickhouse-keeper-03
, следуя инструкциям для вашего типа архива (.deb, .rpm, .tar.gz и т.д.).
Редактирование файлов конфигурации
When configuring ClickHouse Server by adding or editing configuration files you should:
- Add files to
/etc/clickhouse-server/config.d/
directory - Add files to
/etc/clickhouse-server/users.d/
directory - Leave the
/etc/clickhouse-server/config.xml
file as it is - Leave the
/etc/clickhouse-server/users.xml
file as it is
Конфигурация clickhouse-01
Для clickhouse-01 имеется пять файлов конфигурации. Вы можете выбрать, чтобы объединить эти файлы в один, но для ясности в документации может быть проще рассмотреть их отдельно. Когда вы будете просматривать файлы конфигурации, вы увидите, что большая часть конфигурации одинакова для clickhouse-01 и clickhouse-02; различия будут выделены.
Конфигурация сети и логирования
Эти значения можно настраивать по своему усмотрению. Этот пример конфигурации дает вам:
- отладочный лог, который будет обновляться после 1000M три раза
- имя, отображаемое при подключении с помощью
clickhouse-client
, -cluster_1S_2R node 1
- ClickHouse будет слушать на сетевом интерфейсе IPV4 на портах 8123 и 9000.
Конфигурация макросов
Макросы shard
и replica
упрощают сложность распределенного DDL. Значения, настроенные для них, автоматически заменяются в ваших DDL-запросах, что упрощает ваш DDL. Макросы для этой конфигурации указывают номер шард и реплики для каждого узла.
В этом примере с 1 шард и 2 репликами, макрос реплики — replica_1
на clickhouse-01 и replica_2
на clickhouse-02. Макрос шард имеет значение 1
как для clickhouse-01, так и для clickhouse-02, поскольку существует только один шард.
Конфигурация репликации и шардирования
Начнем с верхней части:
- Раздел remote_servers в XML указывает на каждый из кластеров в среде. Атрибут
replace=true
заменяет пример удаленных серверов в конфигурации ClickHouse по умолчанию на конфигурацию remote_server, указанную в этом файле. Без этого атрибута удаленные серверы в этом файле добавлялись бы к списку примеров в конфигурации по умолчанию. - В этом примере есть один кластер с именем
cluster_1S_2R
. - Создается секрет для кластера с именем
cluster_1S_2R
со значениемmysecretphrase
. Секрет делится между всеми удаленными серверами в среде, чтобы гарантировать, что правильные серверы объединены. - В кластере
cluster_1S_2R
имеется один шард и две реплики. Обратите внимание на диаграмму архитектуры в начале этого документа и сравните ее с определениемshard
в приведенном ниже XML. Определение шард содержит две реплики. Хост и порт для каждой реплики указаны. Одна реплика хранится наclickhouse-01
, а другая — наclickhouse-02
. - Внутренняя репликация для шард установлена на true. Каждый шард может иметь параметр internal_replication, определенный в конфигурационном файле. Если этот параметр установлен на true, операция записи выбирает первую здоровую реплику и записывает данные в нее.
Конфигурация использования Keeper
Этот файл конфигурации use-keeper.xml
настраивает ClickHouse Server для использования ClickHouse Keeper для координации репликации и распределенного DDL. Этот файл указывает, что ClickHouse Server должен использовать Keeper на узлах clickhouse-keeper-01 - 03 на порту 9181, и файл одинаковый для clickhouse-01
и clickhouse-02
.
Конфигурация clickhouse-02
Поскольку конфигурация очень похожа на clickhouse-01 и clickhouse-02, здесь будут указаны только отличия.
Конфигурация сети и логирования
Этот файл одинаков на clickhouse-01 и clickhouse-02, за исключением display_name
.
Конфигурация макросов
Конфигурация макросов отличается между clickhouse-01 и clickhouse-02. replica
установлена в 02
на этом узле.
Конфигурация репликации и шардирования
Этот файл одинаков на clickhouse-01 и clickhouse-02.
Конфигурация использования Keeper
Этот файл одинаков на clickhouse-01 и clickhouse-02.
Конфигурация clickhouse-keeper-01
When configuring ClickHouse Keeper by editing configuration files you should:
- Backup the
/etc/clickhouse-keeper/keeper_config.xml
- Edit the
/etc/clickhouse-keeper/keeper_config.xml
file
ClickHouse Keeper предоставляет систему координации для репликации данных и выполнения распределенных DDL-запросов. ClickHouse Keeper совместим с Apache ZooKeeper. Эта конфигурация включает ClickHouse Keeper на порту 9181. Выделенная строка указывает, что этот экземпляр Keeper имеет server_id равным 1. Это единственное различие в файле enable-keeper.xml
на трех серверах. У clickhouse-keeper-02
будет server_id
, установленный в 2
, а у clickhouse-keeper-03
— в 3
. Раздел конфигурации raft одинаков для всех трех серверов, он выделен ниже, чтобы показать взаимосвязь между server_id
и экземпляром server
в конфигурации raft.
Если по какой-либо причине узел Keeper заменяется или восстанавливается, не используйте существующий server_id
. Например, если узел Keeper с server_id
равным 2
восстанавливается, дайте ему server_id
равный 4
или больше.
Конфигурация clickhouse-keeper-02
Между clickhouse-keeper-01
и clickhouse-keeper-02
есть только одно различие. server_id
установлен на 2
на этом узле.
Конфигурация clickhouse-keeper-03
Между clickhouse-keeper-01
и clickhouse-keeper-03
есть только одно различие. server_id
установлен на 3
на этом узле.
Тестирование
Чтобы получить опыт работы с ReplicatedMergeTree и ClickHouse Keeper, вы можете выполнить следующие команды, которые позволят вам:
- Создать базу данных на сконфигурированном кластере
- Создать таблицу в базе данных, используя движок таблиц ReplicatedMergeTree
- Вставить данные на одном узле и запросить их на другом узле
- Остановить один узел сервера ClickHouse
- Вставить еще данные на работающем узле
- Перезапустить остановленный узел
- Убедиться, что данные доступны при запросе на перезапущенном узле
Убедитесь, что ClickHouse Keeper работает
Команда mntr
используется для проверки, что ClickHouse Keeper работает, и для получения информации о состоянии взаимоотношений между тремя узлами Keeper. В конфигурации, используемой в этом примере, три узла работают вместе. Узлы выберут лидера, а остальные узлы станут последователями. Команда mntr
предоставляет информацию, связанную с производительностью, и о том, является ли конкретный узел последователем или лидером.
Вам может потребоваться установить netcat
, чтобы отправить команду mntr
в Keeper. Пожалуйста, смотрите страницу nmap.org для информации о загрузке.
Проверьте функциональность кластера ClickHouse
Подключитесь к узлу clickhouse-01
с помощью clickhouse client
в одной оболочке, и подключитесь к узлу clickhouse-02
с помощью clickhouse client
в другой оболочке.
- Создайте базу данных на сконфигурированном кластере
- Создайте таблицу в базе данных, используя движок таблиц ReplicatedMergeTree
- Вставьте данные на одном узле и запросите их на другом узле
- Запросите таблицу на узле
clickhouse-02
- Вставьте данные на другом узле и запросите их на узле
clickhouse-01
-
Остановите один узел сервера ClickHouse Остановите один из узлов сервера ClickHouse, выполнив команду операционной системы, аналогичную команде, использованной для запуска узла. Если вы использовали
systemctl start
для запуска узла, используйтеsystemctl stop
для его остановки. -
Вставьте еще данные на работающем узле
Выберите данные:
- Перезапустите остановленный узел и выберите данные также оттуда