13 KiB
toc_priority | toc_title |
---|---|
66 | ClickHouse Keeper |
[пре-продакшн] ClickHouse Keeper
Сервер ClickHouse использует сервис координации ZooKeeper для репликации данных и выполнения распределенных DDL запросов. ClickHouse Keeper — это альтернативный сервис координации, совместимый с ZooKeeper.
!!! warning "Предупреждение" ClickHouse Keeper находится в стадии пре-продакшн и тестируется в CI ClickHouse и на нескольких внутренних инсталляциях.
Детали реализации
ZooKeeper — один из первых широко известных сервисов координации с открытым исходным кодом. Он реализован на языке программирования Java, имеет достаточно простую и мощную модель данных. Алгоритм координации Zookeeper называется ZAB (ZooKeeper Atomic Broadcast). Он не гарантирует линеаризуемость операций чтения, поскольку каждый узел ZooKeeper обслуживает чтения локально. В отличие от ZooKeeper, ClickHouse Keeper реализован на C++ и использует алгоритм RAFT, реализация. Этот алгоритм позволяет достичь линеаризуемости чтения и записи, имеет несколько реализаций с открытым исходным кодом на разных языках.
По умолчанию ClickHouse Keeper предоставляет те же гарантии, что и ZooKeeper (линеаризуемость записей, последовательная согласованность чтений). У него есть совместимый клиент-серверный протокол, поэтому любой стандартный клиент ZooKeeper может использоваться для взаимодействия с ClickHouse Keeper. Снэпшоты и журналы имеют несовместимый с ZooKeeper формат, однако можно конвертировать данные Zookeeper в снэпшот ClickHouse Keeper с помощью clickhouse-keeper-converter
. Межсерверный протокол ClickHouse Keeper также несовместим с ZooKeeper, поэтому создание смешанного кластера ZooKeeper / ClickHouse Keeper невозможно.
Конфигурация
ClickHouse Keeper может использоваться как равноценная замена ZooKeeper или как внутренняя часть сервера ClickHouse, но в обоих случаях конфигурация представлена файлом .xml
. Главный тег конфигурации ClickHouse Keeper — это <keeper_server>
. Параметры конфигурации:
tcp_port
— порт для подключения клиента (по умолчанию для ZooKeeper:2181
).tcp_port_secure
— зашифрованный порт для подключения клиента.server_id
— уникальный идентификатор сервера, каждый участник кластера должен иметь уникальный номер (1, 2, 3 и т. д.).log_storage_path
— путь к журналам координации, лучше хранить их на незанятом устройстве (актуально и для ZooKeeper).snapshot_storage_path
— путь к снэпшотам координации.
Другие общие параметры наследуются из конфигурации сервера ClickHouse (listen_host
, logger
, и т. д.).
Настройки внутренней координации находятся в <keeper_server>.<coordination_settings>
:
operation_timeout_ms
— максимальное время ожидания для одной клиентской операции в миллисекундах (по умолчанию: 10000).session_timeout_ms
— максимальное время ожидания для клиентской сессии в миллисекундах (по умолчанию: 30000).dead_session_check_period_ms
— частота, с которой ClickHouse Keeper проверяет мертвые сессии и удаляет их, в миллисекундах (по умолчанию: 500).heart_beat_interval_ms
— частота, с которой узел-лидер ClickHouse Keeper отправляет хартбиты узлам-последователям, в миллисекундах (по умолчанию: 500).election_timeout_lower_bound_ms
— время, после которого последователь может инициировать выборы лидера, если не получил от него сердцебиения (по умолчанию: 1000).election_timeout_upper_bound_ms
— время, после которого последователь должен инициировать выборы лидера, если не получил от него сердцебиения (по умолчанию: 2000).rotate_log_storage_interval
— количество записей в журнале координации для хранения в одном файле (по умолчанию: 100000).reserved_log_items
— минимальное количество записей в журнале координации которые нужно сохранять после снятия снепшота (по умолчанию: 100000).snapshot_distance
— частота, с которой ClickHouse Keeper делает новые снэпшоты (по количеству записей в журналах), в миллисекундах (по умолчанию: 100000).snapshots_to_keep
— количество снэпшотов для сохранения (по умолчанию: 3).stale_log_gap
— время, после которого лидер считает последователя устаревшим и отправляет ему снэпшот вместо журналов (по умолчанию: 10000).fresh_log_gap
— максимальное отставание от лидера в количестве записей журнала после которого последователь считает себя не отстающим (по умолчанию: 200).max_requests_batch_size
— количество запросов на запись, которые будут сгруппированы в один перед отправкой через RAFT (по умолчанию: 100).force_sync
— вызыватьfsync
при каждой записи в журнал координации (по умолчанию: true).quorum_reads
— выполнять запросы чтения аналогично запросам записи через весь консенсус RAFT с негативным эффектом на производительность и размер журналов (по умолчанию: false).raft_logs_level
— уровень логгирования сообщений в текстовый лог (trace, debug и т. д.) (по умолчанию: information).auto_forwarding
— разрешить пересылку запросов на запись от последователей лидеру (по умолчанию: true).shutdown_timeout
— время ожидания завершения внутренних подключений и выключения, в миллисекундах (по умолчанию: 5000).startup_timeout
— время отключения сервера, если он не подключается к другим участникам кворума, в миллисекундах (по умолчанию: 30000).
Конфигурация кворума находится в <keeper_server>.<raft_configuration>
и содержит описание серверов. Единственный параметр для всего кворума — secure
, который включает зашифрованное соединение для связи между участниками кворума. Параметры для каждого <server>
:
id
— идентификатор сервера в кворуме.hostname
— имя хоста, на котором размещен сервер.port
— порт, на котором серверу доступны соединения для внутренней коммуникации.
Примеры конфигурации кворума с тремя узлами можно найти в интеграционных тестах с префиксом test_keeper_
. Пример конфигурации для сервера №1:
<keeper_server>
<tcp_port>2181</tcp_port>
<server_id>1</server_id>
<log_storage_path>/var/lib/clickhouse/coordination/log</log_storage_path>
<snapshot_storage_path>/var/lib/clickhouse/coordination/snapshots</snapshot_storage_path>
<coordination_settings>
<operation_timeout_ms>10000</operation_timeout_ms>
<session_timeout_ms>30000</session_timeout_ms>
<raft_logs_level>trace</raft_logs_level>
</coordination_settings>
<raft_configuration>
<server>
<id>1</id>
<hostname>zoo1</hostname>
<port>9444</port>
</server>
<server>
<id>2</id>
<hostname>zoo2</hostname>
<port>9444</port>
</server>
<server>
<id>3</id>
<hostname>zoo3</hostname>
<port>9444</port>
</server>
</raft_configuration>
</keeper_server>
Как запустить
ClickHouse Keeper входит в пакет clickhouse-server
, просто добавьте кофигурацию <keeper_server>
и запустите сервер ClickHouse как обычно. Если вы хотите запустить ClickHouse Keeper автономно, сделайте это аналогичным способом:
clickhouse-keeper --config /etc/your_path_to_config/config.xml --daemon
[экспериментально] Переход с ZooKeeper
Плавный переход с ZooKeeper на ClickHouse Keeper невозможен, необходимо остановить кластер ZooKeeper, преобразовать данные и запустить ClickHouse Keeper. Утилита clickhouse-keeper-converter
конвертирует журналы и снэпшоты ZooKeeper в снэпшот ClickHouse Keeper. Работа утилиты проверена только для версий ZooKeeper выше 3.4. Для миграции необходимо выполнить следующие шаги:
-
Остановите все узлы ZooKeeper.
-
Необязательно, но рекомендуется: найдите узел-лидер ZooKeeper, запустите и снова остановите его. Это заставит ZooKeeper создать консистентный снэпшот.
-
Запустите
clickhouse-keeper-converter
на лидере, например:
clickhouse-keeper-converter --zookeeper-logs-dir /var/lib/zookeeper/version-2 --zookeeper-snapshots-dir /var/lib/zookeeper/version-2 --output-dir /path/to/clickhouse/keeper/snapshots
- Скопируйте снэпшот на узлы сервера ClickHouse с настроенным
keeper
или запустите ClickHouse Keeper вместо ZooKeeper. Снэпшот должен сохраняться на всех узлах: в противном случае пустые узлы могут захватить лидерство и сконвертированные данные могут быть отброшены на старте.