Создание базы данных
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:
Особенности и рекомендации
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.
Пример использования
zoo_path используется макрос {uuid}:
Настройки
| Setting | Default | Description |
|---|---|---|
max_broken_tables_ratio | 1 | Не выполнять автоматическое восстановление реплики, если доля устаревших таблиц среди всех таблиц превышает это значение |
max_replication_lag_to_enqueue | 50 | Реплика сгенерирует исключение при попытке выполнить запрос, если её отставание репликации превышает это значение |
wait_entry_commited_timeout_sec | 3600 | Реплики попытаются отменить запрос, если тайм-аут превышен, но хост-инициатор ещё не выполнил его |
collection_name | Имя коллекции, определённой в конфигурации сервера, где указана вся информация для аутентификации кластера | |
check_consistency | true | Проверять согласованность локальных метаданных и метаданных в Keeper; при обнаружении несогласованности восстанавливать реплику |
max_retries_before_automatic_recovery | 10 | Максимальное число попыток выполнить элемент очереди перед тем, как пометить реплику как потерянную и восстановить её из снимка (0 означает бесконечное число попыток) |
allow_skipping_old_temporary_tables_ddls_of_refreshable_materialized_views | false | Если включено, при обработке DDL-запросов в базах данных Replicated по возможности пропускаются создание и обмен DDL-запросами для временных таблиц refreshable materialized view |
logs_to_keep | 1000 | Число записей журнала, которое по умолчанию хранится в ZooKeeper для базы данных Replicated. |
default_replica_path | /clickhouse/databases/{uuid} | Путь к базе данных в ZooKeeper. Используется при создании базы данных, если аргументы не указаны. |
default_replica_shard_name | {shard} | Имя сегмента реплики в базе данных. Используется при создании базы данных, если аргументы не указаны. |
default_replica_name | {replica} | Имя реплики в базе данных. Используется при создании базы данных, если аргументы не указаны. |
internal_replication | false | Определяет, будет ли distributed таблица, созданная в кластере этой базы данных Replicated, отправлять данные на одну из реплик (внутренняя репликация означает, что реплики кластера реплицируют данные самостоятельно) или на все реплики (отсутствие внутренней репликации означает, что distributed таблица будет отправлять вставленные данные на все реплики) |