Репликация + масштабирование

В этом примере вы узнаете, как настроить простой кластер ClickHouse, использующий репликацию и масштабирование. Он состоит из двух сегментов и двух реплик, а также 3-узлового кластера ClickHouse Keeper для управления координацией и поддержания кворума в кластере.

Архитектура кластера, который вы будете настраивать, показана ниже:

Хотя ClickHouse Server и ClickHouse Keeper можно запускать вместе на одном сервере, мы настоятельно рекомендуем использовать выделенные хосты для ClickHouse Keeper в производственных средах — именно этот подход мы и продемонстрируем в данном примере.Серверы Keeper могут быть менее мощными, и 4 ГБ оперативной памяти обычно достаточно для каждого сервера Keeper до тех пор, пока ваши серверы ClickHouse не станут достаточно крупными.

Предварительные требования

Вы уже настраивали локальный сервер ClickHouse
Вы знакомы с базовыми принципами конфигурирования ClickHouse, например с файлами конфигурации
На вашем компьютере установлен Docker

Настройка структуры каталогов и тестовой среды

Файлы с примерамиСледующие шаги помогут вам с нуля настроить кластер. Если вы хотите пропустить их и сразу перейти к запуску кластера, файлы с примерами можно взять из репозитория examples каталог «docker-compose-recipes».

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

mkdir cluster_2S_2R
cd cluster_2S_2R

# Создать директории clickhouse-keeper
for i in {01..03}; do
  mkdir -p fs/volumes/clickhouse-keeper-${i}/etc/clickhouse-keeper
done

# Создать директории clickhouse-server
for i in {01..04}; do
  mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server
done

Добавьте следующий файл docker-compose.yml в каталог clickhouse-cluster:

docker-compose.yml

version: '3.8'
services:
  clickhouse-01:
    image: "clickhouse/clickhouse-server:latest"
    user: "101:101"
    container_name: clickhouse-01
    hostname: clickhouse-01
    volumes:
      - ${PWD}/fs/volumes/clickhouse-01/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml
      - ${PWD}/fs/volumes/clickhouse-01/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml
    ports:
      - "127.0.0.1:8123:8123"
      - "127.0.0.1:9000:9000"
    depends_on:
      - clickhouse-keeper-01
      - clickhouse-keeper-02
      - clickhouse-keeper-03
  clickhouse-02:
    image: "clickhouse/clickhouse-server:latest"
    user: "101:101"
    container_name: clickhouse-02
    hostname: clickhouse-02
    volumes:
      - ${PWD}/fs/volumes/clickhouse-02/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml
      - ${PWD}/fs/volumes/clickhouse-02/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml
    ports:
      - "127.0.0.1:8124:8123"
      - "127.0.0.1:9001:9000"
    depends_on:
      - clickhouse-keeper-01
      - clickhouse-keeper-02
      - clickhouse-keeper-03
  clickhouse-03:
    image: "clickhouse/clickhouse-server:latest"
    user: "101:101"
    container_name: clickhouse-03
    hostname: clickhouse-03
    volumes:
      - ${PWD}/fs/volumes/clickhouse-03/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml
      - ${PWD}/fs/volumes/clickhouse-03/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml
    ports:
      - "127.0.0.1:8125:8123"
      - "127.0.0.1:9002:9000"
    depends_on:
      - clickhouse-keeper-01
      - clickhouse-keeper-02
      - clickhouse-keeper-03
  clickhouse-04:
    image: "clickhouse/clickhouse-server:latest"
    user: "101:101"
    container_name: clickhouse-04
    hostname: clickhouse-04
    volumes:
      - ${PWD}/fs/volumes/clickhouse-04/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml
      - ${PWD}/fs/volumes/clickhouse-04/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml
    ports:
      - "127.0.0.1:8126:8123"
      - "127.0.0.1:9003:9000"
    depends_on:
      - clickhouse-keeper-01
      - clickhouse-keeper-02
      - clickhouse-keeper-03
  clickhouse-keeper-01:
    image: "clickhouse/clickhouse-keeper:latest-alpine"
    user: "101:101"
    container_name: clickhouse-keeper-01
    hostname: clickhouse-keeper-01
    volumes:
      - ${PWD}/fs/volumes/clickhouse-keeper-01/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml
    ports:
      - "127.0.0.1:9181:9181"
  clickhouse-keeper-02:
    image: "clickhouse/clickhouse-keeper:latest-alpine"
    user: "101:101"
    container_name: clickhouse-keeper-02
    hostname: clickhouse-keeper-02
    volumes:
      - ${PWD}/fs/volumes/clickhouse-keeper-02/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml
    ports:
      - "127.0.0.1:9182:9181"
  clickhouse-keeper-03:
    image: "clickhouse/clickhouse-keeper:latest-alpine"
    user: "101:101"
    container_name: clickhouse-keeper-03
    hostname: clickhouse-keeper-03
    volumes:
      - ${PWD}/fs/volumes/clickhouse-keeper-03/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml
    ports:
      - "127.0.0.1:9183:9181"

Создайте следующие подкаталоги и файлы:

for i in {01..04}; do
  mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server/config.d
  mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server/users.d
  touch fs/volumes/clickhouse-${i}/etc/clickhouse-server/config.d/config.xml
  touch fs/volumes/clickhouse-${i}/etc/clickhouse-server/users.d/users.xml
done

Каталог config.d содержит файл конфигурации сервера ClickHouse config.xml, в котором задаётся пользовательская конфигурация для каждого узла ClickHouse. Эта конфигурация объединяется с файлом конфигурации ClickHouse config.xml по умолчанию, который входит в состав каждой установки ClickHouse.
Каталог users.d содержит файл пользовательской конфигурации users.xml, в котором задаётся пользовательская конфигурация для пользователей. Эта конфигурация объединяется с файлом конфигурации ClickHouse users.xml по умолчанию, который входит в состав каждой установки ClickHouse.

Пользовательские каталоги конфигурацииРекомендуется использовать каталоги config.d и users.d при создании собственной конфигурации, а не изменять напрямую конфигурацию по умолчанию в /etc/clickhouse-server/config.xml и etc/clickhouse-server/users.xml.Строка

<clickhouse replace="true">

обеспечивает, что разделы конфигурации, определённые в каталогах config.d и users.d, переопределяют разделы конфигурации по умолчанию, заданные в стандартных файлах config.xml и users.xml.

Настройка узлов ClickHouse

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

Теперь измените каждый пустой файл конфигурации config.xml, расположенный по пути fs/volumes/clickhouse-{}/etc/clickhouse-server/config.d. Выделенные ниже строки необходимо изменить так, чтобы они соответствовали конкретному узлу:

<clickhouse replace="true">
    <logger>
        <level>debug</level>
        <log>/var/log/clickhouse-server/clickhouse-server.log</log>
        <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
        <size>1000M</size>
        <count>3</count>
    </logger>
    <display_name>cluster_2S_2R node 1</display_name>
    <listen_host>0.0.0.0</listen_host>
    <http_port>8123</http_port>
    <tcp_port>9000</tcp_port>
    <user_directories>
        <users_xml>
            <path>users.xml</path>
        </users_xml>
        <local_directory>
            <path>/var/lib/clickhouse/access/</path>
        </local_directory>
    </user_directories>
    <distributed_ddl>
        <path>/clickhouse/task_queue/ddl</path>
    </distributed_ddl>
    <remote_servers>
        <cluster_2S_2R>
            <shard>
                <internal_replication>true</internal_replication>
                <replica>
                    <host>clickhouse-01</host>
                    <port>9000</port>
                </replica>
                <replica>
                    <host>clickhouse-03</host>
                    <port>9000</port>
                </replica>
            </shard>
            <shard>
                <internal_replication>true</internal_replication>
                <replica>
                    <host>clickhouse-02</host>
                    <port>9000</port>
                </replica>
                <replica>
                    <host>clickhouse-04</host>
                    <port>9000</port>
                </replica>
            </shard>
        </cluster_2S_2R>
    </remote_servers>
    <zookeeper>
        <node>
            <host>clickhouse-keeper-01</host>
            <port>9181</port>
        </node>
        <node>
            <host>clickhouse-keeper-02</host>
            <port>9181</port>
        </node>
        <node>
            <host>clickhouse-keeper-03</host>
            <port>9181</port>
        </node>
    </zookeeper>
    <macros>
        <shard>01</shard>
        <replica>01</replica>
    </macros>
</clickhouse>

Каталог	File
`fs/volumes/clickhouse-01/etc/clickhouse-server/config.d`	`config.xml`
`fs/volumes/clickhouse-02/etc/clickhouse-server/config.d`	`config.xml`
`fs/volumes/clickhouse-03/etc/clickhouse-server/config.d`	`config.xml`
`fs/volumes/clickhouse-04/etc/clickhouse-server/config.d`	`config.xml`

Каждый раздел приведённого выше конфигурационного файла подробно описан ниже.

Сеть и логирование

Возможность внешних подключений через сетевой интерфейс включается при активации настройки listen host. Это гарантирует, что хост сервера ClickHouse доступен с других хостов:

<listen_host>0.0.0.0</listen_host>

Порт HTTP API установлен на 8123:

<http_port>8123</http_port>

TCP-порт для взаимодействия по собственному протоколу ClickHouse между clickhouse-client и другими инструментами ClickHouse, а также между clickhouse-server и другими clickhouse-servers, установлен в 9000:

<tcp_port>9000</tcp_port>

Конфигурация логирования задаётся в блоке <logger>. Приведённая ниже конфигурация создаёт отладочный лог с ротацией по достижении 1000 МБ, выполняемой трижды:

<logger>
   <level>debug</level>
   <log>/var/log/clickhouse-server/clickhouse-server.log</log>
   <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
   <size>1000M</size>
   <count>3</count>
</logger>

Дополнительные сведения о конфигурации логирования см. в комментариях в стандартном файле конфигурации ClickHouse.

Конфигурация кластера

Конфигурация кластера задаётся в блоке <remote_servers>. Здесь определяется имя кластера cluster_2S_2R.Блок <cluster_2S_2R></cluster_2S_2R> определяет структуру кластера с помощью настроек <shard></shard> и <replica></replica> и служит шаблоном для запросов distributed DDL — запросов, выполняемых по всему кластеру с использованием предложения ON CLUSTER. По умолчанию запросы distributed DDL разрешены, однако их можно отключить с помощью настройки allow_distributed_ddl_queries.internal_replication установлен в true, чтобы данные записывались только в одну из реплик.

<remote_servers>
   <!-- имя кластера (не должно содержать точек) -->
  <cluster_2S_2R>
      <!-- <allow_distributed_ddl_queries>false</allow_distributed_ddl_queries> -->
      <shard>
          <!-- Необязательно. Записывать ли данные только на одну из реплик. По умолчанию: false (записывать данные на все реплики). -->
          <internal_replication>true</internal_replication>
          <replica>
              <host>clickhouse-01</host>
              <port>9000</port>
          </replica>
          <replica>
              <host>clickhouse-03</host>
              <port>9000</port>
          </replica>
      </shard>
      <shard>
          <internal_replication>true</internal_replication>
          <replica>
              <host>clickhouse-02</host>
              <port>9000</port>
          </replica>
          <replica>
              <host>clickhouse-04</host>
              <port>9000</port>
          </replica>
      </shard>
  </cluster_2S_2R>
</remote_servers>

Раздел <cluster_2S_2R></cluster_2S_2R> определяет структуру кластера и служит шаблоном для распределённых DDL-запросов — запросов, выполняемых по всему кластеру с помощью предложения ON CLUSTER.

Конфигурация Keeper

Раздел <ZooKeeper> сообщает ClickHouse, где запущен ClickHouse Keeper (или ZooKeeper). Поскольку мы используем кластер ClickHouse Keeper, необходимо указать каждый узел <node> кластера, задав его hostname и номер порта с помощью тегов <host> и <port> соответственно.Настройка ClickHouse Keeper рассматривается на следующем шаге руководства.

<zookeeper>
    <node>
        <host>clickhouse-keeper-01</host>
        <port>9181</port>
    </node>
    <node>
        <host>clickhouse-keeper-02</host>
        <port>9181</port>
    </node>
    <node>
        <host>clickhouse-keeper-03</host>
        <port>9181</port>
    </node>
</zookeeper>

Хотя ClickHouse Keeper можно запускать на том же сервере, что и ClickHouse Server, для производственных сред мы настоятельно рекомендуем запускать ClickHouse Keeper на выделенных узлах.

Настройка макросов

Кроме того, раздел <macros> используется для определения подстановок параметров для реплицированных таблиц. Они перечислены в system.macros и позволяют использовать подстановки вида {shard} и {replica} в запросах.

<macros>
   <shard>01</shard>
   <replica>01</replica>
</macros>

Конфигурация пользователя

Теперь внесите следующие изменения в каждый пустой файл конфигурации users.xml, расположенный по пути fs/volumes/clickhouse-{}/etc/clickhouse-server/users.d:

/users.d/users.xml

<?xml version="1.0"?>
<clickhouse replace="true">
    <profiles>
        <default>
            <max_memory_usage>10000000000</max_memory_usage>
            <use_uncompressed_cache>0</use_uncompressed_cache>
            <load_balancing>in_order</load_balancing>
            <log_queries>1</log_queries>
        </default>
    </profiles>
    <users>
        <default>
            <access_management>1</access_management>
            <profile>default</profile>
            <networks>
                <ip>::/0</ip>
            </networks>
            <quota>default</quota>
            <access_management>1</access_management>
            <named_collection_control>1</named_collection_control>
            <show_named_collections>1</show_named_collections>
            <show_named_collections_secrets>1</show_named_collections_secrets>
        </default>
    </users>
    <quotas>
        <default>
            <interval>
                <duration>3600</duration>
                <queries>0</queries>
                <errors>0</errors>
                <result_rows>0</result_rows>
                <read_rows>0</read_rows>
                <execution_time>0</execution_time>
            </interval>
        </default>
    </quotas>
</clickhouse>

В этом примере пользователь по умолчанию настроен без пароля для простоты. На практике такой подход не рекомендуется.

В этом примере файл users.xml одинаков на всех узлах кластера.

Настройка ClickHouse Keeper

Далее вы настроите ClickHouse Keeper, который используется для координации работы.

Настройка Keeper

Чтобы репликация работала, необходимо развернуть и настроить кластер ClickHouse Keeper. ClickHouse Keeper обеспечивает систему координации для репликации данных, выступая в качестве замены ZooKeeper, который также можно использовать. Однако рекомендуется использовать ClickHouse Keeper, так как он обеспечивает более строгие гарантии и надежность, а также потребляет меньше ресурсов, чем ZooKeeper. Для Высокой доступности и сохранения кворума рекомендуется запускать как минимум три узла ClickHouse Keeper.

ClickHouse Keeper может работать на любом узле кластера вместе с ClickHouse, однако рекомендуется запускать его на выделенном узле, что позволяет масштабировать кластер ClickHouse Keeper и управлять им независимо от кластера базы данных.

Создайте файлы keeper_config.xml для каждого узла ClickHouse Keeper, выполнив следующую команду из корневой папки примера:

for i in {01..03}; do
  touch fs/volumes/clickhouse-keeper-${i}/etc/clickhouse-keeper/keeper_config.xml
done

Измените пустые файлы конфигурации, созданные в каждом каталоге узла fs/volumes/clickhouse-keeper-{}/etc/clickhouse-keeper. Выделенные ниже строки нужно изменить для каждого узла:

/clickhouse-keeper/keeper_config.xml

<clickhouse replace="true">
    <logger>
        <level>information</level>
        <log>/var/log/clickhouse-keeper/clickhouse-keeper.log</log>
        <errorlog>/var/log/clickhouse-keeper/clickhouse-keeper.err.log</errorlog>
        <size>1000M</size>
        <count>3</count>
    </logger>
    <listen_host>0.0.0.0</listen_host>
    <keeper_server>
        <tcp_port>9181</tcp_port>
        <server_id>1</server_id>
        <log_storage_path>/var/lib/clickhouse/coordination/log</log_storage_path>
        <snapshot_storage_path>/var/lib/clickhouse/coordination/snapshots</snapshot_storage_path>
        <coordination_settings>
            <operation_timeout_ms>10000</operation_timeout_ms>
            <session_timeout_ms>30000</session_timeout_ms>
            <raft_logs_level>information</raft_logs_level>
        </coordination_settings>
        <raft_configuration>
            <server>
                <id>1</id>
                <hostname>clickhouse-keeper-01</hostname>
                <port>9234</port>
            </server>
            <server>
                <id>2</id>
                <hostname>clickhouse-keeper-02</hostname>
                <port>9234</port>
            </server>
            <server>
                <id>3</id>
                <hostname>clickhouse-keeper-03</hostname>
                <port>9234</port>
            </server>
        </raft_configuration>
    </keeper_server>
</clickhouse>

Каталог	Файл
`fs/volumes/clickhouse-keeper-01/etc/clickhouse-keeper`	`keeper_config.xml`
`fs/volumes/clickhouse-keeper-02/etc/clickhouse-keeper`	`keeper_config.xml`
`fs/volumes/clickhouse-keeper-03/etc/clickhouse-keeper`	`keeper_config.xml`

Каждый файл конфигурации должен содержать следующую уникальную конфигурацию (показана ниже). Используемый server_id должен быть уникальным для соответствующего узла ClickHouse Keeper в кластере и совпадать с <id> сервера, заданным в разделе <raft_configuration>. tcp_port — порт, используемый клиентами ClickHouse Keeper.

<tcp_port>9181</tcp_port>
<server_id>{id}</server_id>

Следующий раздел используется для настройки серверов, которые участвуют в кворуме алгоритма консенсуса Raft:

<raft_configuration>
    <server>
        <id>1</id>
        <hostname>clickhouse-keeper-01</hostname>
        <!-- TCP-порт для связи между узлами ClickHouse Keeper -->
        <port>9234</port>
    </server>
    <server>
        <id>2</id>
        <hostname>clickhouse-keeper-02</hostname>
        <port>9234</port>
    </server>
    <server>
        <id>3</id>
        <hostname>clickhouse-keeper-03</hostname>
        <port>9234</port>
    </server>
</raft_configuration>

ClickHouse Cloud упрощает администрированиеClickHouse Cloud снимает операционную нагрузку, связанную с управлением сегментами и репликами. Платформа автоматически обеспечивает высокую доступность, репликацию и масштабирование. Вычислительные ресурсы и хранилище разделены и масштабируются по мере необходимости без ручной настройки и постоянного обслуживания.Подробнее

Проверка настройки

Убедитесь, что на вашей машине запущен Docker. Запустите кластер командой docker-compose up из корня каталога cluster_2S_2R:

docker-compose up -d

Вы должны увидеть, как Docker начинает загружать образы ClickHouse и Keeper, а затем запускать контейнеры:

[+] Running 8/8
 ✔ Network   cluster_2s_2r_default     Created
 ✔ Container clickhouse-keeper-03      Started
 ✔ Container clickhouse-keeper-02      Started
 ✔ Container clickhouse-keeper-01      Started
 ✔ Container clickhouse-01             Started
 ✔ Container clickhouse-02             Started
 ✔ Container clickhouse-04             Started
 ✔ Container clickhouse-03             Started

Чтобы проверить, что кластер запущен, подключитесь к любому из узлов и выполните следующий запрос. Ниже показана команда для подключения к первому узлу:

# Подключитесь к любому узлу
docker exec -it clickhouse-01 clickhouse-client

Если всё прошло успешно, вы увидите приглашение клиента ClickHouse:

cluster_2S_2R node 1 :)

Выполните следующий запрос, чтобы проверить, какие топологии кластеров определены для каких хостов:

Query

SELECT 
    cluster,
    shard_num,
    replica_num,
    host_name,
    port
FROM system.clusters;

Response

   ┌─cluster───────┬─shard_num─┬─replica_num─┬─host_name─────┬─port─┐
│ cluster_2S_2R │         1 │           1 │ clickhouse-01 │ 9000 │
│ cluster_2S_2R │         1 │           2 │ clickhouse-03 │ 9000 │
│ cluster_2S_2R │         2 │           1 │ clickhouse-02 │ 9000 │
│ cluster_2S_2R │         2 │           2 │ clickhouse-04 │ 9000 │
│ default       │         1 │           1 │ localhost     │ 9000 │
   └───────────────┴───────────┴─────────────┴───────────────┴──────┘

Выполните следующий запрос, чтобы проверить состояние кластера ClickHouse Keeper:

Query

SELECT *
FROM system.zookeeper
WHERE path IN ('/', '/clickhouse')

Response

   ┌─name───────┬─value─┬─path────────┐
1. │ task_queue │       │ /clickhouse │
2. │ sessions   │       │ /clickhouse │
3. │ keeper     │       │ /           │
4. │ clickhouse │       │ /           │
   └────────────┴───────┴─────────────┘

Команда mntr также часто используется, чтобы убедиться, что ClickHouse Keeper запущен, и получить информацию о состоянии и ролях трёх узлов Keeper. В конфигурации, используемой в этом примере, вместе работают три узла. Они выберут leader, а остальные узлы будут followers.Команда mntr предоставляет информацию о производительности, а также о том, является ли конкретный узел follower или leader.

Возможно, вам потребуется установить netcat, чтобы отправить команду mntr в Keeper. Информацию о загрузке см. на странице nmap.org.

Выполните приведённую ниже команду в оболочке на clickhouse-keeper-01, clickhouse-keeper-02 и clickhouse-keeper-03, чтобы проверить состояние каждого узла Keeper. Команда для clickhouse-keeper-01 показана ниже:

docker exec -it clickhouse-keeper-01  /bin/sh -c 'echo mntr | nc 127.0.0.1 9181'

Ниже приведён пример ответа от узла-реплики:

Response

zk_version      v23.3.1.2823-testing-46e85357ce2da2a99f56ee83a079e892d7ec3726
zk_avg_latency  0
zk_max_latency  0
zk_min_latency  0
zk_packets_received     0
zk_packets_sent 0
zk_num_alive_connections        0
zk_outstanding_requests 0
zk_server_state follower
zk_znode_count  6
zk_watch_count  0
zk_ephemerals_count     0
zk_approximate_data_size        1271
zk_key_arena_size       4096
zk_latest_snapshot_size 0
zk_open_file_descriptor_count   46
zk_max_file_descriptor_count    18446744073709551615

Ниже приведён пример ответа от узла-лидера:

Response

zk_version      v23.3.1.2823-testing-46e85357ce2da2a99f56ee83a079e892d7ec3726
zk_avg_latency  0
zk_max_latency  0
zk_min_latency  0
zk_packets_received     0
zk_packets_sent 0
zk_num_alive_connections        0
zk_outstanding_requests 0
zk_server_state leader
zk_znode_count  6
zk_watch_count  0
zk_ephemerals_count     0
zk_approximate_data_size        1271
zk_key_arena_size       4096
zk_latest_snapshot_size 0
zk_open_file_descriptor_count   48
zk_max_file_descriptor_count    18446744073709551615
zk_followers    2
zk_synced_followers     2

Итак, вы успешно настроили кластер ClickHouse с двумя сегментами и двумя репликами. На следующем шаге вы создадите в кластере таблицу.

Создайте базу данных

Теперь, когда вы убедились, что cluster настроен правильно и работает, вам предстоит заново создать ту же таблицу, что использовалась в руководстве по примеру набора данных UK property prices. Она состоит примерно из 30 миллионов строк с ценами сделок с недвижимым имуществом в Англии и Уэльсе с 1995 года.Подключитесь к клиенту каждого хоста, выполнив по одной из следующих команд в отдельных вкладках или окнах терминала:

docker exec -it clickhouse-01 clickhouse-client
docker exec -it clickhouse-02 clickhouse-client
docker exec -it clickhouse-03 clickhouse-client
docker exec -it clickhouse-04 clickhouse-client

Вы можете выполнить приведённый ниже запрос в clickhouse-client на каждом узле, чтобы убедиться, что, кроме баз данных по умолчанию, другие базы данных ещё не созданы:

Query

SHOW DATABASES;

Response

   ┌─name───────────────┐
1. │ INFORMATION_SCHEMA │
2. │ default            │
3. │ information_schema │
4. │ system             │
   └────────────────────┘

В клиенте clickhouse-01 выполните следующий распределённый DDL-запрос, используя предложение ON CLUSTER, чтобы создать новую базу данных uk:

CREATE DATABASE IF NOT EXISTS uk 
ON CLUSTER cluster_2S_2R;

Вы можете снова выполнить тот же запрос, что и раньше, из клиента на каждом узле, чтобы убедиться, что база данных была создана во всём кластере, хотя запрос выполнялся только с clickhouse-01:

SHOW DATABASES;

   ┌─name───────────────┐
│ INFORMATION_SCHEMA │
│ default            │
│ information_schema │
│ system             │
│ uk                 │
   └────────────────────┘

Создайте таблицу в кластере

Теперь, когда база данных создана, создайте таблицу с репликацией.Выполните следующий запрос с любого клиентского хоста:

CREATE TABLE IF NOT EXISTS uk.uk_price_paid_local
ON CLUSTER cluster_2S_2R
(
    price UInt32,
    date Date,
    postcode1 LowCardinality(String),
    postcode2 LowCardinality(String),
    type Enum8('terraced' = 1, 'semi-detached' = 2, 'detached' = 3, 'flat' = 4, 'other' = 0),
    is_new UInt8,
    duration Enum8('freehold' = 1, 'leasehold' = 2, 'unknown' = 0),
    addr1 String,
    addr2 String,
    street LowCardinality(String),
    locality LowCardinality(String),
    town LowCardinality(String),
    district LowCardinality(String),
    county LowCardinality(String)
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}')
ORDER BY (postcode1, postcode2, addr1, addr2);

Обратите внимание, что он идентичен запросу, использованному в исходном операторе CREATE в руководстве по примеру набора данных о ценах на недвижимость в Великобритании, за исключением предложения ON CLUSTER и использования движка ReplicatedMergeTree.Предложение ON CLUSTER предназначено для распределённого выполнения DDL-запросов (языка определения данных), таких как CREATE, DROP, ALTER и RENAME, и гарантирует, что эти изменения схемы будут применены ко всем узлам кластера.Движок ReplicatedMergeTree работает так же, как обычный движок таблицы MergeTree, но при этом также реплицирует данные. Для него нужно указать два параметра:

zoo_path: Путь в Keeper/ZooKeeper к метаданным таблицы.
replica_name: Имя реплики таблицы.

Параметр zoo_path можно задать произвольно, однако рекомендуется использовать префикс

/clickhouse/tables/{shard}/{database}/{table}

где:

{database} и {table} будут подставлены автоматически.
{shard} и {replica} — это макросы, которые были определены ранее в файле config.xml на каждом узле ClickHouse.

Вы можете выполнить приведённый ниже запрос из клиента на каждом узле, чтобы убедиться, что таблица создана во всём кластере:

Query

SHOW TABLES IN uk;

Response

   ┌─name────────────────┐
1. │ uk_price_paid_local │
   └─────────────────────┘

Вставка данных в distributed таблицу

Чтобы вставить данные в таблицу, ON CLUSTER использовать нельзя, так как это предложение не применяется к DML-запросам (языку манипулирования данными), таким как INSERT, UPDATE и DELETE. Для вставки данных необходимо использовать движок таблицы Distributed. Как вы узнали из руководства по настройке кластера с 2 сегментами и 1 репликой, distributed таблицы — это таблицы, которые имеют доступ к сегментам, расположенным на разных хостах, и определяются с помощью движка таблицы Distributed. Distributed таблица выступает интерфейсом для всех сегментов в кластере.С любого из клиентских хостов выполните следующий запрос, чтобы создать distributed таблицу на основе существующей реплицируемой таблицы, которую мы создали на предыдущем шаге:

CREATE TABLE IF NOT EXISTS uk.uk_price_paid_distributed
ON CLUSTER cluster_2S_2R
ENGINE = Distributed('cluster_2S_2R', 'uk', 'uk_price_paid_local', rand());

Теперь на каждом хосте в базе данных uk будут отображаться следующие таблицы:

   ┌─name──────────────────────┐
1. │ uk_price_paid_distributed │
2. │ uk_price_paid_local       │
   └───────────────────────────┘

Данные можно вставить в таблицу uk_price_paid_distributed с любого из клиентских хостов, выполнив следующий запрос:

INSERT INTO uk.uk_price_paid_distributed
SELECT
    toUInt32(price_string) AS price,
    parseDateTimeBestEffortUS(time) AS date,
    splitByChar(' ', postcode)[1] AS postcode1,
    splitByChar(' ', postcode)[2] AS postcode2,
    transform(a, ['T', 'S', 'D', 'F', 'O'], ['terraced', 'semi-detached', 'detached', 'flat', 'other']) AS type,
    b = 'Y' AS is_new,
    transform(c, ['F', 'L', 'U'], ['freehold', 'leasehold', 'unknown']) AS duration,
    addr1,
    addr2,
    street,
    locality,
    town,
    district,
    county
FROM url(
    'http://prod1.publicdata.landregistry.gov.uk.s3-website-eu-west-1.amazonaws.com/pp-complete.csv',
    'CSV',
    'uuid_string String,
    price_string String,
    time String,
    postcode String,
    a String,
    b String,
    c String,
    addr1 String,
    addr2 String,
    street String,
    locality String,
    town String,
    district String,
    county String,
    d String,
    e String'
) SETTINGS max_http_get_redirects=10;

Выполните следующий запрос, чтобы убедиться, что вставленные данные равномерно распределились по узлам нашего кластера:

SELECT count(*)
FROM uk.uk_price_paid_distributed;

SELECT count(*) FROM uk.uk_price_paid_local;

   ┌──count()─┐
1. │ 30212555 │ -- 30,21 миллиона
   └──────────┘

   ┌──count()─┐
1. │ 15105983 │ -- 15,11 миллиона
   └──────────┘

Заключение

Преимущество этой топологии кластера с 2 сегментами и 2 репликами в том, что она обеспечивает и масштабируемость, и отказоустойчивость. Данные распределяются по отдельным хостам, что снижает требования к хранилищу и операциям ввода-вывода на каждом узле, а запросы обрабатываются параллельно в обоих сегментах, повышая производительность и эффективность использования памяти. Что особенно важно, кластер может пережить потерю одного узла и продолжать обслуживать запросы без перерыва, поскольку для каждого сегмента на другом узле доступна резервная реплика. Основной недостаток этой топологии кластера — повышенные требования к хранилищу: по сравнению с конфигурацией без реплик ей требуется вдвое больше места, поскольку каждый сегмент дублируется. Кроме того, хотя кластер может пережить отказ одного узла, одновременная потеря двух узлов может сделать его неработоспособным — в зависимости от того, какие именно узлы выйдут из строя и как распределены сегменты. Эта топология представляет собой компромисс между доступностью и стоимостью, поэтому хорошо подходит для производственных сред, где требуется определенный уровень отказоустойчивости, но без затрат, связанных с более высокими коэффициентами репликации. Чтобы узнать, как ClickHouse Cloud обрабатывает запросы, обеспечивая одновременно масштабируемость и отказоустойчивость, см. раздел “Параллельные реплики”.

​Предварительные требования

​Настройка структуры каталогов и тестовой среды

​Настройка узлов ClickHouse

​Настройка сервера

​Сеть и логирование

​Конфигурация кластера

​Конфигурация Keeper

​Настройка макросов

​Конфигурация пользователя

​Настройка ClickHouse Keeper

​Настройка Keeper

​Проверка настройки

​Создайте базу данных

​Создайте таблицу в кластере

​Вставка данных в distributed таблицу

​Заключение

Предварительные требования

Настройка структуры каталогов и тестовой среды

Настройка узлов ClickHouse

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

Сеть и логирование

Конфигурация кластера

Конфигурация Keeper

Настройка макросов

Конфигурация пользователя

Настройка ClickHouse Keeper

Настройка Keeper

Проверка настройки

Создайте базу данных

Создайте таблицу в кластере

Вставка данных в distributed таблицу

Заключение