Перейти к основному содержимому
Перейти к основному содержимому

Масштабирование

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

ClickHouse Keeper предоставляет систему координации для репликации данных и выполнения распределённых запросов DDL. ClickHouse Keeper совместим с Apache ZooKeeper. Эта конфигурация включает ClickHouse Keeper на порту 9181. Выделенная строка указывает, что этот экземпляр Keeper имеет server_id равный 1. Это единственное отличие в файле enable-keeper.xml между тремя серверами. chnode2 будет иметь server_id равный 2, а chnode3 будет иметь server_id равный 3. Раздел конфигурации raft одинаков на всех трех серверах, и он выделен ниже, чтобы показать вам соотношение между server_id и экземпляром server в конфигурации raft.

примечание

Если по какой-либо причине узел Keeper заменяется или восстанавливается, не повторяйте существующий server_id. Например, если узел Keeper с server_id равным 2 восстанавливается, дайте ему server_id равный 4 или выше.

Конфигурация макросов​

Макросы shard и replica уменьшают сложность распределённых DDL. Сконфигурированные значения автоматически подставляются в ваши запросы DDL, что упрощает ваши DDL. Макросы для этой конфигурации указывают номер шардов и реплики для каждого узла. В этом примере с 2 шардом и 1 репликой макрос реплики — replica_1 на обоих узлах chnode1 и chnode2, поскольку есть только одна реплика. Макрос шардов равен 1 на chnode1 и 2 на chnode2.

Конфигурация репликации и шардирования​

Начинаем сверху:

  • Раздел remote_servers в XML указывает каждый из кластеров в среде. Атрибут replace=true заменяет пример remote_servers в стандартной конфигурации ClickHouse на конфигурацию remote_servers, указанную в этом файле. Без этого атрибута удалённые серверы в этом файле будут добавлены к списку примеров в стандартной конфигурации.
  • В этом примере есть один кластер с именем cluster_2S_1R.
  • Создается секрет для кластера с именем cluster_2S_1R со значением mysecretphrase. Секрет разделяется на всех удалённых серверах в среде, чтобы обеспечить правильное соединение серверов.
  • Кластер cluster_2S_1R имеет два шарда, и каждый из этих шардов имеет одну реплику. Посмотрите на схему архитектуры в начале этого документа и сравните её с двумя определениями shard в XML ниже. В каждом определении шардов есть одна реплика. Хост и порт для этой реплики указаны. Реплика для первого шарада в конфигурации хранится на chnode1, а реплика для второго шарада в конфигурации хранится на chnode2.
  • Внутренняя репликация для шардов установлена в истинное значение. Каждый шард может иметь параметр internal_replication, определяемый в файле конфигурации. Если этот параметр установлен в истинное значение, операция записи выбирает первую здоровую реплику и записывает данные в неё.

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

В вышеупомянутых файлах был настроен ClickHouse Keeper. Этот файл конфигурации use-keeper.xml настраивает ClickHouse Server на использование ClickHouse Keeper для координации репликации и распределенных DDL. Этот файл указывает, что ClickHouse Server должен использовать Keeper на узлах chnode1 - 3 на порту 9181, и файл одинаков на chnode1 и chnode2.

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

Так как конфигурация очень похожа на chnode1 и chnode2, здесь будут указаны только отличия.

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

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

Этот файл содержит одно из двух отличий между chnode1 и chnode2. В конфигурации Keeper server_id установлен в 2.

Конфигурация макросов​

Конфигурация макросов имеет одно из отличий между chnode1 и chnode2. shard установлен в 2 на этом узле.

Конфигурация репликации и шардирования​

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

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

Так как chnode3 не хранит данные и используется только как ClickHouse Keeper для обеспечения третьего узла в кворуме, chnode3 имеет только два файла конфигурации: один для настройки сети и логирования, и один для настройки ClickHouse Keeper.

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

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

Тестирование​

  1. Подключитесь к chnode1 и проверьте, что кластер cluster_2S_1R, настроенный выше, существует
  1. Создайте базу данных в кластере
  1. Создайте таблицу с движком таблицы MergeTree в кластере.
примечание

Не нужно указывать параметры в движке таблицы, так как они будут автоматически определены в зависимости от наших макросов.

  1. Подключитесь к chnode1 и вставьте строку
  1. Подключитесь к chnode2 и вставьте строку
  1. Подключитесь к любому узлу, chnode1 или chnode2, и вы увидите только строку, которая была вставлена в эту таблицу на этом узле. например, на chnode2
  1. Создайте распределенную таблицу для запроса обоих шардов на обоих узлах. (В этом примере функция rand() установлена как ключ шардирования, чтобы она случайным образом распределяла каждую вставку)
  1. Подключитесь к любому из узлов chnode1 или chnode2 и выполните запрос к распределённой таблице, чтобы увидеть обе строки.

Дополнительная информация о:​