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

Репликация для отказоустойчивости

Описание​

В этой архитектуре настроены пять серверов. Два из них используются для хранения копий данных. Оставшиеся три сервера используются для координации репликации данных. На этом примере мы создадим базу данных и таблицу, которые будут реплицироваться на обеих узлах данных, используя движок таблиц ReplicatedMergeTree.

Уровень: Базовый​

Terminology​

Replica​

A copy of data. ClickHouse always has at least one copy of your data, and so the minimum number of replicas is one. This is an important detail, you may not be used to counting the original copy of your data as a replica, but that is the term used in ClickHouse code and documentation. Adding a second replica of your data provides fault tolerance.

Shard​

A subset of data. ClickHouse always has at least one shard for your data, so if you do not split the data across multiple servers, your data will be stored in one shard. Sharding data across multiple servers can be used to divide the load if you exceed the capacity of a single server. The destination server is determined by the sharding key, and is defined when you create the distributed table. The sharding key can be random or as an output of a hash function. The deployment examples involving sharding will use rand() as the sharding key, and will provide further information on when and how to choose a different sharding key.

Distributed coordination​

ClickHouse Keeper provides the coordination system for data replication and distributed DDL queries execution. ClickHouse Keeper is compatible with Apache ZooKeeper.

Среда​

Диаграмма архитектуры​

УзелОписание
clickhouse-01Данные
clickhouse-02Данные
clickhouse-keeper-01Распределенная координация
clickhouse-keeper-02Распределенная координация
clickhouse-keeper-03Распределенная координация
примечание

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

Установка​

Установите сервер и клиент ClickHouse на два сервера clickhouse-01 и clickhouse-02, следуя инструкциям для вашего типа архива (.deb, .rpm, .tar.gz и т.д.).

Установите ClickHouse Keeper на три сервера clickhouse-keeper-01, clickhouse-keeper-02 и clickhouse-keeper-03, следуя инструкциям для вашего типа архива (.deb, .rpm, .tar.gz и т.д.).

Редактирование файлов конфигурации​

best practices

When configuring ClickHouse Server by adding or editing configuration files you should:

  • Add files to /etc/clickhouse-server/config.d/ directory
  • Add files to /etc/clickhouse-server/users.d/ directory
  • Leave the /etc/clickhouse-server/config.xml file as it is
  • Leave the /etc/clickhouse-server/users.xml file as it is

Конфигурация clickhouse-01​

Для clickhouse-01 имеется пять файлов конфигурации. Вы можете выбрать, чтобы объединить эти файлы в один, но для ясности в документации может быть проще рассмотреть их отдельно. Когда вы будете просматривать файлы конфигурации, вы увидите, что большая часть конфигурации одинакова для clickhouse-01 и clickhouse-02; различия будут выделены.

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

Эти значения можно настраивать по своему усмотрению. Этот пример конфигурации дает вам:

  • отладочный лог, который будет обновляться после 1000M три раза
  • имя, отображаемое при подключении с помощью clickhouse-client, - cluster_1S_2R node 1
  • ClickHouse будет слушать на сетевом интерфейсе IPV4 на портах 8123 и 9000.

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

Макросы shard и replica упрощают сложность распределенного DDL. Значения, настроенные для них, автоматически заменяются в ваших DDL-запросах, что упрощает ваш DDL. Макросы для этой конфигурации указывают номер шард и реплики для каждого узла. В этом примере с 1 шард и 2 репликами, макрос реплики — replica_1 на clickhouse-01 и replica_2 на clickhouse-02. Макрос шард имеет значение 1 как для clickhouse-01, так и для clickhouse-02, поскольку существует только один шард.

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

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

  • Раздел remote_servers в XML указывает на каждый из кластеров в среде. Атрибут replace=true заменяет пример удаленных серверов в конфигурации ClickHouse по умолчанию на конфигурацию remote_server, указанную в этом файле. Без этого атрибута удаленные серверы в этом файле добавлялись бы к списку примеров в конфигурации по умолчанию.
  • В этом примере есть один кластер с именем cluster_1S_2R.
  • Создается секрет для кластера с именем cluster_1S_2R со значением mysecretphrase. Секрет делится между всеми удаленными серверами в среде, чтобы гарантировать, что правильные серверы объединены.
  • В кластере cluster_1S_2R имеется один шард и две реплики. Обратите внимание на диаграмму архитектуры в начале этого документа и сравните ее с определением shard в приведенном ниже XML. Определение шард содержит две реплики. Хост и порт для каждой реплики указаны. Одна реплика хранится на clickhouse-01, а другая — на clickhouse-02.
  • Внутренняя репликация для шард установлена на true. Каждый шард может иметь параметр internal_replication, определенный в конфигурационном файле. Если этот параметр установлен на true, операция записи выбирает первую здоровую реплику и записывает данные в нее.

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

Этот файл конфигурации use-keeper.xml настраивает ClickHouse Server для использования ClickHouse Keeper для координации репликации и распределенного DDL. Этот файл указывает, что ClickHouse Server должен использовать Keeper на узлах clickhouse-keeper-01 - 03 на порту 9181, и файл одинаковый для clickhouse-01 и clickhouse-02.

Конфигурация clickhouse-02​

Поскольку конфигурация очень похожа на clickhouse-01 и clickhouse-02, здесь будут указаны только отличия.

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

Этот файл одинаков на clickhouse-01 и clickhouse-02, за исключением display_name.

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

Конфигурация макросов отличается между clickhouse-01 и clickhouse-02. replica установлена в 02 на этом узле.

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

Этот файл одинаков на clickhouse-01 и clickhouse-02.

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

Этот файл одинаков на clickhouse-01 и clickhouse-02.

Конфигурация clickhouse-keeper-01​

best practices

When configuring ClickHouse Keeper by editing configuration files you should:

  • Backup the /etc/clickhouse-keeper/keeper_config.xml
  • Edit the /etc/clickhouse-keeper/keeper_config.xml file

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

примечание

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

Конфигурация clickhouse-keeper-02​

Между clickhouse-keeper-01 и clickhouse-keeper-02 есть только одно различие. server_id установлен на 2 на этом узле.

Конфигурация clickhouse-keeper-03​

Между clickhouse-keeper-01 и clickhouse-keeper-03 есть только одно различие. server_id установлен на 3 на этом узле.

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

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

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

Убедитесь, что ClickHouse Keeper работает​

Команда mntr используется для проверки, что ClickHouse Keeper работает, и для получения информации о состоянии взаимоотношений между тремя узлами Keeper. В конфигурации, используемой в этом примере, три узла работают вместе. Узлы выберут лидера, а остальные узлы станут последователями. Команда mntr предоставляет информацию, связанную с производительностью, и о том, является ли конкретный узел последователем или лидером.

подсказка

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

Проверьте функциональность кластера ClickHouse​

Подключитесь к узлу clickhouse-01 с помощью clickhouse client в одной оболочке, и подключитесь к узлу clickhouse-02 с помощью clickhouse client в другой оболочке.

  1. Создайте базу данных на сконфигурированном кластере
  1. Создайте таблицу в базе данных, используя движок таблиц ReplicatedMergeTree
  1. Вставьте данные на одном узле и запросите их на другом узле
  1. Запросите таблицу на узле clickhouse-02
  1. Вставьте данные на другом узле и запросите их на узле clickhouse-01

  1. Остановите один узел сервера ClickHouse Остановите один из узлов сервера ClickHouse, выполнив команду операционной системы, аналогичную команде, использованной для запуска узла. Если вы использовали systemctl start для запуска узла, используйте systemctl stop для его остановки.

  2. Вставьте еще данные на работающем узле

Выберите данные:

  1. Перезапустите остановленный узел и выберите данные также оттуда