ALTER
Большинство запросов ALTER TABLE
изменяют настройки или данные таблицы:
Модификатор |
---|
COLUMN |
PARTITION |
DELETE |
UPDATE |
ORDER BY |
INDEX |
CONSTRAINT |
TTL |
STATISTICS |
APPLY DELETED MASK |
Большинство запросов ALTER TABLE
поддерживаются только для *MergeTree, Merge и Distributed таблиц.
Эти операторы ALTER
управляют представлениями:
Оператор | Описание |
---|---|
ALTER TABLE ... MODIFY QUERY | Изменяет структуру материализованного представления. |
ALTER LIVE VIEW | Обновляет live-представление. |
Эти операторы ALTER
изменяют сущности, связанные с контролем доступа на основе ролей:
Оператор |
---|
USER |
ROLE |
QUOTA |
ROW POLICY |
SETTINGS PROFILE |
Оператор | Описание |
---|---|
ALTER TABLE ... MODIFY COMMENT | Добавляет, изменяет или удаляет комментарии в таблице, независимо от того, были ли они установлены ранее или нет. |
ALTER NAMED COLLECTION | Изменяет Именованные коллекции. |
Мутации
Запросы ALTER
, предназначенные для изменения данных таблицы, реализуются с помощью механизма, называемого "мутациями", наиболее заметными из которых являются ALTER TABLE ... DELETE и ALTER TABLE ... UPDATE. Они являются асинхронными фоновыми процессами, похожими на слияния в таблицах MergeTree, которые производят новые "мутированные" версии частей.
Для таблиц *MergeTree
мутации выполняются путем перезаписи целых частей данных.
Атомарность отсутствует — части заменяются мутированными частями, как только они готовы, и запрос SELECT
, который начал выполняться в процессе мутации, будет видеть данные из частей, которые уже были мутированы, вместе с данными из частей, которые еще не были мутированы.
Мутации полностью упорядочены по порядку их создания и применяются к каждой части в этом порядке. Мутации также частично упорядочены с запросами INSERT INTO
: данные, которые были вставлены в таблицу до подачи мутации, будут мутированы, а данные, вставленные после этого, не будут мутированы. Обратите внимание, что мутации не блокируют вставки.
Запрос на мутацию возвращается немедленно после добавления записи мутации (в случае реплицируемых таблиц — в ZooKeeper, для нереплицируемых таблиц — в файловую систему). Сама мутация выполняется асинхронно с использованием настроек системного профиля. Для отслеживания процесса мутаций вы можете использовать таблицу system.mutations
. Мутация, которая была успешно подана, продолжит выполняться даже если серверы ClickHouse будут перезапущены. Нет возможности отменить мутацию после ее подачи, но если мутация зависла по какой-либо причине, ее можно отменить с помощью запроса KILL MUTATION
.
Записи для завершенных мутаций не удаляются сразу (количество хранимых записей определяется параметром движка хранения finished_mutations_to_keep
). Более старые записи мутаций удаляются.
Синхронность запросов ALTER
Для нереплицируемых таблиц все запросы ALTER
выполняются синхронно. Для реплицируемых таблиц запрос просто добавляет инструкции для соответствующих действий в ZooKeeper
, а сами действия выполняются как можно скорее. Тем не менее, запрос может ждать завершения этих действий на всех репликах.
Для запросов ALTER
, которые создают мутации (например: включая, но не ограничиваясь UPDATE
, DELETE
, MATERIALIZE INDEX
, MATERIALIZE PROJECTION
, MATERIALIZE COLUMN
, APPLY DELETED MASK
, CLEAR STATISTIC
, MATERIALIZE STATISTIC
), синхронность определяется настройкой mutations_sync.
Для других запросов ALTER
, которые изменяют только метаданные, вы можете использовать настройку alter_sync для организации ожидания.
Вы можете указать, как долго (в секундах) ждать, пока неактивные реплики выполнят все запросы ALTER
, с помощью настройки replication_wait_for_inactive_replica_timeout.
Для всех запросов ALTER
, если alter_sync = 2
и некоторые реплики не активны более времени, указанного в настройке replication_wait_for_inactive_replica_timeout
, то генерируется исключение UNFINISHED
.