Приветствую, читатель! Сегодня мы закончим реализовывать отказоустойчивый кластер Clickhouse. Мы поставим точку или многоточие в этой теме засчет того, что создадим базу данных на трех узлах, а в этой базе создадим таблицу, работающую на движке ReplicatedMergeTree. Предыдущий пост.

Если отринуть исследование и осознание внутреннего устройства Zookeeper или Keeper, а также принципы работы Clickhouse с ним, остается совсем немного до завершения развертывания кластера.

Любым удобным образом (через веб-морду на порту localhost:8123/play, посредством CLI clickhouse client или каким- угодно иным образом) отправляем запрос на создание базы на кластере cluster_name. cluster_name - это имя кластера, которое было определено пользователем в конфиге. Никто не помешает ипользовать иное имя для кластера или создать их больше, нежели 1. Приписка ON CLUSTER даст Clickhouse’у понять, что этот запрос распределенный, то есть его нужно отправить на все сервера кластера и дождаться, пока они его выполнят. По-сути Clickhouse обратится к свои собратьям- серверам и скажет: “Выполни вот этот запрос: …” Собственно, в этом и состоит суть распределенных DDL- запросов.

Создание БД:

CREATE DATABASE db_name ON CLUSTER cluster_name

Создание

Создание таблицы:

CREATE TABLE db_name.table_name on CLUSTER cluster_name
(
    ...
) ENGINE = ReplicatedMergeTree()
ORDER BY ...

В принципе, этого достаточно, чтобы пользоваться кластером, ведь в нём есть целая табличка. Но если копнуть чуть глубже, то выясняется, что ReplicatedMergeTree() принимает два, три, а то и более параметров. В официальной документации вы можете найти вот такое:

ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/{shard}/table_name', '{replica}', ver)

Аналогичная ситуация состоит и с ReplicatedMergeTree.

ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/table_name', '{replica}', ver)

ReplicatedMergeTree(zoo_path, replica_name, other_parameters) может принимать 3 параметра:

  • zoo_path - путь до таблицы внутри файловой системы Keeper’а;
  • replica_name - имя реплики/hostname узла clickhouse в Keeper;
  • other_parameters - параметры движка, например, версия;

Если вы преследуете цель запуска кластера для обеспечения работы базы данных и несколькими реплицируемыми табличками в ней, то вам не обязательно указывать перечисленные выше параметры, при создании таблицы. На самом деле, эти параметры начинают играть роль, когда вы обслуживаете, предположим, десяток серверов, штук 5 кластеров, два десятка шардов и штук 30 таблиц. Вот в этом случае вам наверняка будет сподручно указать значащие, понятные для человека, пути к таблицам (zoo_path), а также названия реплик, чтобы не запутаться при разрешении проблем с кластером в будущем.

Буквально пара слов об zoo_path. Ранее я уже говорил о том, что внутри кластера Keeper существует нечто наподобие распределенной файловой системы. Внутри этой файловой системы по указанным при создании таблицы или по стандартным путям хранится мета-информация о таблице.

Осталось прояснить, что такое {shard} и {replica}. Это места подстановки. В конфигах clickhouse следует определить секцию macros, а внутри указать значение для replica. Этот конфиг должен отличаться на каждом из узлов. Поскольку при выполненни распределенного запроса, Clickhouse на каждом из узлов будет подставлять знвчение для replica. Ознакомиться с примером использования можно в репозитории с докер-проектом в файлике keeper.xml любого из docker-контейнеров (директории click1, click2 или click3).

<clickhouse>
    <macros>
        <shard>standart_shard</shard>
        <replica>replica_3</replica>
    </macros>
</clickhouse>

В общем, таким образом развертывается кластер, на котором работает реплицируемая таблица.

В будущем рассмотрим распределенные системы, сервисы координцаии (это как раз Zookeeper/Keeper), заглянем в то, как устроен Keeper/Zookeeper, а также попробуем описать взаимодействие этого сервиса с Clickhouse.