Эта страница не применима к ClickHouse Cloud. Описанная здесь процедура в сервисах ClickHouse Cloud выполняется автоматически.
Подробности реализации
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.
Внешние интеграции не поддерживаются.
Конфигурация
.xml.
Настройки конфигурации 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+), рекомендуем включить этот параметр, так как он может повысить производительность без каких-либо недостатков.test_keeper_. Пример конфигурации для сервера №1:
Как запустить
<keeper_server> в /etc/your_path_to_config/clickhouse-server/config.xml и запустите ClickHouse server как обычно. Если вы хотите запустить автономный ClickHouse Keeper, это можно сделать аналогичным образом с помощью:
clickhouse-keeper), вы можете создать её или указать keeper в качестве аргумента для clickhouse:
Команды из четырёх букв
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, используя клиентский порт.
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
/ready:
Флаги возможностей
keeper_server.feature_flags.
Все возможности можно явно отключить.
Если вы хотите включить новую возможность в своем кластере Keeper, мы рекомендуем сначала обновить все узлы Keeper в кластере до версии, которая поддерживает эту возможность, а затем включить саму возможность.
Пример конфигурации флагов возможностей, которая отключает multi_read и включает check_not_exists:
Некоторые флаги возможностей включены по умолчанию начиная с версии 25.7.
Рекомендуемый способ обновить Keeper до 25.7+ — сначала обновиться до версии 24.9+.
Миграция с ZooKeeper
clickhouse-keeper-converter преобразует журналы и снимки ZooKeeper в снимок ClickHouse Keeper. Требуется ZooKeeper версии 3.4 или новее.
Подготовка к миграции
Этапы миграции
- Остановите ингестию данных на всех узлах ClickHouse.
- Остановите все фоновые задачи на всех узлах ClickHouse (см. выше).
- Остановите все узлы ZooKeeper.
- Необязательно, но рекомендуется: найдите узел-лидер ZooKeeper, запустите его и затем снова остановите. Это принудительно заставит ZooKeeper записать на диск согласованный снимок перед преобразованием.
-
Запустите
clickhouse-keeper-converterна узле-лидере. Если у вас установлен полный бинарный файл ClickHouse, используйте вместо него подкомандуkeeper-converter(clickhouse keeper-converter). Если недоступно ни то ни другое, скачайте бинарный файл.
- Скопируйте снимок на все узлы ClickHouse Keeper. Снимок должен находиться на каждом узле до запуска любого из них — если узел запустится без снимка, он может избрать себя лидером с пустым состоянием.
- Обновите конфигурацию ClickHouse, чтобы она указывала на новый кластер ClickHouse Keeper.
- Запустите ClickHouse Keeper на всех узлах, затем перезапустите ClickHouse.
- Сравните метрики с базовыми значениями до миграции, чтобы убедиться в согласованности.
- Возобновите фоновые задачи и перезапустите ингестию данных.
Объединение нескольких кластеров ZooKeeper
clickhouse-keeper-converter поддерживает только конвертацию в формате «один к одному» (один кластер ZooKeeper в один снимок Keeper), поэтому для консолидации потребуется изменить исходный код конвертера, чтобы объединить несколько снимков:
- Запустите
clickhouse-keeper-converterотдельно для каждого кластера ZooKeeper, записывая каждый результат в отдельный каталог. - Последовательно десериализуйте файлы снимков. При слиянии пересчитайте значения
numChildren, чтобы избежать конфликтов идентификаторов узлов между пространствами имен из разных исходных кластеров. - Запишите объединенный результат в целевой каталог снимков ClickHouse Keeper.
Работа с шифрованием и ACL
world, auth, digest). Способ обработки ACL при конвертации зависит от вашей конфигурации ZooKeeper:
- Полностью зашифровано или полностью незашифровано: Конвертируйте напрямую. Конвертер сохранит существующую информацию об ACL.
- Частично зашифровано: Перед конвертацией выдайте права учётной записи суперадминистратора и очистите ACL с помощью
setAcl -Rдля затронутых путей. Выполните конвертацию, затем при необходимости снова включите шифрование в ClickHouse Keeper.
Проверка миграции
- Общие пути: пути, присутствующие в нескольких исходных кластерах и содержащие одинаковые данные, — для них в объединённом результате следует выполнить дедупликацию.
- Различающиеся пути: пути, существующие только в определённых кластерах (например, в
/clickhouse/tablesдля каждой группы сегментов), — их необходимо сохранить из соответствующего источника.
Тонкая настройка после миграции
Эти параметры задаются в разделе
coordination_settings вашей конфигурации Keeper.
Восстановление после потери кворума
- Убедитесь, что вышедшие из строя узлы больше не смогут подключиться к кластеру.
- Не запускайте новые узлы, пока это не будет указано в шагах.
- Выберите один узел Keeper, который станет новым лидером. Учтите, что данные именно этого узла будут использованы для всего кластера, поэтому мы рекомендуем выбрать узел с наиболее актуальным состоянием.
- Прежде чем делать что-либо еще, создайте резервную копию каталогов
log_storage_pathиsnapshot_storage_pathна выбранном узле. - Выполните реконфигурацию кластера на всех узлах, которые вы хотите использовать.
- Отправьте на выбранный узел четырехбуквенную команду
rcvr, чтобы перевести узел в режим восстановления, ИЛИ остановите экземпляр Keeper на выбранном узле и снова запустите его с аргументом--force-recovery. - По одному запускайте экземпляры Keeper на новых узлах, убеждаясь, что
mntrвозвращаетfollowerдляzk_server_stateперед запуском следующего узла. - В режиме восстановления узел-лидер будет возвращать сообщение об ошибке для команды
mntr, пока не достигнет кворума с новыми узлами, и будет отклонять любые запросы от клиента и последователей. - После достижения кворума узел-лидер вернется в обычный режим работы и начнет принимать все запросы с проверкой через Raft — проверьте это с помощью
mntr, который должен возвращатьleaderдляzk_server_state.
Использование дисков с 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_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.
Настройка кэша журналов
latest_logs_cache_size_threshold- общий размер последних журналов, хранящихся в кэшеcommit_logs_cache_size_threshold- общий размер последующих журналов, которые должны быть зафиксированы следующими
Вы можете использовать команду
pfev, чтобы проверить объём журналов, считанных из каждого кэша и из файла.
Вы также можете использовать метрики из конечной точки Prometheus, чтобы отслеживать текущий размер обоих кэшей.Prometheus
endpoint– HTTP-конечная точка для сбора метрик сервером Prometheus. Должна начинаться с ’/’.port– Порт дляendpoint.metrics– Флаг, включающий экспорт метрик из таблицы system.metrics.events– Флаг, включающий экспорт метрик из таблицы system.events.asynchronous_metrics– Флаг, включающий экспорт текущих значений метрик из таблицы system.asynchronous_metrics.
127.0.0.1 на IP-адрес или имя хоста вашего сервера ClickHouse):
Руководство пользователя ClickHouse Keeper
1
Настройте узлы, указав параметры Keeper
-
Установите 3 экземпляра ClickHouse на 3 хостах (
chnode1,chnode2,chnode3). (Подробности по установке ClickHouse см. в разделе Быстрый старт.) -
На каждом узле добавьте следующую запись, чтобы разрешить внешние подключения через сетевой интерфейс.
-
Добавьте следующую конфигурацию ClickHouse Keeper на все три сервера, изменив параметр
<server_id>для каждого из них; дляchnode1это будет1, дляchnode2—2и т. д.Вот основные настройки, которые использовались выше: -
Включите компонент ZooKeeper. Для него будет использоваться движок ClickHouse Keeper:
Вот основные настройки, которые использовались выше:
-
Перезапустите ClickHouse и убедитесь, что каждый экземпляр Keeper запущен. Выполните следующую команду на каждом сервере. Команда
ruokвозвращаетimok, если Keeper запущен и работает нормально: -
В базе данных
systemесть таблицаzookeeper, содержащая сведения о ваших экземплярах ClickHouse Keeper. Давайте посмотрим на эту таблицу:Таблица выглядит так:
2
Настройте кластер в ClickHouse
-
Давайте настроим простой кластер с 2 сегментами и только одной репликой на двух узлах. Третий узел будет использоваться для обеспечения кворума, необходимого ClickHouse Keeper. Обновите конфигурацию на
chnode1иchnode2. Следующая конфигурация кластера задает по 1 сегменту на каждом узле, то есть всего 2 сегмента без репликации. В этом примере часть данных будет находиться на одном узле, а часть — на другом: -
Перезапустите ClickHouse и убедитесь, что кластер создан:
Вы должны увидеть свой кластер:
3
Создайте и протестируйте distributed таблицу
-
Создайте новую базу данных в новом кластере с помощью клиента ClickHouse на
chnode1. ПредложениеON CLUSTERавтоматически создаёт базу данных на обоих узлах. -
Создайте новую таблицу в базе данных
db1. И сноваON CLUSTERсоздаёт таблицу на обоих узлах. -
На узле
chnode1добавьте пару строк: -
Добавьте пару строк на узле
chnode2: -
Обратите внимание, что выполнение оператора
SELECTна каждом узле показывает только данные, находящиеся на этом узле. Например, наchnode1:Наchnode2: -
-
Вы можете создать таблицу
Distributed, чтобы представить данные на двух сегментах. Таблицы с движком таблицыDistributedне хранят собственные данные, но позволяют выполнять распределённую обработку запросов на нескольких серверах. Чтение выполняется со всех сегментов, а операции записи можно распределять между сегментами. Выполните следующий запрос наchnode1: -
Обратите внимание, что запрос к
dist_tableвозвращает все четыре строки данных из двух сегментов:
Краткое содержание
Настройка ClickHouse Keeper с уникальными путями
Эта страница не применима к ClickHouse Cloud. Описанная здесь процедура в сервисах ClickHouse Cloud выполняется автоматически.
Описание
{uuid}
для создания уникальных записей в ClickHouse Keeper или ZooKeeper. Уникальные
пути полезны при частом создании и удалении таблиц, поскольку
позволяют не ждать несколько минут, пока сборщик мусора Keeper
удалит записи путей: при каждом создании пути в нём используется новый uuid,
поэтому пути никогда не используются повторно.
Пример окружения
Пример конфигурации кластера:
Настройка таблиц для использования {uuid}
- Настройте макросы на каждом сервере пример для сервера 1:
Обратите внимание: мы определяем макросы для
сегмент и replica, но {uuid} здесь не определён — он встроен, поэтому задавать его не нужно.- Создайте базу данных
- Создайте таблицу в кластере с помощью макросов и
{uuid}
- Создайте distributed таблицу
Тестирование
- Вставьте данные в первый узел (например,
chnode1)
- Вставьте данные на второй узел (например,
chnode2)
- Просмотрите записи с использованием distributed таблицы
Другие варианты
{uuid}
- Задайте значение по умолчанию для таблиц на каждом узле
- Создайте таблицу без явного указания параметров:
- Убедитесь, что используются настройки из конфигурации по умолчанию
Устранение неполадок
База данных должна использовать движок
Atomic; при обновлении с предыдущей версии
база данных default, скорее всего, имеет тип Ordinary.Динамическая реконфигурация ClickHouse Keeper
Эта страница не применима к ClickHouse Cloud. Описанная здесь процедура в сервисах ClickHouse Cloud выполняется автоматически.
Описание
reconfig
для динамической реконфигурации кластера, если включён параметр keeper_server.enable_reconfiguration.
Если этот параметр отключён, кластер можно переконфигурировать, вручную изменив раздел
raft_configuration у реплики. Обязательно внесите изменения в файлы на всех репликах, так как
применяет их только лидер. Либо можно отправить запрос reconfig через любой клиент,
совместимый с ZooKeeper./keeper/config содержит последнюю подтверждённую конфигурацию кластера в следующем формате:
- Каждая запись о server отделяется новой строкой.
server_type— либоparticipant, либоlearner(learner не участвует в выборах лидера).server_priority— неотрицательное целое число, указывающее, каким узлам следует отдавать приоритет при выборе лидера. Приоритет 0 означает, что server никогда не станет лидером.
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 должен быть включён параметр конфигурации
keeper_server.enable_reconfiguration. - Запустите второй узел с полной новой конфигурацией кластера Keeper.
- После запуска добавьте его на узел 1 с помощью
reconfig. - Затем запустите третий узел и добавьте его с помощью
reconfig. - Обновите конфигурацию
clickhouse-server, добавив в неё новый узел Keeper, и перезапустите его, чтобы применить изменения. - Обновите конфигурацию Raft на узле 1 и, при необходимости, перезапустите его.
Неподдерживаемые возможности
createне поддерживает возврат объектаStatcreateне поддерживает TTLaddWatchне работает с наблюдениямиPERSISTENTremoveWatchиremoveAllWatchesне поддерживаютсяsetWatchesне поддерживается- Создание znode типа
CONTAINERне поддерживается SASL authenticationне поддерживается