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.