Деплоймент кластера
Этот учебник предполагает, что вы уже настроили локальный сервер ClickHouse
Пройдя этот учебник, вы научитесь настраивать простой кластер ClickHouse. Он будет небольшим, но отказоустойчивым и масштабируемым. Затем мы используем один из примерных наборов данных, чтобы заполнить его данными и выполнить несколько демонстрационных запросов.
Деплоймент кластера
Этот кластер ClickHouse будет однородным кластером. Вот шаги:
- Установите сервер ClickHouse на всех машинах кластера
- Настройте конфигурации кластера в файлах конфигурации
- Создайте локальные таблицы на каждом экземпляре
- Создайте распределенную таблицу
Распределенная таблица является своего рода "представлением" локальных таблиц в кластере ClickHouse. Запрос SELECT из распределенной таблицы выполняется с использованием ресурсов всех шардов кластера. Вы можете указать конфигурации для нескольких кластеров и создать несколько распределенных таблиц, чтобы предоставить представления для разных кластеров.
Вот пример конфигурации для кластера с тремя шардом, с одной репликой на каждый:
Для дальнейшей демонстрации давайте создадим новую локальную таблицу с тем же запросом CREATE TABLE, который мы использовали для hits_v1 в учебнике по развертыванию на одном узле, но с другим именем таблицы:
Создание распределенной таблицы предоставляет представление в локальные таблицы кластера:
Распространенной практикой является создание аналогичных распределенных таблиц на всех машинах кластера. Это позволяет выполнять распределенные запросы на любой машине кластера. Также есть альтернативный вариант создать временную распределенную таблицу для данного запроса SELECT, используя remote табличную функцию.
Давайте выполните INSERT SELECT в распределенную таблицу, чтобы распространить таблицу на несколько серверов.
Как вы могли ожидать, вычислительно тяжелые запросы выполняются в N раз быстрее, если они используют 3 сервера вместо одного.
В данном случае мы используем кластер с 3 шардом, и каждый шард содержит одну реплику.
Для обеспечения отказоустойчивости в продуктивной среде мы рекомендуем, чтобы каждый шард содержал 2-3 реплики, распределенные между несколькими зонами доступности или дата-центрами (или, по крайней мере, стойками). Обратите внимание, что ClickHouse поддерживает неограниченное количество реплик.
Вот пример конфигурации для кластера из одного шардом, содержащего три реплики:
Для включения нативной репликации требуется ZooKeeper. ClickHouse заботится о согласованности данных на всех репликах и автоматически выполняет процедуру восстановления после сбоя. Рекомендуется развернуть кластер ZooKeeper на отдельных серверах (где не работают другие процессы, включая ClickHouse).
ZooKeeper не является строгим требованием: в некоторых простых случаях вы можете дублировать данные, записывая их во все реплики из кода вашего приложения. Этот подход не рекомендуется, так как в этом случае ClickHouse не сможет гарантировать согласованность данных на всех репликах. Таким образом, это становится обязанностью вашего приложения.
Местоположения ZooKeeper указываются в файле конфигурации:
Также нам необходимо установить макросы для идентификации каждого шарда и реплики, которые используются при создании таблицы:
Если в момент создания реплицированной таблицы нет реплик, создается новая первая реплика. Если уже существуют активные реплики, новая реплика клонирует данные из существующих. Вы можете сначала создать все реплицированные таблицы, а затем вставить данные в них. Другой вариант — создать некоторые реплики и добавить остальные после или во время вставки данных.
Здесь мы используем табличный движок ReplicatedMergeTree. В параметрах мы указываем путь ZooKeeper, содержащий идентификаторы шардов и реплик.
Репликация работает в режиме многомастершства. Данные могут быть загружены в любую реплику, и система затем автоматически синхронизирует их с другими экземплярами. Репликация асинхронна, поэтому в данный момент не все реплики могут содержать недавно вставленные данные. По меньшей мере одна реплика должна быть активной, чтобы обеспечить прием данных. Остальные синхронизируют данные и восстанавливают согласование после того, как снова станут активными. Обратите внимание, что этот подход позволяет снизить вероятность потери недавно вставленных данных.
