ALTER TABLE modifica configurações da tabela ou dados:
A maioria das consultas
ALTER TABLE é suportada apenas para tabelas *MergeTree, Merge e Distributed.ALTER manipulam views:
| Instrução | Descrição |
|---|---|
| ALTER TABLE … MODIFY QUERY | Modifica a estrutura de uma visão materializada. |
ALTER modificam entidades relacionadas ao Controle de Acesso Baseado em Funções:
| Instrução | Descrição |
|---|---|
| ALTER TABLE … MODIFY COMMENT | Adiciona, modifica ou remove comentários na tabela, independentemente de já terem sido definidos ou não. |
| ALTER NAMED COLLECTION | Modifica coleções nomeadas. |
Mutações
ALTER destinadas a manipular dados de tabelas são implementadas por meio de um mecanismo chamado “mutações”, principalmente ALTER TABLE … DELETE e ALTER TABLE … UPDATE. Elas são processos assíncronos em segundo plano, semelhantes às mesclagens em tabelas MergeTree, que produzem novas versões “mutadas” das partes.
Para tabelas *MergeTree, as mutações são executadas por reescrita de partes de dados inteiras.
Não há atomicidade — as partes são substituídas por partes mutadas assim que ficam prontas, e uma consulta SELECT iniciada durante uma mutação verá dados de partes que já foram mutadas junto com dados de partes que ainda não foram mutadas.
As mutações são totalmente ordenadas pela ordem de criação e são aplicadas a cada parte nessa ordem. As mutações também têm uma ordenação parcial em relação às consultas INSERT INTO: os dados inseridos na tabela antes de a mutação ser enviada serão mutados, e os dados inseridos depois disso não serão mutados. Observe que as mutações não bloqueiam inserts de forma alguma.
Uma consulta de mutação retorna imediatamente após a entrada da mutação ser adicionada (no caso de tabelas replicadas, ao ZooKeeper; no caso de tabelas não replicadas, ao sistema de arquivos). A mutação em si é executada de forma assíncrona usando as configurações do perfil do sistema. Para acompanhar o progresso das mutações, você pode usar a tabela system.mutations. Uma mutação enviada com sucesso continuará a ser executada mesmo que os servidores ClickHouse sejam reiniciados. Não há como reverter a mutação depois que ela é enviada, mas, se a mutação ficar travada por algum motivo, ela pode ser cancelada com a consulta KILL MUTATION.
As entradas de mutações concluídas não são excluídas imediatamente (o número de entradas preservadas é determinado pelo parâmetro do motor de armazenamento finished_mutations_to_keep). Entradas de mutação mais antigas são excluídas.
Sincronia das consultas ALTER
ALTER são executadas de forma síncrona. Para tabelas replicadas, a consulta apenas adiciona instruções para as ações apropriadas ao ZooKeeper, e as próprias ações são executadas assim que possível. No entanto, a consulta pode aguardar a conclusão dessas ações em todas as réplicas.
Para consultas ALTER que criam mutações (por exemplo, entre elas UPDATE, DELETE, MATERIALIZE INDEX, MATERIALIZE PROJECTION, MATERIALIZE COLUMN, APPLY DELETED MASK, APPLY PATCHES, CLEAR STATISTIC, MATERIALIZE STATISTIC), a sincronia é definida pela configuração mutations_sync.
Para outras consultas ALTER que apenas modificam os metadados, você pode usar a configuração alter_sync para configurar a espera.
Você pode especificar por quanto tempo (em segundos) aguardar que réplicas inativas executem todas as consultas ALTER com a configuração replication_wait_for_inactive_replica_timeout.
Para todas as consultas
ALTER, se alter_sync = 2 e algumas réplicas permanecerem inativas por mais tempo do que o especificado na configuração replication_wait_for_inactive_replica_timeout, uma exceção UNFINISHED será lançada.