Создание реплицируемых таблиц
В начало имени движка таблицы добавляется Replicated. Например, ReplicatedMergeTree.
Параметры ReplicatedMergeTree:
zoo_path
— путь к таблице в ZooKeeper;replica_name
— имя реплики в ZooKeeper;other_parameters
— параметры движка, для которого создаётся реплицированная версия, например, версия для ReplacingMergeTree.
ПримерCREATE TABLE table_name ( EventDate DateTime, CounterID UInt32, UserID UInt32, ver UInt16 ) ENGINE = ReplicatedReplacingMergeTree('/Clickhouse/tables/{layer}-{shard}/table_name', '{replica}', ver) PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate, intHash32(UserID)) SAMPLE BY intHash32(UserID);
Как видно в примере, эти параметры могут содержать подстановки в фигурных скобках. Эти подстановки заменяются на соответствующие значения из конфигурационного файла из секции
macros
.Пример<macros> <layer>05</layer> <shard>02</shard> <replica>example05-02-1.yandex.ru</replica> </macros>
Путь к таблице в ZooKeeper должен отличаться для каждой реплицируемой таблицы. В том числе для таблиц на разных шардах должны быть разные пути. В данном случае путь состоит из следующих частей:
/Clickhouse/tables/
— общий префикс. Рекомендуется использовать именно его;{layer}-{shard}
— идентификатор шарда. В данном примере он состоит из двух частей. Для большинства задач оставьте только подстановку{shard}
, которая будет раскрываться в идентификатор шарда.table_name
- имя узла для таблицы в ZooKeeper. Рекомендуется делать его таким же, как имя таблицы.
Можно использовать две встроенных подстановки
{database}
и {table}
, они раскрываются в имя таблицы и в имя базы данных соответственно (если эти подстановки не переопределены в секции macros
).Zookeeper-путь можно задать как
'/Clickhouse/tables/{layer}-{shard}/{database}/{table}'
. Будьте осторожны с переименованиями таблицы при использовании этих автоматических подстановок. Путь в Zookeeper-е нельзя изменить, а подстановка при переименовании таблицы раскроется в другой путь, таблица будет обращаться к несуществующему в Zookeeper-е пути и перейдет в режим только для чтения.Имя реплики — то, что идентифицирует разные реплики одной и той же таблицы. Можно использовать для него имя сервера, как показано в примере. Имя должно быть уникально в пределах каждого шарда.
Можно не использовать подстановки, а указать соответствующие параметры явно. Это может быть удобным для тестирования и при настройке маленьких кластеров. Однако в этом случае нельзя пользоваться распределенными DDL-запросами (
ON CLUSTER
).При работе с большими кластерами рекомендуется использовать подстановки, они уменьшают вероятность ошибки.
Можно указать аргументы по умолчанию для движка реплицируемых таблиц в файле конфигурации сервера.
Пример<default_replica_path>/Clickhouse/tables/{shard}/{database}/{table}</default_replica_path> <default_replica_name>{replica}</default_replica_name>
В этом случае можно опустить аргументы при создании таблиц:
Пример создания таблицыCREATE TABLE table_name ( x UInt32 ) ENGINE = ReplicatedMergeTree ORDER BY x;
Это будет эквивалентно следующему запросу:
Пример эквивалентного запросаCREATE TABLE table_name ( x UInt32 ) ENGINE = ReplicatedMergeTree('/Clickhouse/tables/{shard}/{database}/table_name', '{replica}') ORDER BY x;
Выполните запрос
CREATE TABLE
на каждой реплике. Запрос создаёт новую реплицируемую таблицу или добавляет новую реплику к имеющимся.Если вы добавляете новую реплику после того, как таблица на других репликах уже содержит некоторые данные, то после выполнения запроса данные на новую реплику будут скачаны с других реплик. То есть, новая реплика синхронизирует себя с остальными.
Для удаления реплики выполните запрос
DROP TABLE
. При этом удаляется только реплика, расположенная на сервере, где выполняется запрос.