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

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

Описание​

В этой архитектуре сконфигурировано пять серверов. Два из них используются для размещения копий данных. Остальные три сервера используются для координации репликации данных. В этом примере мы создадим базу данных и таблицу, которые будут реплицированы на обоих узлах данных, используя движок таблиц 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; различия будут выделены.

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

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

  • журнал отладки, который будет перезаписываться на 1000 М трижды
  • имя, отображаемое при подключении с помощью 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 заменяет примеры remote_servers в конфигурации по умолчанию ClickHouse на конфигурацию remote_server, указанную в этом файле. Без этого атрибута remote-серверы в этом файле будут добавлены к списку образцов в конфигурации по умолчанию.
  • В этом примере существует один кластер под именем 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 в одном shell, а к узлу clickhouse-02 с помощью clickhouse client в другом shell.

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

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

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

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

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