Skip to main content
Эта страница не применима к ClickHouse Cloud. Описанная здесь процедура в сервисах ClickHouse Cloud выполняется автоматически.
ClickHouse Keeper обеспечивает систему координации для репликации данных и выполнения запросов distributed DDL. ClickHouse Keeper совместим с ZooKeeper.

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

ZooKeeper — одна из первых широко известных систем координации с открытым исходным кодом. Она реализована на Java и использует простую, но мощную модель данных. Алгоритм координации ZooKeeper, ZooKeeper Atomic Broadcast (ZAB), не дает гарантий линеаризуемости для операций чтения, поскольку каждый узел ZooKeeper обрабатывает чтение локально. В отличие от ZooKeeper, ClickHouse Keeper написан на C++ и использует реализацию алгоритма RAFT. Этот алгоритм обеспечивает линеаризуемость операций чтения и записи и имеет несколько реализаций с открытым исходным кодом на разных языках. По умолчанию ClickHouse Keeper предоставляет те же гарантии, что и ZooKeeper: линеаризуемые записи и нелинеаризуемые чтения. Он использует совместимый клиент-серверный протокол, поэтому для работы с ClickHouse Keeper можно использовать любой стандартный клиент ZooKeeper. Снимки и журналы имеют формат, несовместимый с 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>. Он имеет следующие параметры: Другие распространенные параметры наследуются из конфигурации ClickHouse server (listen_host, logger и так далее).

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

Внутренние настройки координации находятся в разделе <keeper_server>.<coordination_settings> и включают следующие параметры: Конфигурация кворума находится в разделе <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+), рекомендуем включить этот параметр, так как он может повысить производительность без каких-либо недостатков.
Примеры конфигурации кворума из трёх узлов можно найти в integration tests с префиксом test_keeper_. Пример конфигурации для сервера №1:

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

ClickHouse Keeper входит в пакет ClickHouse server: просто добавьте конфигурацию <keeper_server> в /etc/your_path_to_config/clickhouse-server/config.xml и запустите ClickHouse server как обычно. Если вы хотите запустить автономный 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: Выводит подробную информацию о наблюдениях на сервере по путям. В результате выводится список путей (znode) со связанными сеансами. Обратите внимание: в зависимости от количества наблюдений эта операция может быть ресурсоёмкой (то есть влиять на производительность сервера), поэтому используйте её с осторожностью.
  • dump: Выводит активные сеансы и эфемерные узлы. Команда работает только на лидере.
  • csnp: Планирует задачу создания снимка. В случае успеха возвращает последний зафиксированный индекс журнала для запланированного снимка, а в случае ошибки — Failed to schedule snapshot creation task.. Команда 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: Запрос на назначение новым лидером. Возвращает Sent leadership request to leader., если запрос отправлен, или Failed to send leadership request to leader., если запрос не отправлен. Если узел уже является лидером, результат будет таким же, как при отправке запроса.
  • ftfl: Выводит список всех флагов возможностей и показывает, включены ли они для экземпляра Keeper.
  • ydld: Запрос на отказ от роли лидера и переход в состояние follower. Если сервер, получивший запрос, является лидером, он сначала приостановит операции записи, дождётся, пока преемник (текущий лидер никогда не может быть преемником) завершит догонку до последней записи журнала, а затем сложит полномочия. Преемник будет выбран автоматически. Возвращает Sent yield leadership request to leader. если запрос отправлен, или Failed to send yield leadership request to leader. если отправить запрос не удалось. Если узел уже является follower, результат будет таким же, как и при отправке запроса.
  • pfev: Возвращает значения для всех собранных событий. Для каждого события возвращает его имя, значение и описание.

Управление по HTTP

ClickHouse Keeper предоставляет HTTP-интерфейс для проверки, готова ли реплика принимать трафик. Его можно использовать в облачных средах, таких как Kubernetes. Пример конфигурации, включающей конечную точку /ready:

Флаги возможностей

Keeper полностью совместим с ZooKeeper и его клиентами, но также поддерживает некоторые уникальные возможности и типы запросов, которые могут использоваться клиентом ClickHouse. Поскольку эти возможности могут приводить к обратно несовместимым изменениям, большинство из них по умолчанию отключены и могут быть включены с помощью конфигурации keeper_server.feature_flags. Все возможности можно явно отключить. Если вы хотите включить новую возможность в своем кластере Keeper, мы рекомендуем сначала обновить все узлы Keeper в кластере до версии, которая поддерживает эту возможность, а затем включить саму возможность. Пример конфигурации флагов возможностей, которая отключает multi_read и включает check_not_exists:
Доступны следующие возможности:
Некоторые флаги возможностей включены по умолчанию начиная с версии 25.7. Рекомендуемый способ обновить Keeper до 25.7+ — сначала обновиться до версии 24.9+.

Миграция с ZooKeeper

Плавная миграция с ZooKeeper на ClickHouse Keeper невозможна. Необходимо остановить кластер ZooKeeper, преобразовать данные и запустить ClickHouse Keeper. Инструмент clickhouse-keeper-converter преобразует журналы и снимки ZooKeeper в снимок ClickHouse Keeper. Требуется ZooKeeper версии 3.4 или новее.

Подготовка к миграции

На время миграции нужно остановить ингестию данных. Перед началом запланируйте окно обслуживания. Перед остановкой ZooKeeper остановите фоновые задачи ClickHouse, которые изменяют координационные метаданные. Например:
Зафиксируйте метрики для сравнения перед миграцией, чтобы затем проверить согласованность.

Этапы миграции

  1. Остановите ингестию данных на всех узлах ClickHouse.
  2. Остановите все фоновые задачи на всех узлах ClickHouse (см. выше).
  3. Остановите все узлы ZooKeeper.
  4. Необязательно, но рекомендуется: найдите узел-лидер ZooKeeper, запустите его и затем снова остановите. Это принудительно заставит ZooKeeper записать на диск согласованный снимок перед преобразованием.
  5. Запустите clickhouse-keeper-converter на узле-лидере. Если у вас установлен полный бинарный файл ClickHouse, используйте вместо него подкоманду keeper-converter (clickhouse keeper-converter). Если недоступно ни то ни другое, скачайте бинарный файл.
  1. Скопируйте снимок на все узлы ClickHouse Keeper. Снимок должен находиться на каждом узле до запуска любого из них — если узел запустится без снимка, он может избрать себя лидером с пустым состоянием.
  2. Обновите конфигурацию ClickHouse, чтобы она указывала на новый кластер ClickHouse Keeper.
  3. Запустите ClickHouse Keeper на всех узлах, затем перезапустите ClickHouse.
  4. Сравните метрики с базовыми значениями до миграции, чтобы убедиться в согласованности.
  5. Возобновите фоновые задачи и перезапустите ингестию данных.

Объединение нескольких кластеров ZooKeeper

Если вы используете несколько кластеров ZooKeeper — например, по одному на каждую группу сегментов, — их можно объединить в один кластер ClickHouse Keeper. Официальный инструмент clickhouse-keeper-converter поддерживает только конвертацию в формате «один к одному» (один кластер ZooKeeper в один снимок Keeper), поэтому для консолидации потребуется изменить исходный код конвертера, чтобы объединить несколько снимков:
  1. Запустите clickhouse-keeper-converter отдельно для каждого кластера ZooKeeper, записывая каждый результат в отдельный каталог.
  2. Последовательно десериализуйте файлы снимков. При слиянии пересчитайте значения numChildren, чтобы избежать конфликтов идентификаторов узлов между пространствами имен из разных исходных кластеров.
  3. Запишите объединенный результат в целевой каталог снимков ClickHouse Keeper.

Работа с шифрованием и ACL

ClickHouse Keeper поддерживает те же схемы ACL, что и ZooKeeper (world, auth, digest). Способ обработки ACL при конвертации зависит от вашей конфигурации ZooKeeper:
  • Полностью зашифровано или полностью незашифровано: Конвертируйте напрямую. Конвертер сохранит существующую информацию об ACL.
  • Частично зашифровано: Перед конвертацией выдайте права учётной записи суперадминистратора и очистите ACL с помощью setAcl -R для затронутых путей. Выполните конвертацию, затем при необходимости снова включите шифрование в ClickHouse Keeper.

Проверка миграции

После запуска ClickHouse Keeper и перезапуска ClickHouse сравните ключевые метрики с базовыми значениями, зафиксированными до миграции, чтобы убедиться, что миграция прошла успешно. При консолидации нескольких кластеров ZooKeeper различайте:
  • Общие пути: пути, присутствующие в нескольких исходных кластерах и содержащие одинаковые данные, — для них в объединённом результате следует выполнить дедупликацию.
  • Различающиеся пути: пути, существующие только в определённых кластерах (например, в /clickhouse/tables для каждой группы сегментов), — их необходимо сохранить из соответствующего источника.
Не обходите большие деревья ZooKeeper напрямую для сравнения. Вместо этого в процессе преобразования выводите все преобразованные пути в файл.

Тонкая настройка после миграции

После миграции при необходимости настройте следующие параметры для более крупных кластеров или более высокой пропускной способности: Эти параметры задаются в разделе coordination_settings вашей конфигурации Keeper.

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

Поскольку 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 должен быть диском local, если latest_log_storage_disk не используется. Если используется latest_log_storage_disk, он всегда должен быть диском local. Если 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):
См. также интеграцию Prometheus для ClickHouse Cloud.

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

В этом руководстве приведены простые и минимально необходимые настройки для конфигурации ClickHouse Keeper, а также пример проверки распределённых операций. В примере используются 3 узла Linux.
1

Настройте узлы, указав параметры Keeper

  1. Установите 3 экземпляра ClickHouse на 3 хостах (chnode1, chnode2, chnode3). (Подробности по установке ClickHouse см. в разделе Быстрый старт.)
  2. На каждом узле добавьте следующую запись, чтобы разрешить внешние подключения через сетевой интерфейс.
  3. Добавьте следующую конфигурацию ClickHouse Keeper на все три сервера, изменив параметр <server_id> для каждого из них; для chnode1 это будет 1, для chnode22 и т. д.
    Вот основные настройки, которые использовались выше:
  4. Включите компонент ZooKeeper. Для него будет использоваться движок ClickHouse Keeper:
    Вот основные настройки, которые использовались выше:
  5. Перезапустите ClickHouse и убедитесь, что каждый экземпляр Keeper запущен. Выполните следующую команду на каждом сервере. Команда ruok возвращает imok, если Keeper запущен и работает нормально:
  6. В базе данных system есть таблица zookeeper, содержащая сведения о ваших экземплярах ClickHouse Keeper. Давайте посмотрим на эту таблицу:
    Таблица выглядит так:
2

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

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

Создайте и протестируйте distributed таблицу

  1. Создайте новую базу данных в новом кластере с помощью клиента ClickHouse на chnode1. Предложение ON CLUSTER автоматически создаёт базу данных на обоих узлах.
  2. Создайте новую таблицу в базе данных db1. И снова ON CLUSTER создаёт таблицу на обоих узлах.
  3. На узле chnode1 добавьте пару строк:
  4. Добавьте пару строк на узле chnode2:
  5. Обратите внимание, что выполнение оператора SELECT на каждом узле показывает только данные, находящиеся на этом узле. Например, на chnode1:
    На chnode2:
  6. Вы можете создать таблицу Distributed, чтобы представить данные на двух сегментах. Таблицы с движком таблицы Distributed не хранят собственные данные, но позволяют выполнять распределённую обработку запросов на нескольких серверах. Чтение выполняется со всех сегментов, а операции записи можно распределять между сегментами. Выполните следующий запрос на chnode1:
  7. Обратите внимание, что запрос к dist_table возвращает все четыре строки данных из двух сегментов:

Краткое содержание

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

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

Эта страница не применима к ClickHouse Cloud. Описанная здесь процедура в сервисах ClickHouse Cloud выполняется автоматически.

Описание

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

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

Кластер из трёх узлов будет настроен так, что ClickHouse Keeper будет работать на всех трёх узлах, а ClickHouse — на двух из них. Это обеспечивает для ClickHouse Keeper три узла (включая узел для разрешения спорных ситуаций) и один сегмент ClickHouse, состоящий из двух реплик. Пример конфигурации кластера:

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

  1. Настройте макросы на каждом сервере пример для сервера 1:
Обратите внимание: мы определяем макросы для сегмент и replica, но {uuid} здесь не определён — он встроен, поэтому задавать его не нужно.
  1. Создайте базу данных
  1. Создайте таблицу в кластере с помощью макросов и {uuid}
  1. Создайте distributed таблицу

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

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

Другие варианты

Путь репликации по умолчанию можно заранее задать с помощью макросов, в том числе с использованием {uuid}
  1. Задайте значение по умолчанию для таблиц на каждом узле
Вы также можете определить макрос {database} на каждом узле, если отдельные узлы используются для определённых баз данных.
  1. Создайте таблицу без явного указания параметров:
  1. Убедитесь, что используются настройки из конфигурации по умолчанию

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

Пример команды для получения сведений о таблице и её UUID:
Пример команды для получения информации о таблице в ZooKeeper по UUID таблицы, указанной выше
База данных должна использовать движок Atomic; при обновлении с предыдущей версии база данных default, скорее всего, имеет тип Ordinary.
Чтобы проверить: Например,

Динамическая реконфигурация ClickHouse Keeper

Эта страница не применима к ClickHouse Cloud. Описанная здесь процедура в сервисах ClickHouse Cloud выполняется автоматически.

Описание

ClickHouse Keeper частично поддерживает команду ZooKeeper reconfig для динамической реконфигурации кластера, если включён параметр keeper_server.enable_reconfiguration.
Если этот параметр отключён, кластер можно переконфигурировать, вручную изменив раздел raft_configuration у реплики. Обязательно внесите изменения в файлы на всех репликах, так как применяет их только лидер. Либо можно отправить запрос reconfig через любой клиент, совместимый с ZooKeeper.
Виртуальный узел /keeper/config содержит последнюю подтверждённую конфигурацию кластера в следующем формате:
Пример:
Вы можете использовать команду reconfig, чтобы добавлять новые серверы, удалять существующие и изменять их приоритеты. Ниже приведены примеры (с использованием clickhouse-keeper-client):
Вот примеры для kazoo:
Серверы в joining должны быть указаны в описанном выше формате server. Записи серверов должны разделяться запятыми. При добавлении новых серверов можно не указывать server_priority (значение по умолчанию — 1) и server_type (значение по умолчанию — participant). Если вы хотите изменить приоритет существующего сервера, добавьте его в joining, указав целевой приоритет. Хост, порт и тип сервера должны совпадать с существующей конфигурацией сервера. Серверы добавляются и удаляются в порядке их появления в joining и leaving. Все обновления из joining обрабатываются раньше обновлений из leaving. В реализации реконфигурации Keeper есть несколько особенностей:
  • Поддерживается только инкрементальная реконфигурация. Запросы с непустым new_members отклоняются. Реализация ClickHouse Keeper использует API NuRaft для динамического изменения состава участников. NuRaft позволяет добавлять или удалять только по одному серверу за раз. Это означает, что каждое изменение конфигурации (каждая часть joining, каждая часть leaving) должно рассматриваться отдельно. Поэтому массовая реконфигурация недоступна, поскольку это могло бы ввести конечных пользователей в заблуждение. Изменить тип сервера (participant/learner) тоже невозможно, поскольку это не поддерживается 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, некоторые возможности пока не реализованы (разработка продолжается):
Последнее изменение 23 июля 2026 г.