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

Движок основан на 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 запросы с реплицированной базой данных работают аналогично запросам ON CLUSTER, но с небольшими отличиями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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