ZooKeeper

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

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

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

  • установить сервис ZooKeeper в кластер ADQM.

Внешний ZooKeeper

  1. На странице конфигурации сервиса ADQMDB в интерфейсе ADCM выполните следующие действия:

    • активируйте External zookeeper и в поле zk_hosts перечислите через запятую все хосты в ансамбле ZooKeeper с указанием портов, через которые они взаимодействуют;

    • укажите пути к узлам ZooKeeper в секции Zookeeper;

    • установите значение Zookeeper для параметра Coordination system.

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

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

ZooKeeper как сервис ADQM

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

  1. Добавьте сервис Zookeeper в кластер ADQM.

  2. Установите компонент Zookeeper Server на нечетное количество хостов.

  3. Настройте параметры сервиса Zookeeper (см. описания параметров сервиса в соответствующем разделе статьи Конфигурационные параметры).

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

    Нажмите Save, чтобы сохранить настройки.

  4. Установите сервис.

  5. На странице конфигурации сервиса ADQMDB установите значение Zookeeper для параметра Coordination system.

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

    В секции Zookeeper можно настроить пути к узлам ZooKeeper.

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

ПРИМЕЧАНИЕ

  • Если в кластере установлен сервис Zookeeper и одновременно включена опция External zookeeper, для репликации данных и распределения запросов будет использоваться указанный внешний кластер ZooKeeper.

  • Чтобы переустановить компонент Zookeeper Server на другие хосты кластера, можно использовать действие сервиса Zookeeper Add/Remove components.

    После выполнения этого действия необходимо запустить действие Reconfig для сервиса ADQMDB, чтобы применить изменения.

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

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

  1. Сконфигурируйте тестовый кластер — два шарда, в каждом по две реплики (в данном примере используются хосты 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.

  2. Установите сервис 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>

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

  1. Создайте реплицируемую таблицу, выполнив следующий запрос на одном из хостов (например, на хосте 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.

  2. Зайдите на хост host-2 и вставьте данные в таблицу:

    INSERT INTO test_local VALUES (1, 'a');

  3. Убедитесь, что данные реплицируются. Для этого выполните выборку данных из таблицы 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            │
└────┴──────────────┘

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

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

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

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

    SELECT * FROM test_distr;

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

    ┌─id─┬─value_string─┐
│  1 │ a            │
└────┴──────────────┘
┌─id─┬─value_string─┐
│  2 │ b            │
└────┴──────────────┘
Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней