ClickHouse Keeper (clickhouse-keeper)

Not supported in ClickHouse Cloud

примечание

Эта страница не применима к ClickHouse Cloud. Процедура, описанная здесь, автоматизирована в сервисах ClickHouse Cloud.

ClickHouse Keeper предоставляет систему координации для репликации данных и выполнения распределенных DDL запросов. ClickHouse Keeper совместим с ZooKeeper.

Подробности реализации

ZooKeeper является одной из первых известных открытых систем координации. Он реализован на Java и имеет достаточно простую и мощную модель данных. Алгоритм координации ZooKeeper, ZooKeeper Atomic Broadcast (ZAB), не предоставляет гарантии линейной согласованности для чтений, поскольку каждый узел ZooKeeper обслуживает чтения локально. В отличие от ZooKeeper, ClickHouse Keeper написан на C++ и использует алгоритм RAFT реализации. Этот алгоритм позволяет обеспечить линейную согласованность для чтений и записей и имеет несколько открытых реализаций на разных языках.

По умолчанию ClickHouse Keeper предоставляет те же гарантии, что и ZooKeeper: линейные записи и нелинейные чтения. У него совместимый клиент-серверный протокол, так что любой стандартный клиент ZooKeeper может использоваться для взаимодействия с ClickHouse Keeper. Снимки и журналы имеют несовместимый формат с ZooKeeper, но инструмент clickhouse-keeper-converter позволяет конвертировать данные ZooKeeper в снимки ClickHouse Keeper. Протокол межсерверного взаимодействия в ClickHouse Keeper также несовместим с ZooKeeper, поэтому смешанный кластер ZooKeeper / ClickHouse Keeper невозможен.

ClickHouse Keeper поддерживает списки управления доступом (ACL) так же, как это делает ZooKeeper. ClickHouse Keeper поддерживает тот же набор разрешений и имеет идентичные встроенные схемы: world, auth и digest. Схема аутентификации digest использует пару username:password, пароль кодируется в Base64.

примечание

Внешние интеграции не поддерживаются.

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

ClickHouse Keeper может использоваться как самостоятельная замена ZooKeeper или как внутренний компонент сервера ClickHouse. В обоих случаях конфигурация почти одинаковая .xml файл.

Настройки конфигурации Keeper

Основной тег конфигурации ClickHouse Keeper — <keeper_server> и имеет следующие параметры:

Параметр	Описание	Значение по умолчанию
tcp_port	Порт для подключения клиента.	2181
tcp_port_secure	Защищенный порт для SSL-соединения между клиентом и сервером keeper.	-
server_id	Уникальный идентификатор сервера, каждый участник кластера ClickHouse Keeper должен иметь уникальный номер (1, 2, 3 и так далее).	-
log_storage_path	Путь к журналам координации, как и в ZooKeeper, лучше всего хранить журналы на не занятых узлах.	-
snapshot_storage_path	Путь к снимкам координации.	-
enable_reconfiguration	Включить динамическую переконфигурацию кластера через reconfig.	False
max_memory_usage_soft_limit	Мягкий лимит в байтах на максимальное использование памяти keeper.	max_memory_usage_soft_limit_ratio * physical_memory_amount
max_memory_usage_soft_limit_ratio	Если max_memory_usage_soft_limit не установлен или установлен на ноль, мы используем это значение для определения стандартного мягкого лимита.	0.9
cgroups_memory_observer_wait_time	Если max_memory_usage_soft_limit не установлен или установлен на 0, мы используем этот интервал для наблюдения за количеством физической памяти. Как только количество памяти изменится, мы пересчитаем мягкий лимит памяти Keeper по max_memory_usage_soft_limit_ratio.	15
http_control	Настройки интерфейса HTTP управления.	-
digest_enabled	Включить проверку согласованности данных в реальном времени	True
create_snapshot_on_exit	Создать снимок во время завершения работы	-
hostname_checks_enabled	Включить проверки корректности имени хоста для конфигурации кластера (например, если localhost используется с удаленными конечными точками)	True
four_letter_word_white_list	Белый список команд 4lw.	conf, cons, crst, envi, ruok, srst, srvr, stat, wchs, dirs, mntr, isro, rcvr, apiv, csnp, lgif, rqld, ydld

Другие общие параметры унаследованы от конфигурации сервера ClickHouse (listen_host, logger и так далее).

Внутренние настройки координации

Внутренние настройки координации находятся в секции <keeper_server>.<coordination_settings> и имеют следующие параметры:

Параметр	Описание	Значение по умолчанию
operation_timeout_ms	Тайм-аут для одной клиентской операции (мс)	10000
min_session_timeout_ms	Минимальный тайм-аут для клиентской сессии (мс)	10000
session_timeout_ms	Максимальный тайм-аут для клиентской сессии (мс)	100000
dead_session_check_period_ms	Как часто ClickHouse Keeper проверяет на наличие мертвых сессий и удаляет их (мс)	500
heart_beat_interval_ms	Как часто лидер ClickHouse Keeper будет отправлять сигналы жизни последователям (мс)	500
election_timeout_lower_bound_ms	Если последователю не приходит сигнал жизни от лидера в этом интервале, он может инициировать выборы лидера. Должен быть меньше или равен election_timeout_upper_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 и так далее).	system default
auto_forwarding	Позволить пересылать записи запросов от последователей к лидеру.	true
shutdown_timeout	Ждать завершения внутренних подключений и завершения работы (мс).	5000
startup_timeout	Если сервер не подключается к другим участникам кворума в установленный тайм-аут, он завершается (мс).	30000
async_replication	Включить асинхронную репликацию. Все гарантия записи и чтения сохраняются, в то время как достигается лучшая производительность. Настройка отключена по умолчанию, чтобы не нарушить обратную совместимость	false
latest_logs_cache_size_threshold	Максимальный общий размер кеша последних записей журнала в памяти	1GiB
commit_logs_cache_size_threshold	Максимальный общий размер кеша записей журнала, необходимых для коммита	500MiB
disk_move_retries_wait_ms	Как долго ждать между попытками после сбоя, который произошел во время перемещения файла между дисками	1000
disk_move_retries_during_init	Количество попыток после сбоя, который произошел во время перемещения файла между дисками во время инициализации	100
experimental_use_rocksdb	Использовать rocksdb в качестве бекенда для хранения	0

Конфигурация кворума расположена в секции <keeper_server>.<raft_configuration> и содержит описание серверов.

Единственный параметр для всего кворума — secure, который включает зашифрованное соединение для общения между участниками кворума. Параметр может быть установлен в true, если для внутреннего общения между узлами требуется SSL-соединение, или оставлен неопределенным в противном случае.

Основные параметры для каждого <server>:

• id — Идентификатор сервера в кворуме.
• hostname — Имя хоста, где расположен этот сервер.
• port — Порт, на котором этот сервер слушает подключения.
• can_become_leader — Установите в false, чтобы настроить сервер как learner. Если пропущено, значение равно true.

примечание

В случае изменения топологии вашего кластера ClickHouse Keeper (например, замена сервера) убедитесь, что сопоставление server_id с hostname остается постоянным и избегайте перемешивания или повторного использования существующего server_id для различных серверов (например, это может произойти, если вы полагаетесь на автоматизированные скрипты для развертывания ClickHouse Keeper)

Если хост экземпляра Keeper может измениться, мы рекомендуем определить и использовать имя хоста вместо сырых IP-адресов. Изменение имени хоста эквивалентно удалению и повторному добавлению сервера, что в некоторых случаях может быть невозможно (например, недостаточно экземпляров Keeper для кворума).

примечание

async_replication отключен по умолчанию, чтобы избежать нарушения обратной совместимости. Если у вас все ваши экземпляры Keeper в кластере работают на версии, поддерживающей async_replication (v23.9+), мы рекомендуем включить его, так как это может улучшить производительность без каких-либо недостатков.

Примеры конфигурации для кворума с тремя узлами можно найти в интеграционных тестах с префиксом test_keeper_. Пример конфигурации для сервера #1:

Как запустить

ClickHouse Keeper входит в состав пакета сервера ClickHouse, просто добавьте конфигурацию <keeper_server> в ваш /etc/your_path_to_config/clickhouse-server/config.xml и запустите сервер ClickHouse, как всегда. Если вы хотите запустить ClickHouse Keeper отдельно, вы можете запустить его аналогичным образом:

Если у вас нет символической ссылки (clickhouse-keeper), вы можете создать ее или указать keeper в качестве аргумента для clickhouse:

Четырехбуквенные команды

ClickHouse Keeper также предоставляет команды 4lw, которые почти такие же, как в Zookeeper. Каждая команда состоит из четырех букв, таких как mntr, stat и т.д. Есть несколько более интересных команд: stat дает общую информацию о сервере и подключенных клиентах, в то время как srvr и cons предоставляют расширенные детали о сервере и соединениях соответственно.

Команды 4lw имеют конфигурацию белого списка four_letter_word_white_list, которая по умолчанию установлена на conf,cons,crst,envi,ruok,srst,srvr,stat,wchs,dirs,mntr,isro,rcvr,apiv,csnp,lgif,rqld,ydld.

Вы можете отправлять команды ClickHouse Keeper через telnet или nc по клиентскому порту.

Ниже представлена подробная информация о командах 4lw:

• ruok: Проверяет, работает ли сервер в состоянии без ошибок. Сервер ответит imok, если он работает. В противном случае он вообще не ответит. Ответ imok не обязательно указывает на то, что сервер присоединился к кворуму, только что процесс сервера активен и привязан к указанному клиентскому порту. Используйте "stat" для получения подробностей о состоянии относительно кворума и информации о подключении клиентов.

• mntr: Выводит список переменных, которые могут использоваться для мониторинга состояния кластера.

• srvr: Перечисляет полные детали для сервера.

• stat: Перечисляет краткие детали для сервера и подключенных клиентов.

• srst: Сбрасывает статистику сервера. Команда повлияет на результат srvr, mntr и stat.

• conf: Печатает детали о конфигурации обслуживания.

• cons: Перечисляет полные детали соединений/сессий для всех клиентов, подключенных к этому серверу. Включает информацию о количестве полученных/отправленных пакетов, идентификаторе сессии, задержках операций, последней выполненной операции и т.д.

• crst: Сбрасывает статистику соединений/сессий для всех подключений.

• envi: Печатает детали о среде обслуживания.

• dirs: Показывает общий размер снимков и файлов журналов в байтах.

• isro: Проверяет, работает ли сервер в режиме только для чтения. Сервер ответит ro, если он в режиме только для чтения, или rw, если он не в режиме только для чтения.

• wchs: Перечисляет краткую информацию о наблюдениях для сервера.

• wchc: Перечисляет детальную информацию о наблюдениях для сервера по сессиям. Это выводит список сессий (соединений) с связанными наблюдениями (путями). Обратите внимание, в зависимости от количества наблюдений эта операция может быть ресурсоемкой (влиять на производительность сервера), используйте ее с осторожностью.

• wchp: Перечисляет детальную информацию о наблюдениях для сервера по путям. Это выводит список путей (znodes) с ассоциированными сессиями. Обратите внимание, в зависимости от количества наблюдений эта операция может быть ресурсоемкой (например, влиять на производительность сервера), используйте ее с осторожностью.

• dump: Перечисляет текущие сессии и эфемерные узлы. Это работает только на лидере.

• csnp: Запланировать задачу создания снимка. Вернуть последний зафиксированный индекс лога запланированного снимка, если успешен, или Не удалось запланировать задачу создания снимка. , если неудачно. Обратите внимание, что команда lgif может помочь вам определить, завершен ли снимок.

• lgif: Информация о журнале Keeper. first_log_idx : мой первый индекс лога в хранилище логов; first_log_term : мой первый термин лога; last_log_idx : мой последний индекс лога в хранилище логов; last_log_term : мой последний термин лога; last_committed_log_idx : мой последний зафиксированный индекс лога в состоянии машины; leader_committed_log_idx : зафиксированный индекс лога лидера с моей точки зрения; target_committed_log_idx : целевой индекс лога, который должен быть зафиксирован; last_snapshot_idx : наибольший зафиксированный индекс лога в последнем снимке.

• rqld: Запрос на получение нового лидера. Возвращает Отправлен запрос на лидерство к лидеру. если запрос отправлен или Не удалось отправить запрос на лидерство к лидеру. если запрос не отправлен. Обратите внимание, если узел уже лидер, результат будет тем же, так как запрос отправляется.

• ftfl: Перечисляет все флаги функций и информацию о том, включены ли они для экземпляра Keeper.

• ydld: Запрос на передачу лидерства и становление подписчиком. Если сервер, получающий запрос, является лидером, он сначала приостановит операции записи, дождется, пока преемник (текущий лидер никогда не может быть преемником) завершит синхронизацию с последним логом, а затем уйдет. Преемник будет выбран автоматически. Возвращает Отправлен запрос на передачу лидерства к лидеру. если запрос отправлен или Не удалось отправить запрос на передачу лидерства к лидеру. если запрос не отправлен. Обратите внимание, если узел уже подписчик, результат будет тем же, так как запрос отправляется.

• pfev: Возвращает значения для всех собранных событий. Для каждого события он возвращает название события, значение события и описание события.

HTTP управление

ClickHouse Keeper предоставляет HTTP интерфейс для проверки готовности реплики к получению трафика. Он может использоваться в облачных средах, таких как Kubernetes.

Пример конфигурации, которая включает конечную точку /ready:

Флаги функций

Keeper полностью совместим с ZooKeeper и его клиентами, но также вводит некоторые уникальные функции и типы запросов, которые могут использоваться клиентом ClickHouse. Поскольку эти функции могут ввести несовместимое изменение, большинство из них отключены по умолчанию и могут быть включены с помощью конфигурации keeper_server.feature_flags. Все функции могут быть отключены явно. Если вы хотите включить новую функцию для вашего кластера Keeper, мы рекомендуем сначала обновить все экземпляры Keeper в кластере до версии, которая поддерживает эту функцию, а затем включить саму функцию.

Пример конфигурации флагов функции, которая отключает multi_read и включает check_not_exists:

Доступные функции:

multi_read - поддержка многочитательных запросов. По умолчанию: 1
filtered_list - поддержка запросов списка, которые фильтруют результаты по типу узла (эфемерный или постоянный). По умолчанию: 1
check_not_exists - поддержка запроса CheckNotExists, который утверждает, что узел не существует. По умолчанию: 0
create_if_not_exists - поддержка запросов CreateIfNotExists, которые попытаются создать узел, если он не существует. Если он существует, никакие изменения не применяются, и возвращается ZOK. По умолчанию: 0

Миграция из ZooKeeper

Бесшовная миграция из ZooKeeper в ClickHouse Keeper невозможна. Вам нужно остановить свой кластер ZooKeeper, конвертировать данные и запустить ClickHouse Keeper. Инструмент clickhouse-keeper-converter позволяет конвертировать журналы и снимки ZooKeeper в снимок ClickHouse Keeper. Он работает только с ZooKeeper > 3.4. Шаги для миграции:

1. Остановите все узлы ZooKeeper.

2. Необязательно, но рекомендуется: найдите узел-лидер ZooKeeper, запустите и остановите его снова. Это заставит ZooKeeper создать согласованный снимок.

3. Запустите clickhouse-keeper-converter на лидере, например:

4. Скопируйте снимок на узлы сервера ClickHouse с настроенным keeper или запустите ClickHouse Keeper вместо ZooKeeper. Снимок должен существовать на всех узлах, в противном случае пустые узлы могут работать быстрее, и один из них может стать лидером.

примечание

Инструмент keeper-converter недоступен из самостоятельного двоичного файла Keeper. Если у вас установлен ClickHouse, вы можете использовать двоичный файл напрямую:

В противном случае вы можете скачать двоичный файл и запустить инструмент, как описано выше, без установки ClickHouse.

Восстановление после потери кворума

Поскольку ClickHouse Keeper использует Raft, он может переносить определенное количество сбоев узлов в зависимости от размера кластера. Например, в кластере из 3 узлов он продолжит работать правильно, если только 1 узел выйдет из строя.

Конфигурация кластера может быть настроена динамически, но есть некоторые ограничения. Перенастройка также зависит от Raft, поэтому чтобы добавить/удалить узел из кластера, вам нужно иметь кворум. Если вы потеряете слишком много узлов в вашем кластере одновременно без возможности их повторного запуска, Raft перестанет работать и не позволит вам перенастроить кластер привычным способом.

Тем не менее, ClickHouse Keeper имеет режим восстановления, который позволяет вам принудительно перенастроить кластер с использованием только 1 узла. Это следует делать только в крайних случаях, если вы не можете снова запустить свои узлы или запустить новый экземпляр на той же конечной точке.

Важно отметить перед продолжением:

• Убедитесь, что неудавшиеся узлы не смогут снова подключиться к кластеру.
• Не запускайте никакие новые узлы, пока это не указано в шагах.

После того как вы убедились, что вышеописанные условия истинны, вам нужно сделать следующее:

1. Выберите один узел Keeper, который станет вашим новым лидером. Имейте в виду, что данные этого узла будут использоваться для всего кластера, поэтому мы рекомендуем использовать узел с наиболее актуальным состоянием.
2. Прежде чем делать что-либо другое, сделайте резервную копию папок log_storage_path и snapshot_storage_path выбранного узла.
3. Перенастройте кластер на всех узлах, которые вы хотите использовать.
4. Отправьте четырехбуквенную команду rcvr выбранному узлу, чтобы перевести его в режим восстановления ИЛИ остановите экземпляр Keeper на выбранном узле и запустите его снова с аргументом --force-recovery.
5. Один за другим, запускайте экземпляры Keeper на новых узлах, убедившись, что mntr возвращает follower для zk_server_state перед запуском следующего.
6. Находясь в режиме восстановления, узел-лидер будет возвращать сообщение об ошибке для команды mntr, пока не завоюет кворум с новыми узлами и откажется от любых запросов от клиентов и подписчиков.
7. После достижения кворума узел-лидер вернется к нормальному режиму работы, принимая все запросы с использованием Raft-верификации, и mntr должен вернуть leader для zk_server_state.

Использование дисков с Keeper

Keeper поддерживает подмножество внешних дисков для хранения снимков, файлов журналов и файла состояния.

Поддерживаемые типы дисков:

• s3_plain
• s3
• local

Ниже представлен пример определений дисков, содержащихся в конфигурации.

Чтобы использовать диск для журналов, параметр конфигурации keeper_server.log_storage_disk должен быть установлен на имя диска. Чтобы использовать диск для снимков, параметр конфигурации keeper_server.snapshot_storage_disk должен быть установлен на имя диска. Кроме того, различные диски могут быть использованы для последних журналов или снимков с помощью keeper_server.latest_log_storage_disk и keeper_server.latest_snapshot_storage_disk соответственно. В этом случае Keeper автоматически переместит файлы на правильные диски, когда будут созданы новые журналы или снимки. Чтобы использовать диск для файла состояния, параметр конфигурации keeper_server.state_storage_disk должен быть установлен на имя диска.

Перемещение файлов между дисками безопасно, и нет риска потери данных, если Keeper остановится в середине передачи. Пока файл полностью не перемещен на новый диск, он не удаляется со старого.

Keeper с установленными параметрами keeper_server.coordination_settings.force_sync в значение true (по умолчанию true) не может удовлетворить некоторые гарантии для всех типов дисков. В настоящее время только диски типа local поддерживают постоянную синхронизацию. Если используется force_sync, log_storage_disk должен быть локальным диском, если latest_log_storage_disk не используется. Если используется latest_log_storage_disk, он всегда должен быть локальным диском. Если force_sync отключен, диски всех типов могут использоваться в любой настройке.

Возможная настройка хранения для экземпляра Keeper может выглядеть следующим образом:

Этот экземпляр будет хранить все, кроме последних журналов на диске log_s3_plain, в то время как последний журнал будет храниться на диске log_local. Тот же принцип применим к снимкам, все, кроме последних снимков, будут храниться на snapshot_s3_plain, в то время как последний снимок будет храниться на snapshot_local.

Изменение настройки диска

к сведению

Перед применением новой настройки диска вручную создайте резервную копию всех журналов и снимков Keeper.

Если определена многослойная настройка диска (с использованием отдельных дисков для последних файлов), Keeper попробует автоматически переместить файлы на правильные диски при запуске. То же самое гарантия применяется, как и прежде; пока файл полностью не перемещен на новый диск, он не удаляется со старого, поэтому несколько перезапусков можно безопасно выполнять.

Если необходимо переместить файлы на совершенно новый диск (или переместить из 2-дисковой настройки на однодисковую настройку), можно использовать несколько определений keeper_server.old_snapshot_storage_disk и keeper_server.old_log_storage_disk.

Следующий пример конфигурации показывает, как мы можем переместиться из предыдущей 2-дисковой настройки в совершенно новую однодисковую настройку:

При запуске все файлы журналов будут перемещены с log_local и log_s3_plain на диск log_local2. Также все файлы снимков будут перемещены с snapshot_local и snapshot_s3_plain на диск snapshot_local2.

Настройка кэширования журналов

Чтобы минимизировать количество данных, считываемых с диска, Keeper кэширует записи журнала в памяти. Если запросы большие, записи журнала займут слишком много памяти, поэтому количество кэшированных журналов ограничено. Лимит контролируется двумя этими параметрами:

• latest_logs_cache_size_threshold - общий размер последних журналов, хранящихся в кэше
• commit_logs_cache_size_threshold - общий размер последующих журналов, которые необходимо зафиксировать

Если значения по умолчанию слишком велики, вы можете уменьшить использование памяти, уменьшив эти два параметра.

примечание

Вы можете использовать команду pfev, чтобы проверить количество журналов, считанных из каждого кэша и из файла. Вы также можете использовать метрики с конечной точки Prometheus, чтобы отслеживать текущий размер обоих кэшей.

Prometheus

Keeper может предоставлять данные метрик для сбора помещений из Prometheus.

Настройки:

• endpoint – HTTP конечная точка для сбора метрик сервером Prometheus. Начинается с '/'.
• port – порт для endpoint.
• metrics – флаг, который устанавливает для экспонирования метрик из таблицы system.metrics.
• events – флаг, который устанавливает для экспонирования метрик из таблицы system.events.
• asynchronous_metrics – флаг, который устанавливает для экспонирования текущих значений метрик из таблицы system.asynchronous_metrics.

Пример

Проверка (замените 127.0.0.1 на IP-адрес или имя хоста вашего сервера ClickHouse):

Пожалуйста, также смотрите интеграцию ClickHouse Cloud Prometheus.

Руководство пользователя ClickHouse Keeper

Это руководство предоставляет простые и минимальные настройки для конфигурации ClickHouse Keeper с примером тестирования распределенных операций. Этот пример выполняется с использованием 3 узлов на Linux.

1. Настройка узлов с настройками Keeper

1. Установите 3 экземпляра ClickHouse на 3 хоста (chnode1, chnode2, chnode3). (Смотрите Быстрый старт для подробной информации по установке ClickHouse.)

2. На каждом узле добавьте следующую запись для разрешения внешней связи через сетевой интерфейс.

3. Добавьте следующую конфигурацию ClickHouse Keeper на все три сервера, обновив настройку <server_id> для каждого сервера; для chnode1 будет 1, для chnode2 будет 2 и т.д.

   Это основные настройки, используемые выше:

   Параметр	Описание	Пример
   tcp_port	порт, используемый клиентами Keeper	9181 по умолчанию эквивалент 2181, как в Zookeeper
   server_id	идентификатор для каждого сервера ClickHouse Keeper, используемый в конфигурации Raft	1
   coordination_settings	секция для параметров, таких как таймы	таймауты: 10000, уровень журнала: trace
   server	определение сервера, участвующего	список каждой определения сервера
   raft_configuration	настройки для каждого сервера в кластере Keeper	сервер и настройки для каждого
   id	числовой ID сервера для служб Keeper	1
   hostname	имя хоста, IP или FQDN каждого сервера в кластере Keeper	chnode1.domain.com
   port	порт для прослушивания для внутреннего соединения Keeper	9234

4. Включите компонент Zookeeper. Он будет использовать движок ClickHouse Keeper:

   Это основные настройки, используемые выше:

   Параметр	Описание	Пример
   node	список узлов для соединений ClickHouse Keeper	настройка записи для каждого сервера
   host	имя хоста, IP или FQDN каждого узла ClickHouse Keeper	chnode1.domain.com
   port	порт клиента ClickHouse Keeper	9181

5. Перезапустите ClickHouse и убедитесь, что каждый экземпляр Keeper работает. Выполните следующую команду на каждом сервере. Команда ruok возвращает imok, если Keeper работает и здоров:

6. База данных system имеет таблицу с именем zookeeper, которая содержит детали ваших экземпляров ClickHouse Keeper. Давайте просмотрим таблицу:

   Таблица выглядит так:

2. Настройка кластера в ClickHouse

1. Давайте настроим простой кластер с 2 шардми и только одним репликой на 2 из узлов. Третий узел будет использоваться для достижения кворума для требований в ClickHouse Keeper. Обновите конфигурацию на chnode1 и chnode2. Следующий кластер определяет 1 шард на каждом узле, всего 2 shards без репликации. В этом примере некоторые данные будут на одном узле, а некоторые на другом узле:

   Параметр	Описание	Пример
   shard	список реплик в определении кластера	список реплик для каждого шард
   replica	список настроек для каждой реплики	записи настроек для каждой реплики
   host	имя хоста, IP или FQDN сервера, который будет хостить реплику шард	chnode1.domain.com
   port	порт, используемый для связи с использованием нативного tcp протокола	9000
   user	имя пользователя, которое будет использоваться для аутентификации к экземплярам кластера	default
   password	пароль для пользователя, определенного для разрешения подключений к экземплярам кластера	ClickHouse123!

2. Перезапустите ClickHouse и проверьте, что кластер был создан:

   Вы должны увидеть ваш кластер:

3. Создание и тестирование распределенной таблицы

1. Создайте новую базу данных в новом кластере с использованием клиента ClickHouse на chnode1. Условие ON CLUSTER автоматически создает базу данных на обоих узлах.

2. Создайте новую таблицу в базе данных db1. Вновь, ON CLUSTER создает таблицу на обоих узлах.

3. На узле chnode1 добавьте несколько строк:

4. Добавьте несколько строк на узле chnode2:

5. Обратите внимание, что выполнение команды SELECT на каждом узле показывает только данные на этом узле. Например, на chnode1:

   На chnode2:

7. Вы можете создать распределенную таблицу, чтобы представить данные на двух шард. Таблицы с движком Distributed не хранят собственные данные, но позволяют распределенную обработку запросов на нескольких серверах. Чтения попадают во все шард, а записи могут распределяться по шардом. Выполните следующий запрос на chnode1:

8. Обратите внимание, что запрос к dist_table возвращает все четыре строки данных из двух шард:

Резюме

В этом руководстве показано, как настроить кластер с использованием ClickHouse Keeper. С помощью ClickHouse Keeper вы можете настраивать кластеры и определять распределенные таблицы, которые можно реплицировать между шардом.

Настройка ClickHouse Keeper с уникальными путями

Not supported in ClickHouse Cloud

примечание

Эта страница не применима к ClickHouse Cloud. Процедура, описанная здесь, автоматизирована в сервисах ClickHouse Cloud.

Описание

В этой статье описывается, как использовать встроенные настройки макроса {uuid} для создания уникальных записей в ClickHouse Keeper или ZooKeeper. Уникальные пути помогают при частом создании и удалении таблиц, поскольку это избегает ожидания нескольких минут для сборки мусора Keeper для удаления элементов пути; каждый раз при создании пути используется новый uuid, и пути никогда не повторяются.

Пример окружения

Трехузловой кластер, который будет настроен для работы с ClickHouse Keeper на всех трех узлах и ClickHouse на двух из узлов. Это обеспечивает ClickHouse Keeper тремя узлами (включая узел для разрешения споров) и одним шардом ClickHouse, состоящим из двух реплик.

узел	описание
chnode1.marsnet.local	узел данных - кластер cluster_1S_2R
chnode2.marsnet.local	узел данных - кластер cluster_1S_2R
chnode3.marsnet.local	узел-делитель ClickHouse Keeper

Пример конфигурации для кластера:

Процедуры по настройке таблиц для использования {uuid}

1. Настройте макросы на каждом сервере пример для сервера 1:

примечание

Обратите внимание, что мы определяем макросы для shard и replica, но {uuid} здесь не определен, он встроен и нет необходимости в определении.

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

3. Создайте таблицу в кластере с использованием макросов и {uuid}

4. Создайте распределенную таблицу

Тестирование

1. Вставьте данные в первый узел (например, chnode1)

2. Вставьте данные во второй узел (например, chnode2)

3. Просмотрите записи с помощью распределенной таблицы

Альтернативы

Путь репликации по умолчанию можно определить заранее с помощью макросов и также используя {uuid}

1. Установите значение по умолчанию для таблиц на каждом узле

подсказка

Вы также можете определить макрос {database} на каждом узле, если узлы используются для определенных баз данных.

2. Создайте таблицу без явных параметров:

3. Убедитесь, что были использованы настройки, использованные в конфигурации по умолчанию

Устранение неполадок

Пример команды для получения информации о таблице и UUID:

Пример команды для получения информации о таблице в zookeeper с UUID для таблицы выше

примечание

База данных должна быть Atomic, если обновление с предыдущей версии, то база данных default вероятно будет типа Ordinary.

Чтобы проверить:

Например,

Динамическая перенаcтройка ClickHouse Keeper

Not supported in ClickHouse Cloud

примечание

Эта страница не применима к ClickHouse Cloud. Процедура, описанная здесь, автоматизирована в сервисах ClickHouse Cloud.

Описание

ClickHouse Keeper частично поддерживает команду ZooKeeper reconfig для динамической перенастройки кластера, если включен параметр keeper_server.enable_reconfiguration.

примечание

Если эта настройка отключена, вы можете перенастроить кластер, изменив раздел raft_configuration реплики вручную. Убедитесь, что вы редактируете файлы на всех репликах, поскольку только лидер будет применять изменения. Кроме того, вы можете отправить запрос reconfig через любой клиент, совместимый с ZooKeeper.

Виртуальный узел /keeper/config содержит последнюю утвержденную конфигурацию кластера в следующем формате:

• Каждая запись сервера отделяется переводом строки.
• server_type — это либо participant, либо learner (learner не участвует в выборах лидера).
• server_priority — это неотрицательное целое число, указывающее какие узлы должны быть приоритетными при выборах лидера. Приоритет 0 означает, что сервер никогда не будет лидером.

Пример:

Вы можете использовать команду reconfig, чтобы добавить новые серверы, удалить существующие и изменить приоритеты существующих серверов. Вот примеры (с использованием clickhouse-keeper-client):

А вот примеры для kazoo:

Сервера в joining должны быть в формате сервера, описанном выше. Записи сервера должны отделяться запятыми. При добавлении новых серверов можно опустить server_priority (значение по умолчанию - 1) и server_type (значение по умолчанию - participant).

Если вы хотите изменить приоритет существующего сервера, добавьте его в joining с целевым приоритетом. Хост, порт и тип сервера должны соответствовать конфигурации существующего сервера.

Сервера добавляются и удаляются в порядке их появления в joining и leaving. Все обновления из joining обрабатываются перед обновлениями из leaving.

Существуют некоторые нюансы в реализации перенастройки Keeper:

• Поддерживается только инкрементальная перенастройка. Запросы с непустым new_members отклоняются.

  Реализация ClickHouse Keeper основана на API NuRaft для динамической смены состава. NuRaft имеет способ добавить один сервер или удалить один сервер, один за другим. Это означает, что каждое изменение конфигурации (каждая часть joining, каждая часть leaving) должно быть решено отдельно. Таким образом, массовая перенастройка недоступна, поскольку это будет вводить пользователей в заблуждение.

  Изменение типа сервера (участник/ученик) также невозможно, так как это не поддерживается NuRaft, и единственным способом было бы удалить и добавить сервер, что снова будет вводить в заблуждение.

• Вы не можете использовать возвращенное значение znodestat.

• Поле from_version не используется. Все запросы с установленным from_version отклоняются. Это связано с тем, что /keeper/config - это виртуальный узел, что означает, что он не хранится в постоянном хранилище, а вместо этого генерируется на лету с указанной конфигурацией узла для каждого запроса. Это решение было принято, чтобы не дублировать данные, так как NuRaft уже хранит эту конфигурацию.

• В отличие от ZooKeeper, нет способа ждать перенастройки кластера, отправляя команду sync. Новая конфигурация будет в конечном итоге применена, но без временных гарантий.

• Команда reconfig может завершиться неудачей по различным причинам. Вы можете проверить состояние кластера и увидеть, была ли применена обновление.

Преобразование одноузлового keeper в кластер

Иногда необходимо расширить экспериментальный узел keeper в кластер. Вот схема того, как это сделать шаг за шагом для кластера из 3 узлов:

• ВАЖНО: новые узлы должны добавляться партиями меньше, чем текущий кворум, иначе они выберут лидера среди них. В этом примере по одному.
• Существующий узел keeper должен иметь включенный параметр конфигурации keeper_server.enable_reconfiguration.
• Запустите второй узел с полной новой конфигурацией кластера keeper.
• После его запуска добавьте его к узлу 1 с помощью reconfig.
• Теперь запустите третий узел и добавьте его с помощью reconfig.
• Обновите конфигурацию clickhouse-server, добавив новый узел keeper, и перезапустите его, чтобы применить изменения.
• Обновите конфигурацию raft узла 1 и, по желанию, перезапустите его.

Чтобы уверенно понять процесс, вот песочница репозиторий.

Неподдерживаемые функции

Хотя ClickHouse Keeper стремится быть полностью совместимым с ZooKeeper, есть некоторые функции, которые в настоящее время не реализованы (хотя разработка продолжается):

• create не поддерживает возврат объекта Stat
• create не поддерживает TTL
• addWatch не работает с PERSISTENT наблюдениями
• removeWatch и removeAllWatches не поддерживаются
• setWatches не поддерживается
• Создание znodes типа CONTAINER не поддерживается
• SASL аутентификация](https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zookeeper+and+SASL) не поддерживается