ALTER TABLE modifient les paramètres ou les données d’une table :
La plupart des requêtes
ALTER TABLE ne sont prises en charge que pour les tables *MergeTree, Merge et Distributed.ALTER s’appliquent aux vues :
| Statement | Description |
|---|---|
| ALTER TABLE … MODIFY QUERY | Modifie la structure d’une vue matérialisée. |
ALTER modifient les entités liées au contrôle d’accès basé sur les rôles :
| Statement | Description |
|---|---|
| ALTER TABLE … MODIFY COMMENT | Ajoute, modifie ou supprime les commentaires de la table, qu’un commentaire ait déjà été défini ou non. |
| ALTER NAMED COLLECTION | Modifie les collections nommées. |
Mutations
ALTER destinées à modifier les données des tables sont mises en œuvre au moyen d’un mécanisme appelé « mutations », notamment ALTER TABLE … DELETE et ALTER TABLE … UPDATE. Il s’agit de processus asynchrones en arrière-plan, similaires aux fusions dans les tables MergeTree, qui produisent de nouvelles versions « mutées » des parts.
Pour les tables *MergeTree, les mutations s’exécutent en réécrivant des data parts entières.
Il n’y a pas d’atomicité — les parts sont remplacées par leurs versions mutées dès qu’elles sont prêtes, et une requête SELECT dont l’exécution a commencé pendant une mutation verra à la fois des données provenant de parts déjà mutées et de parts qui ne l’ont pas encore été.
Les mutations sont totalement ordonnées selon leur ordre de création et sont appliquées à chaque part dans cet ordre. Les mutations sont également partiellement ordonnées par rapport aux requêtes INSERT INTO : les données insérées dans la table avant la soumission de la mutation seront mutées, et celles insérées après ne le seront pas. Notez que les mutations ne bloquent en aucune façon les insertions.
Une requête de mutation renvoie immédiatement après l’ajout de l’entrée de mutation (dans le cas des tables répliquées, dans ZooKeeper ; pour les tables non répliquées, dans le système de fichiers). La mutation elle-même s’exécute de manière asynchrone en utilisant les paramètres du profil système. Pour suivre la progression des mutations, vous pouvez utiliser la table system.mutations. Une mutation soumise avec succès continuera à s’exécuter même si les serveurs ClickHouse sont redémarrés. Il n’existe aucun moyen de revenir sur une mutation une fois qu’elle a été soumise, mais si elle est bloquée pour une raison quelconque, elle peut être annulée avec la requête KILL MUTATION.
Les entrées des mutations terminées ne sont pas supprimées immédiatement (le nombre d’entrées conservées est déterminé par le paramètre du moteur de stockage finished_mutations_to_keep). Les entrées de mutation plus anciennes sont supprimées.
Exécution synchrone des requêtes ALTER
ALTER sont exécutées de manière synchrone. Pour les tables répliquées, la requête se contente d’ajouter dans ZooKeeper les instructions correspondant aux actions appropriées, et ces actions sont ensuite exécutées dès que possible. Toutefois, la requête peut attendre que ces actions soient terminées sur toutes les répliques.
Pour les requêtes ALTER qui créent des mutations (par ex. : UPDATE, DELETE, MATERIALIZE INDEX, MATERIALIZE PROJECTION, MATERIALIZE COLUMN, APPLY DELETED MASK, APPLY PATCHES, CLEAR STATISTIC, MATERIALIZE STATISTIC, entre autres), le caractère synchrone est défini par le paramètre mutations_sync.
Pour les autres requêtes ALTER qui modifient uniquement les métadonnées, vous pouvez utiliser le paramètre alter_sync pour définir l’attente.
Vous pouvez spécifier, avec le paramètre replication_wait_for_inactive_replica_timeout, combien de temps (en secondes) attendre que les répliques inactives exécutent toutes les requêtes ALTER.
Pour toutes les requêtes
ALTER, si alter_sync = 2 et que certaines répliques restent inactives au-delà de la durée spécifiée par le paramètre replication_wait_for_inactive_replica_timeout, une exception UNFINISHED est levée.