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

Описание

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

Уровень: Основной

Терминология

Реплика

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

Шард

Подмножество данных. ClickHouse всегда имеет хотя бы один шард для ваших данных, поэтому если вы не разделяете данные на несколько серверов, ваши данные будут храниться в одном шарде. Шардирование данных на несколько серверов можно использовать для распределения нагрузки, если вы превышаете мощность одного сервера. Целевой сервер определяется по шифрующему ключу, который задаётся при создании распределенной таблицы. Шифрующий ключ может быть случайным или являться результатом хеш-функции. Примеры развертывания, связанные с шардированием, будут использовать rand() в качестве шифрующего ключа и предоставят дополнительную информацию о том, когда и как выбрать другой шифрующий ключ.

Распределённая координация

ClickHouse Keeper предоставляет систему координации для репликации данных и выполнения распределённых DDL запросов. ClickHouse Keeper совместим с 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

При настройке ClickHouse Server путем добавления или редактирования конфигурационных файлов, вы должны:

• Добавлять файлы в директорию /etc/clickhouse-server/config.d/
• Добавлять файлы в директорию /etc/clickhouse-server/users.d/
• Оставить файл /etc/clickhouse-server/config.xml без изменений
• Оставить файл /etc/clickhouse-server/users.xml без изменений

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

При настройке ClickHouse Keeper путём редактирования конфигурационных файлов вы должны:

• Создать резервную копию файла /etc/clickhouse-keeper/keeper_config.xml
• Отредактировать файл /etc/clickhouse-keeper/keeper_config.xml

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 — server_id равный 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. Создайте базу данных в вышеуказанном кластере

2. Создайте таблицу в базе данных с использованием движка таблицы ReplicatedMergeTree

3. Вставьте данные на одном узле и запросите их на другом узле

4. Запросите таблицу на узле clickhouse-02

5. Вставьте данные на другом узле и запросите их на узле clickhouse-01

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

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

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

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