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

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

Параметры движка
  • zoo_path — путь в ZooKeeper. Один и тот же путь в ZooKeeper соответствует одной и той же базе данных.
  • shard_name — имя сегмента. Реплики базы данных группируются в сегменты по shard_name.
  • replica_name — имя реплики. Имена реплик должны различаться у всех реплик одного и того же сегмента.
Параметры можно не указывать; в этом случае отсутствующие параметры будут заменены значениями по умолчанию. Если zoo_path содержит макрос {uuid}, необходимо указать UUID явно или добавить ON CLUSTER к оператору CREATE, чтобы все реплики использовали один и тот же UUID для этой базы данных. Для таблиц ReplicatedMergeTree, если аргументы не указаны, используются аргументы по умолчанию: /clickhouse/tables/{uuid}/{shard} и {replica}. Их можно изменить в настройках сервера default_replica_path и default_replica_name. Макрос {uuid} раскрывается в UUID таблицы, а {shard} и {replica} — в значения из конфигурации сервера, а не из аргументов движка базы данных. Однако в будущем появится возможность использовать shard_name и replica_name базы данных Replicated. Также поддерживается использование вспомогательного кластера ZooKeeper для хранения метаданных базы данных Replicated вместо кластера ZooKeeper по умолчанию. Для создания базы данных Replicated со вспомогательным кластером ZooKeeper можно использовать следующий SQL:

Особенности и рекомендации

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 содержит кластер с именем, совпадающим с именем базы данных Replicated, который состоит из всех реплик этой базы данных. Этот кластер автоматически обновляется при создании/удалении реплик и может использоваться для таблиц Distributed. При создании новой реплики базы данных эта реплика создает таблицы самостоятельно. Если реплика была недоступна долгое время и отстала от журнала репликации, она сверяет свои локальные метаданные с текущими метаданными в ZooKeeper, перемещает лишние таблицы с данными в отдельную нереплицируемую базу данных (чтобы случайно не удалить ничего лишнего), создает недостающие таблицы и обновляет имена таблиц, если они были переименованы. Данные реплицируются на уровне ReplicatedMergeTree, то есть если сама таблица не реплицируется, данные реплицироваться не будут (база данных отвечает только за метаданные). Запросы ALTER TABLE FREEZE|ATTACH|FETCH|DROP|DROP DETACHED|DETACH PARTITION|PART разрешены, но не реплицируются. Движок базы данных только добавит/загрузит/удалит партицию/часть на текущей реплике. Однако если сама таблица использует движок таблицы Replicated, то после применения ATTACH данные будут реплицированы. Если вам нужно только настроить кластер без поддержки репликации таблиц, обратитесь к возможности Cluster Discovery.

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

Создадим кластер из трёх хостов:
Создание базы данных в кластере с неявно заданными параметрами:
Выполним DDL-запрос:
Отображение системной таблицы:
Создание distributed таблицы и вставка данных:
Добавление реплики на ещё один хост:
Добавление реплики на ещё один хост, если в zoo_path используется макрос {uuid}:
Конфигурация кластера будет выглядеть следующим образом:
Distributed таблица также будет получать данные с нового хоста:

Настройки

Поддерживаются следующие настройки: Значения по умолчанию могут быть переопределены в файле конфигурации
Последнее изменение 2 июля 2026 г.