Реплицированный

Движок основан на атомарном движке. Он поддерживает репликацию метаданных через журнал DDL, который записывается в ZooKeeper и выполняется на всех репликах для данной базы данных.

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

Создание базы данных

Параметры движка

• zoo_path — путь ZooKeeper. Один и тот же путь ZooKeeper соответствует одной и той же базе данных.
• shard_name — имя шарда. Реплики базы данных группируются по шардом shard_name.
• replica_name — имя реплики. Имена реплик должны быть различными для всех реплик одного и того же шарда.

Для таблиц ReplicatedMergeTree, если аргументы не указаны, используются значения по умолчанию: /clickhouse/tables/{uuid}/{shard} и {replica}. Эти значения можно изменить в настройках сервера default_replica_path и default_replica_name. Макрос {uuid} развертывается в uuid таблицы, {shard} и {replica} разворачиваются в значения из конфигурации сервера, а не из аргументов движка базы данных. Но в будущем будет возможность использовать shard_name и replica_name реплицированной базы данных.

Специфика и рекомендации

Запросы DDL с базой данных Replicated работают аналогично запросам ON CLUSTER, но с незначительными отличиями.

Во-первых, DDL-запрос пытается выполниться на инициаторе (хосте, который первоначально получил запрос от пользователя). Если запрос не выполнен, пользователь сразу получает ошибку, другие хосты не пытаются выполнить его. Если запрос успешно завершен на инициаторе, все другие хосты автоматически повторят попытку до тех пор, пока не завершат его. Инициатор будет стараться дождаться завершения запроса на других хостах (не более distributed_ddl_task_timeout) и вернет таблицу с состояниями выполнения запросов на каждом хосте.

Поведение в случае ошибок регулируется настройкой distributed_ddl_output_mode, для базы данных Replicated лучше установить его на null_status_on_timeout — т.е. если некоторым хостам не хватило времени для выполнения запроса за distributed_ddl_task_timeout, не выбрасывать исключение, а показывать статус NULL для них в таблице.

Системная таблица system.clusters содержит кластер с именем, аналогичным реплицированной базе данных, который состоит из всех реплик базы данных. Этот кластер обновляется автоматически при создании/удалении реплик и может использоваться для таблиц Distributed.

При создании новой реплики базы данных, эта реплика создает таблицы самостоятельно. Если реплика была недоступна в течение долгого времени и отстает от журнала репликации — она проверяет свои локальные метаданные с текущими метаданными в ZooKeeper, перемещает лишние таблицы с данными в отдельную нереплицированную базу данных (чтобы случайно не удалить ничего лишнего), создает отсутствующие таблицы, обновляет имена таблиц, если они были переименованы. Данные реплицируются на уровне ReplicatedMergeTree, т.е. если таблица не реплицирована, данные не будут реплицированы (база данных отвечает только за метаданные).

Запросы ALTER TABLE FREEZE|ATTACH|FETCH|DROP|DROP DETACHED|DETACH PARTITION|PART разрешены, но не реплицируемы. Движок базы данных будет только добавлять/извлекать/удалять партицию/часть на текущей реплике. Однако, если сама таблица использует движок таблиц Replicated, данные будут реплицированы после использования ATTACH.

В случае, если вам нужно только настроить кластер без поддержания репликации таблиц, ознакомьтесь с функцией Cluster Discovery.

Пример использования

Создание кластера с тремя хостами:

Запуск DDL-запроса:

Отображение системной таблицы:

Создание распределенной таблицы и вставка данных:

Добавление реплики на одном из хостов:

Конфигурация кластера будет выглядеть следующим образом:

Распределенная таблица также получит данные с нового хоста: