Replicated
Движок основан на Atomic движке. Он поддерживает репликацию метаданных через 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 разрешены, но не реплицируются. Движок базы данных только добавит/получит/удалит партицию/часть для текущей реплики. Однако, если сама таблица использует реплицированный движок таблицы, то данные будут реплицироваться после использования ATTACH.
Если вам нужно только настроить кластер без поддержки репликации таблиц, обратитесь к функции Cluster Discovery.
Пример использования
Создание кластера с тремя хостами:
Запуск DDL-запроса:
Просмотр системной таблицы:
Создание распределенной таблицы и вставка данных:
Добавление реплики на одном из хостов:
Конфигурация кластера будет выглядеть следующим образом:
Распределенная таблица также получит данные с нового хоста: