ZooKeeper

Елена Дворядкина

Содержание

Внешний ZooKeeper
ZooKeeper как сервис ADQM
Пример тестирования реплицируемых и распределенных таблиц

Чтобы репликация данных и выполнение распределенных запросов в ADQM осуществлялись через ZooKeeper, можно:

использовать внешний кластер ZooKeeper;
установить сервис ZooKeeper в кластер ADQM.

Внешний ZooKeeper

На странице конфигурации сервиса ADQMDB в интерфейсе ADCM выполните следующие действия:
- активируйте External zookeeper и в поле zk_hosts перечислите через запятую все хосты в ансамбле ZooKeeper с указанием портов, через которые они взаимодействуют;
- укажите пути к узлам ZooKeeper в секции Zookeeper;
- установите значение Zookeeper для параметра System в секции Engine .
Нажмите Save и выполните действие Reconfig and restart для сервиса ADQMDB, чтобы включить использование внешнего ZooKeeper в качестве сервиса координации для кластера ADQM.

Подключение внешнего ZooKeeper

ZooKeeper как сервис ADQM

ADQM предоставляет специальный сервис, который можно добавить и установить в кластер, чтобы репликация и распределение запросов координировались через ZooKeeper. Для этого выполните следующие шаги в интерфейсе ADCM:

Добавьте сервис Zookeeper в кластер ADQM.
Установите компонент Zookeeper Server на нечетное количество хостов.
Настройте параметры сервиса Zookeeper (см. описания параметров сервиса в соответствующем разделе статьи Конфигурационные параметры).

Настройка сервиса Zookeeper

Нажмите Save, чтобы сохранить настройки.
Установите сервис.
На странице конфигурации сервиса ADQMDB в секции Engine установите значение Zookeeper для параметра System.

Включение сервиса Zookeeper

В секции Zookeeper можно настроить пути к узлам ZooKeeper.
Нажмите Save и выполните действие Reconfig and restart для сервиса ADQMDB, чтобы включить использование установленного ZooKeeper в качестве сервиса координации для кластера ADQM.

ПРИМЕЧАНИЕ

Если в кластере установлен сервис Zookeeper и одновременно включена опция External zookeeper, для репликации данных и распределения запросов будет использоваться указанный внешний кластер ZooKeeper.
Чтобы переустановить компонент Zookeeper Server на другие хосты кластера, можно использовать действия сервиса Zookeeper:
- Expand — установка компонента Zookeeper Server на хосты.
- Shrink — удаление компонента Zookeeper Server с хостов.
После выполнения этих действий необходимо запустить действие Reconfig and restart для сервиса ADQMDB, чтобы применить изменения.

Пример тестирования реплицируемых и распределенных таблиц

Конфигурирование кластера ADQM c ZooKeeper

Сконфигурируйте тестовый кластер — два шарда, в каждом по две реплики (в данном примере используются хосты host-1, host-2, host-3 и host-4). В статье Конфигурирование логических кластеров в интерфейсе ADCM описано, как это сделать через интерфейс ADCM. В этом случае все необходимые секции (описанные ниже) добавятся в конфигурационный файл каждого сервера автоматически.
- Конфигурация логического кластера
  
  В файле config.xml конфигурация логического кластера описывается в секции remote_servers:
  
  <remote_servers> <default_cluster> <shard> <internal_replication>true</internal_replication> <weight>1</weight> <replica> <host>host-1</host> <port>9000</port> </replica> <replica> <host>host-2</host> <port>9000</port> </replica> </shard> <shard> <internal_replication>true</internal_replication> <weight>1</weight> <replica> <host>host-3</host> <port>9000</port> </replica> <replica> <host>host-4</host> <port>9000</port> </replica> </shard> </default_cluster> </remote_servers>
  
  В данном примере будет использоваться реплицируемая таблица ReplicatedMergeTree, поэтому параметр internal_replication для каждого шарда устанавливается в true — в этом случае репликацию данных будет выполнять реплицируемая таблица (то есть данные будут записываться в любую доступную реплику, другая реплика получит данные автоматически). Если бы использовались обычные таблицы, то параметр internal_replication надо было бы установить в false, чтобы репликацию данных выполняла таблица Distributed (данные будут записываться на все реплики шарда).
- Макросы
  
  В настройках каждого сервера должна также присутствовать секция macros, в которой определяются идентификаторы шарда и реплики для автоматической подстановки соответствующих хосту значений при создании реплицируемых таблиц на кластере (ON CLUSTER). Например, макросы для host-1 в кластере default_cluster:
  
  <macros> <replica>1</replica> <shard>1</shard> </macros>
  
  Если вы настраиваете логический кластер в интерфейсе ADCM через параметр Cluster Configuration и указываете имя кластера, например, abc, то ADQM автоматически пропишет в config.xml макросы следующего вида (для host-1 в составе кластера abc, топология которого аналогична приведенной выше):
  
  <macros> <abc_replica>1</abc_replica> <abc_shard>1</abc_shard> </macros>
  
  В этом случае при создании реплицируемых таблиц нужно будет использовать переменные {abc_shard} и {abc_replica} в параметрах ReplicatedMergeTree.
Установите сервис Zookeeper на 3 хоста (host-1, host-2, host-3). После этого в конфигурационный файл config.xml добавятся секции:
- zookeeper — список узлов ZooKeeper;
- distributed_ddl — путь в ZooKeeper для очереди DDL-запросов (если несколько кластеров используют один и тот же ZooKeeper, этот путь должен быть уникальным для каждого кластера).
```
<zookeeper>
    <node>
        <host>host-1</host>
        <port>2181</port>
    </node>
    <node>
        <host>host-2</host>
        <port>2181</port>
    </node>
    <node>
        <host>host-3</host>
        <port>2181</port>
    </node>
    <root>/clickhouse</root>
</zookeeper>

<distributed_ddl>
    <path>/clickhouse/task_queue/ddl</path>
</distributed_ddl>
```

Реплицируемые таблицы

Создайте реплицируемую таблицу, выполнив следующий запрос на одном из хостов (например, на хосте host-1):
```
CREATE TABLE test_local ON CLUSTER default_cluster (id Int32, value_string String)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/test_local', '{replica}')
ORDER BY id;
```
Этот запрос создаст таблицу test_local на всех хостах кластера default_cluster.
Зайдите на хост host-2 и вставьте данные в таблицу:
```
INSERT INTO test_local VALUES (1, 'a');
```
Убедитесь, что данные реплицируются. Для этого выполните выборку данных из таблицы test_local на хосте host-1:
```
SELECT * FROM test_local;
```
Если все работает правильно, в таблицу на хосте host-1 автоматически скопируются данные, которые были записаны в реплику на хосте host-2:
```
┌─id─┬─value_string─┐
│  1 │ a            │
└────┴──────────────┘
```

Распределенные таблицы

Обратите внимание, запрос SELECT возвращает данные только из таблицы на том хосте, на котором выполняется запрос.

Вставьте данные в любую реплику на второй шард (например, в таблицу на хосте host-3):

INSERT INTO test_local VALUES (2, 'b');

Повторите запрос SELECT на хосте host-1 или host-2 — данные со второго шарда не попадают в выборку:

┌─id─┬─value_string─┐
│  1 │ a            │
└────┴──────────────┘

Чтобы получать данные со всех шардов, можно использовать распределенные таблицы (см. подробную информацию в разделе Распределенные таблицы).

Создайте таблицу на движке Distributed:

CREATE TABLE test_distr ON CLUSTER default_cluster AS default.test_local
ENGINE = Distributed(default_cluster, default, test_local, rand());

Выполните следующий запрос на любом хосте:

SELECT * FROM test_distr;

В результирующую выборку включены данные с обоих шардов кластера:

┌─id─┬─value_string─┐
│  1 │ a            │
└────┴──────────────┘
┌─id─┬─value_string─┐
│  2 │ b            │
└────┴──────────────┘

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней