Теперь, настроив Zookeeper в предыдущем задании, вы готовы внести коррективы в конфигурацию нашего кластера и создать реплицируемые таблицы (а также distributed таблицу для них), а так же проверить вставку данных.
Для репликации данных в кластере нас интересуют следующие параметры в конфиг-файле config.xml:
- zookeeper — конфигурация Zookeeper для ClickHouse кластера.
- macros — макросы для подстановки параметров реплицируемых таблиц.
<zookeeper incl="zookeeper-servers" optional="true" />
<macros incl="macros" optional="true" />
Как и в прошлом задании нам нужно, чтобы данные параметры были пустыми, т.к. мы используем файл с подстановками.
Данный кластер будет состоять из 1-го шарда и 2-х реплик. То есть данные между шардами делиться не будут, поскольку у нас всего лишь один шард. Но они будут реплицироваться в рамках одного шарда, поскольку у нас две реплики в одном шарде. То есть каждая нода ClickHouse в нашем случае является репликой. Полная конфигурация cluster.xml выглядит следующим образом:
<?xml version="1.0"?>
<yandex>
<clickhouse_remote_servers>
<mycluster> // Название кластера
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>167.99.142.32</host> // Первая нода одного шарда
<port>9000</port>
</replica>
<replica>
<host>159.65.123.161</host> // Вторая нода одного шарда
<port>9000</port>
</replica>
</shard>
</mycluster>
</clickhouse_remote_servers>
<zookeeper-servers>
<node index="1">
<host>159.65.119.28</host> // сервер зукипер
<port>2181</port> // порт для подключения
</node>
</zookeeper-servers>
<macros>
<cluster>mycluster</cluster> // название кластера
<replica>167.99.142.32</replica> // Адрес данной машины
<shard>01</shard> // Шард данной машины
</macros>
</yandex>
То есть структуру нашего кластера мы отобразили в параметре clickhouse_remote_servers.
Параметр internal_replication отвечает за то, будет ли дублировать ClickHouse запросы на запись или редактирование данных автоматически на все реплики или нет при вставке в distributed таблицу. То есть когда вы вставляете данные в distributed таблицу, она сама может увидеть все реплики в шарде и продублировать запрос на вставку на все реплики этого шарда.
Второй же вариант - это настройка репликации для таблиц через zookeeper своими руками. То есть мы создадим две таблицы и скажем, что они реплицируемые. В этом случае нам не потребуется репликация через distributed, поэтому cтавим true в данном параметре.
Кстати, репликацию можно настроить и без distributed таблиц и описания кластера. Вы просто создаете две реплицированные таблицы и они начнут синхронизироваться между собой.
В конфигурации параметра zookeeper мы указываем кол-во нод Zookeeper. В данном случае мы имеем 1-ну ноду, в ней указываем адрес и порт соответственно. Аттрибут index отвечает за Zookeeper ID. Для продакшен сред мы рекомендуем использовать нечетное число нод для соблюдения кворума, а их количество обычно не будет превышать 7 штук даже на очень больших нагрузках.
Последний блок - это макросы. Они нужны для автоматической подстановки значений при создании реплицированных таблиц (через sql) в ClickHouse. Это позволяет избегать опечаток и других ошибок. Макросы привязаны к хосту, где запущен ClickHouse, а поэтому будут иметь разные значения на разных нодах кластера. Я думаю вы будете разливать конфигурацию clickhouse через ansible или любую другую систему управления конфигурациями, поэтому на каждой ноде у вас окажется нужное значение параметра.
Для тестирования кластера создадим на нем реплицируемые таблицы. Напомню, что таблицы должны находиться на всех нодах и называться одинаково.
CREATE TABLE posts_replicated ON CLUSTER mycluster
(
id Int64,
title String,
description String,
content String,
date Date
)
ENGINE = ReplicatedMergeTree('/clickhouse/{cluster}/tables/posts_replicated', '{replica}')
PARTITION BY date
ORDER BY id;
В этом запросе есть секция ON CLUSTER, которая позволяет выполнить запрос на всех узлах кластера. Для подстановки значений для запроса будут использоваться макросы, которые мы описали ранее. Также необходимо подключение к ZooKeeper серверу.
Здесь мы используем движок ReplicatedMergeTree, который ничем не отличается от движка MergeTree, но позволяет дополнительно реплицировать данные. В параметрах мы указываем путь к таблице в Zookeeper, а также название реплики. Реплицируемые таблицы должны иметь одинаковый путь в Zookeeper. То есть если вы хотите чтобы 5 нод реплицировали одну и ту же таблицу - то путь в зукипере у них будет один и тот же - /clickhouse/{cluster}/tables/posts_replicated, а вот индекс реплики будет отличаться.
Значения переменных {cluster} и {replica} автоматически подставятся для каждой ноды на кластере из макросов.
Собственно на этом можно заканчивать рассказ про репликацию, поскольку она уже настроена для данной таблицы. Но мы пойдем дальше и создадим distributed таблицу для чтения данных из реплик.
Создадим Distributed таблицы. Опять же они должны иметь такую же структуру, как и реплицируемые таблицы:
CREATE TABLE posts_distributed ON CLUSTER 'mycluster'
(
id Int64,
title String,
description String,
content String,
date Date
)
ENGINE = Distributed('{cluster}', 'default', 'posts_replicated', rand());
В параметрах движка Distributed также используем переменную cluster из макросов.
Теперь проверим, реплицируются ли данные при вставке. Для этого мы вставим данные в ch1 ноду и посмотрим, появятся ли они в ch2 ноде.
root@ch1:~# clickhouse-client --query "INSERT INTO posts_replicated FORMAT CSV" < posts.csv
root@ch1:~# clickhouse-client --query "SELECT count() FROM posts_replicated"
500000
Как мы видим, данные успешно вставились. Теперь сделаем выборку с ch2 ноды:
root@ch2:~# clickhouse-client --query "SELECT count() FROM posts_replicated"
500000
root@ch2:~# clickhouse-client --query "SELECT count() FROM posts_distributed"
500000
Видно, что на другой ноде данные появились, а также, что distributed таблица тоже отображает наши данные и не дублирует их!
Отлично, мы настроили реплицируемый ClickHouse кластер!