В ClickHouse Cloud репликация настраивается автоматически. Создавайте таблицы без добавления аргументов. Например, в приведенном ниже тексте замените:на:
- ReplicatedSummingMergeTree
- ReplicatedCoalescingMergeTree
- ReplicatedVersionedCollapsingMergeTree
- ReplicatedCollapsingMergeTree
- ReplicatedGraphiteMergeTree
- ReplicatedMergeTree
- ReplicatedReplacingMergeTree
- ReplicatedAggregatingMergeTree
INSERT и ALTER реплицируются (подробнее см. в документации по ALTER.
Запросы CREATE, DROP, ATTACH, DETACH и RENAME выполняются на одном сервере и не реплицируются:
- Запрос
CREATE TABLEсоздает новую реплицируемую таблицу на сервере, где он выполняется. Если эта таблица уже существует на других серверах, добавляется новая реплика. - Запрос
DROP TABLEудаляет реплику, расположенную на сервере, где он выполняется. - Запрос
RENAMEпереименовывает таблицу на одной из реплик. Иными словами, реплицируемые таблицы могут иметь разные имена на разных репликах.
Не пренебрегайте настройками безопасности. ClickHouse поддерживает схему ACL
digest подсистемы безопасности ZooKeeper.SELECT, поскольку репликация не влияет на производительность SELECT, и такие запросы выполняются так же быстро, как и для нереплицируемых таблиц. При запросах к распределённым реплицируемым таблицам поведение ClickHouse определяется настройками max_replica_delay_for_distributed_queries и fallback_to_stale_replicas_for_distributed_queries.
Для каждого запроса INSERT в ZooKeeper через несколько транзакций добавляется примерно десять записей. (Точнее, это происходит для каждого вставляемого блока данных; запрос INSERT содержит один блок или по одному блоку на каждые max_insert_block_size = 1048576 строк.) Из-за этого задержка для INSERT немного выше, чем для нереплицируемых таблиц. Но если следовать рекомендациям и вставлять данные батчами, выполняя не более одного INSERT в секунду, это не создаёт проблем. Весь кластер ClickHouse, координируемый одним кластером ZooKeeper, суммарно поддерживает несколько сотен INSERT в секунду. При этом пропускная способность вставки данных (количество строк в секунду) остаётся такой же высокой, как и для нереплицируемых данных.
Для очень больших кластеров можно использовать разные кластеры ZooKeeper для разных сегментов. Однако, по нашему опыту, в этом не было необходимости даже для продакшн-кластеров примерно из 300 серверов.
Репликация асинхронная и мультимастерная. Запросы INSERT (как и ALTER) можно отправлять на любой доступный сервер. Данные вставляются на том сервере, где выполняется запрос, а затем копируются на остальные серверы. Поскольку репликация асинхронная, недавно вставленные данные появляются на других репликах с некоторой задержкой. Если часть реплик недоступна, данные будут записаны, когда они снова станут доступны. Если реплика доступна, задержка равна времени, необходимому для передачи блока сжатых данных по сети. Количество потоков, выполняющих фоновые задачи для реплицируемых таблиц, можно задать с помощью настройки background_schedule_pool_size.
Движок ReplicatedMergeTree использует отдельный пул потоков для загрузки данных репликации. Размер этого пула ограничен настройкой background_fetches_pool_size, которую можно изменить при перезапуске сервера.
По умолчанию запрос INSERT ждёт подтверждения записи данных только от одной реплики. Если данные были успешно записаны только на одну реплику, а сервер с этой репликой перестанет существовать, сохранённые данные будут потеряны. Чтобы получать подтверждение записи данных от нескольких реплик, используйте параметр insert_quorum.
Каждый блок данных записывается атомарно. Запрос INSERT разбивается на блоки размером до max_insert_block_size = 1048576 строк. Иными словами, если запрос INSERT содержит менее 1048576 строк, он выполняется атомарно.
Для блоков данных выполняется дедупликация. Если один и тот же блок данных записывается несколько раз (блоки данных одного размера, содержащие одинаковые строки в одном и том же порядке), он записывается только один раз. Это сделано на случай сбоев сети, когда клиентское приложение не знает, были ли данные записаны в БД, и поэтому запрос INSERT можно просто повторить. Не имеет значения, на какую реплику были отправлены INSERT с одинаковыми данными. Операции INSERT идемпотентны. Параметры дедупликации задаются настройками сервера merge_tree.
Во время репликации по сети передаются только исходные данные для вставки. Дальнейшее преобразование данных (слияние) координируется и выполняется на всех репликах одинаково. Это минимизирует сетевой трафик, а значит, репликация хорошо работает, когда реплики находятся в разных датацентрах. (Обратите внимание, что дублирование данных между разными датацентрами — основная цель репликации.)
Можно иметь любое количество реплик одних и тех же данных. По нашему опыту, относительно надёжным и удобным решением для продакшн может быть двойная репликация, при которой каждый сервер использует RAID-5 или RAID-6 (а в некоторых случаях RAID-10).
Система отслеживает синхронность данных на репликах и способна восстанавливаться после сбоев. Переключение при отказе выполняется автоматически (при небольших различиях в данных) или полуавтоматически (когда данные различаются слишком сильно, что может указывать на ошибку конфигурации).
Создание таблиц с репликацией
В ClickHouse Cloud репликация выполняется автоматически.Создавайте таблицы с помощью
MergeTree без указания аргументов репликации. Система автоматически преобразует MergeTree в SharedMergeTree, чтобы обеспечить репликацию и распределение данных.Не используйте ReplicatedMergeTree и не указывайте параметры репликации, так как репликацией управляет платформа.Параметры Replicated*MergeTree
Пример:
{}. Подставляемые значения берутся из раздела macros файла конфигурации.
Пример:
/clickhouse/tables/ — общий префикс. Мы рекомендуем использовать именно его.
{shard} будет подставлен как идентификатор сегмента.
table_name — это имя узла таблицы в ClickHouse Keeper. Лучше сделать его таким же, как имя таблицы. Оно задаётся явно, потому что, в отличие от имени таблицы, не меняется после запроса RENAME.
ПОДСКАЗКА: перед table_name также можно добавить имя базы данных. Например, db_name.table_name
Можно использовать две встроенные подстановки {database} и {table}; они разворачиваются соответственно в имя таблицы и имя базы данных (если только эти макросы не определены в разделе macros). Таким образом, путь в ZooKeeper можно указать как '/clickhouse/tables/{shard}/{database}/{table}'.
Будьте осторожны с переименованием таблиц при использовании этих встроенных подстановок. Путь в ClickHouse Keeper изменить нельзя, и при переименовании таблицы макросы будут разворачиваться в другой путь, таблица начнёт ссылаться на путь, которого нет в ClickHouse Keeper, и перейдёт в режим только для чтения.
Имя реплики позволяет различать разные реплики одной и той же таблицы. Для этого можно использовать имя сервера, как в примере. Имя должно быть уникальным только в пределах каждого сегмента.
Вы можете явно задать параметры вместо использования подстановок. Это может быть удобно для тестирования и настройки небольших кластеров. Однако в этом случае вы не сможете использовать распределённые DDL-запросы (ON CLUSTER).
При работе с большими кластерами мы рекомендуем использовать подстановки, поскольку они снижают вероятность ошибок.
Вы можете указать аргументы по умолчанию для движка таблицы Replicated в файле конфигурации сервера. Например:
CREATE TABLE на каждой реплике. Этот запрос создает новую реплицируемую таблицу или добавляет новую реплику к уже существующей.
Если вы добавляете новую реплику после того, как таблица уже содержит данные на других репликах, после выполнения запроса эти данные будут скопированы с других реплик на новую. Иными словами, новая реплика синхронизируется с остальными.
Чтобы удалить реплику, выполните DROP TABLE. Однако будет удалена только одна реплика — та, которая находится на сервере, где вы выполняете запрос.
Восстановление после сбоев
INSERT или при взаимодействии с ClickHouse Keeper возникает ошибка, генерируется исключение.
После подключения к ClickHouse Keeper система проверяет, соответствует ли набор данных в локальной файловой системе ожидаемому набору данных (эта информация хранится в ClickHouse Keeper). Если обнаруживаются небольшие расхождения, система устраняет их, синхронизируя данные с репликами.
Если система обнаруживает поврежденные части данных (с неправильными размерами файлов) или нераспознанные части (части, записанные в файловую систему, но не зарегистрированные в ClickHouse Keeper), она перемещает их в подкаталог detached (они не удаляются). Все отсутствующие части копируются с реплик.
Обратите внимание, что ClickHouse не выполняет никаких деструктивных действий, таких как автоматическое удаление большого объема данных.
При запуске сервера (или при установлении нового сеанса с ClickHouse Keeper) система проверяет только количество и размеры всех файлов. Если размеры файлов совпадают, но где-то в середине были изменены байты, это обнаруживается не сразу, а только при попытке прочитать данные для SELECT-запроса. Запрос генерирует исключение о несовпадении контрольной суммы или размера сжатого блока. В этом случае части данных добавляются в очередь проверки и при необходимости копируются с реплик.
Если локальный набор данных слишком сильно отличается от ожидаемого, срабатывает защитный механизм. Сервер записывает это в журнал и отказывается запускаться. Причина в том, что такая ситуация может указывать на ошибку конфигурации, например если реплика в одном сегменте была по ошибке настроена как реплика в другом сегменте. Однако пороговые значения для этого механизма установлены довольно низко, и такая ситуация может возникнуть и при обычном восстановлении после сбоя. В этом случае данные восстанавливаются полуавтоматически — путем “нажатия кнопки”.
Чтобы начать восстановление, создайте узел /path_to_table/replica_name/flags/force_restore_data в ClickHouse Keeper с любым содержимым или выполните команду для восстановления всех реплицируемых таблиц:
Восстановление после полной потери данных
- Установите ClickHouse на сервер. Если вы используете подстановки, правильно задайте их в config-файле, содержащем идентификаторы сегмента и реплики.
- Если у вас были нереплицируемые таблицы, данные которых нужно вручную скопировать на серверы, скопируйте их с реплики (из каталога
/var/lib/clickhouse/data/db_name/table_name/). - Скопируйте с реплики определения таблиц, расположенные в
/var/lib/clickhouse/metadata/. Если идентификатор сегмента или реплики явно указан в определениях таблиц, исправьте его так, чтобы он соответствовал этой реплике. (Либо запустите сервер и выполните все запросыATTACH TABLE, которые должны были находиться в .sql-файлах в/var/lib/clickhouse/metadata/.) - Чтобы начать восстановление, создайте узел ClickHouse Keeper
/path_to_table/replica_name/flags/force_restore_dataс любым содержимым или выполните команду для восстановления всех реплицируемых таблиц:sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data
/path_to_table/replica_name), а затем снова создать реплику, как описано в разделе “Создание реплицируемых таблиц”.
Во время восстановления ограничения на пропускную способность сети отсутствуют. Учитывайте это, если одновременно восстанавливаете много реплик.
Преобразование из MergeTree в ReplicatedMergeTree
MergeTree мы используем для обозначения всех движков таблиц семейства MergeTree family, аналогично ReplicatedMergeTree.
Если у вас есть таблица MergeTree, для которой репликация была настроена вручную, её можно преобразовать в реплицируемую таблицу. Это может понадобиться, если вы уже накопили большой объём данных в таблице MergeTree и теперь хотите включить репликацию.
Оператор ATTACH TABLE … AS REPLICATED позволяет присоединить отсоединённую таблицу MergeTree как ReplicatedMergeTree.
Таблица MergeTree может быть автоматически преобразована при перезапуске сервера, если в каталоге данных таблицы (/store/xxx/xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/ для базы данных Atomic) установлен флаг convert_to_replicated.
Создайте пустой файл convert_to_replicated, и при следующем перезапуске сервера таблица будет загружена как реплицированная.
Этот запрос можно использовать, чтобы получить путь к данным таблицы. Если у таблицы несколько путей к данным, нужно использовать первый из них.
default_replica_path и default_replica_name.
Чтобы создать такую таблицу на других репликах, потребуется явно указать её путь в первом аргументе движка ReplicatedMergeTree. Чтобы узнать этот путь, можно использовать следующий запрос.
ReplicatedMergeTree со старым именем.
Переместите данные из старой таблицы в подкаталог detached внутри каталога с данными новой таблицы (/var/lib/clickhouse/data/db_name/table_name/).
Затем выполните ALTER TABLE ATTACH PARTITION на одной из реплик, чтобы добавить эти части в рабочий набор.
Преобразование ReplicatedMergeTree в MergeTree
ReplicatedMergeTree как MergeTree на одном сервере.
Есть и другой способ, но он требует перезапуска сервера. Создайте таблицу MergeTree с другим именем. Переместите все данные из каталога с данными таблицы ReplicatedMergeTree в каталог данных новой таблицы. Затем удалите таблицу ReplicatedMergeTree и перезапустите сервер.
Если вы хотите избавиться от таблицы ReplicatedMergeTree, не запуская сервер:
- Удалите соответствующий файл
.sqlв каталоге метаданных (/var/lib/clickhouse/metadata/). - Удалите соответствующий путь в ClickHouse Keeper (
/path_to_table/replica_name).
MergeTree, переместить данные в её каталог, а затем перезапустить сервер.