Avec Instant ADD COLUMN, MariaDB propose une technique qui me permet d'ajouter de nouvelles colonnes en temps réel dans de grandes tables InnoDB, sans verrouillage notable ni interruption de service. L'algorithme INSTANT ne réécrit pas les données, mais se contente d'étendre Métadonnées et génère ainsi de nouvelles colonnes contenant des valeurs par défaut.
Points centraux
Les points clés suivants m'aident à évaluer rapidement les possibilités offertes par les opérations instantanées et à prendre les bonnes décisions pour les systèmes de production. Je résume les aspects les plus importants et les mets en relation avec les tâches d'administration courantes. À partir de l'interaction entre la version, la structure des tables et la stratégie DDL, j'en déduis des mesures concrètes. Cette liste sert de mémo succinct pour le quotidien Base de données Administration. Après cette présentation générale, j'aborderai plus en détail la mise en œuvre, les pièges à éviter et des exemples concrets.
- Temps d'arrêt optimiser : de nouvelles colonnes en quelques millisecondes, sans reconstruction ni opérations de copie.
- DDL en ligne Pour un contrôle sûr : spécifier explicitement ALGORITHM=INSTANT et LOCK=NONE.
- Version Remarque : 10.3 (dernière colonne uniquement) ; à partir de la version 10.4, positions flexibles et autres nouveautés.
- Métadonnées Au lieu des données : pas de réécriture physique, fournir les valeurs par défaut de manière logique.
- Mise à l'échelle simplifier : réduction du délai de réplication et déploiements planifiables.
Ces points ne prennent tout leur sens que lorsque je vérifie les compatibilités, telles que ROW_FORMAT ou les index spéciaux, et que je les valide lors de tests. Cela me permet de maîtriser les modifications apportées aux grandes tables et de rester performant même en cas de pics de charge. capable d'agir.
Pourquoi Instant ADD COLUMN modifie les règles du jeu
Autrefois, un classique signifiait ALTER TABLE ... ADD COLUMN souvent des opérations de copie qui durent des heures, des verrous qui bloquent le système et des ralentissements perceptibles Temps d'arrêt. Cela ne cadrait guère avec les versions agiles et les applications fonctionnant 24 h/24 et 7 j/7, pour lesquelles chaque fenêtre de maintenance coûte cher. Grâce à l'algorithme INSTANT, la charge de travail passe du niveau des données au niveau du catalogue, ce qui rend les modifications extrêmement rapides, même lorsqu'il s'agit de milliards de lignes. Je peux déployer de nouveaux attributs en production sans interrompre la charge en cours. Cela me donne la liberté de procéder à des itérations rapides et Release-Fréquence d'horloge.
D'un point de vue opérationnel, cela réduit les risques et les efforts de coordination, car je n'ai plus besoin de planifier de grands changements. Cette approche a un impact direct sur la réplication, les fenêtres de sauvegarde et le fonctionnement des applications. Là où, auparavant, une équipe coordonnait des interventions nocturnes, un simple changement rapide accompagné d’un plan de déploiement bien ficelé suffit souvent aujourd’hui. Cela me permet de tester plus rapidement les idées de produits et de les mettre en production. Ainsi, la maintenance des bases de données se transforme en Levier de croissance.
Voici comment fonctionne l'algorithme INSTANT en coulisses
Le principe est simple : InnoDB étend la description de la table et ajoute une entrée spécifique dans l'index cluster, au lieu d'accéder physiquement à chaque ligne. Les nouvelles colonnes existent ainsi au niveau logique, et lors de la lecture, le moteur renvoie soit la valeur par défaut, soit une valeur enregistrée Valeur. Cette modification prend un temps de l'ordre de O(1) par rapport au nombre d'enregistrements, car aucune page n'est réécrite. Les index secondaires restent inchangés, ce qui évite des opérations d'E/S supplémentaires. Je bénéficie ainsi de verrous très courts, d'un nombre minimal d'opérations d'E/S et d'un très faible Transactions.
Dès que j'inscris des données dans la nouvelle colonne, InnoDB enregistre ces valeurs comme d'habitude. Jusque-là, il ne s'agit que d'une extension virtuelle de la structure. C'est précisément pour cette raison que de nombreux schémas de production peuvent être étendus sans perturber le fonctionnement du système. Je tiens toutefois à souligner que certaines combinaisons de formats et de fonctionnalités peuvent empêcher l’utilisation d’Instant. Une vérification rapide au préalable m’évite des problèmes ultérieurs. Surprises.
Versions, formats et limites
Dans MariaDB 10.3, je ne peux ajouter la nouvelle colonne instantanément qu'à la fin de la table ; si je spécifie une position, l'opération utilise alors un algorithme plus lent. À partir de MariaDB 10.4, un format de données étendu permet des insertions à presque n'importe quel endroit, l'utilisation de la commande DROP COLUMN avec effet immédiat et la modification de l'ordre des colonnes. Certains formats de lignes sont toutefois incompatibles, tels que ROW_FORMAT=COMPRESSED, et les index spéciaux peuvent entraîner des restrictions. Je vérifie également si innodb_instant_alter_column_allowed limite son fonctionnement. Ce n'est que lorsque la version, le format et les variables correspondent que INSTANT me fournit le résultat escompté Avantages.
Une petite mise au point rapide permet de y voir plus clair : SELECT VERSION();, SHOW CREATE TABLE ...; et un ALTER TABLE ... ADD COLUMN ... ALGORITHM=INSTANT, LOCK=NONE; sur l'environnement de staging. Si je constate un message d'erreur, je bloque la mise en production et j'ajuste la conception ou les options. J'évite ainsi les reconstructions indésirables et les pics de charge qui en découlent. Cette étape préalable s'avère particulièrement utile avec des tables très volumineuses. Je préfère prendre cette décision en environnement de test plutôt que sous impression de production.
Les limites en détail : types de données, valeurs par défaut et cas particuliers
Pour qu'INSTANT fonctionne, les définitions de fraction doivent respecter certaines règles. La règle empirique suivante a fait ses preuves : des valeurs par défaut simples et constantes fonctionnent, mais ce n'est souvent pas le cas pour les expressions complexes. Je mets donc DEFAULT NULL ou une valeur littérale claire (nombre, chaîne de caractères), mais évite les appels de fonction tels que NOW(), UUID() ou des expressions dépendantes. Pour les types de type texte et de type « blob », des restrictions supplémentaires s'appliquent selon la version ; je ne me fie pas à mon intuition, mais je teste à l'aide d'un dump de staging réaliste.
Tous les types d'attributs ne se prêtent pas à un démarrage „ instantané “ : une colonne contenant AUTO_INCREMENT introduire, et en plus, tout de suite un Index unique les construire ou les intégrer directement dans un Clé étrangère L'utilisation de cette méthode permet de sortir rapidement du chemin « Instant ». Dans ce genre de cas, je décompose la modification en plusieurs étapes : d'abord la colonne (INSTANT), puis l'index/la contrainte (généralement INPLACE). Générées ou virtuel Je vérifie les colonnes séparément ; selon le format d'impression et le moteur utilisé, différents algorithmes sont appliqués. Le jeu de caractères et Collation Je le précise explicitement afin d'éviter toute surprise ultérieure lors des triages ou des comparaisons.
Voir aussi Changements de position dépendent de la version : dans la version 10.3, je dois forcer les colonnes à se trouver à la fin, tandis qu’à partir de la version 10.4, j’ai pratiquement carte blanche. Je fais néanmoins attention aux ORM et aux outils qui adressent les colonnes par position ordinale : dans ce cas, un simple déplacement sans copie des données peut déjà provoquer des erreurs logiques. Je planifie donc la position non seulement d'un point de vue technique, mais aussi en tenant compte du code de l'application.
Bonnes pratiques : mise en œuvre sécurisée
Je formule toujours les DDL de manière explicite afin d'éviter les solutions de repli ambiguës. Avec ALGORITHME=INSTANTANÉ et LOCK=NONE je force MariaDB à utiliser la variante rapide, sinon j'obtiens une contradiction manifeste. La colonne NOT NULL, je définis une valeur par défaut pertinente afin que les anciennes lignes soient logiquement correctes Valeurs fournir. Avant le déploiement, je mesure sur l'environnement de préproduction les latences, le comportement de réplication et la durée des verrous. De plus, je consigne soigneusement la modification dans le journal des modifications de la Base de données.
Des exemples concrets et utiles sont d'une grande aide dans la pratique : ALTER TABLE orders ADD COLUMN marketing_tag VARCHAR(40) DEFAULT '' NOT NULL ALGORITHM=INSTANT, LOCK=NONE;. Ou pour la version 10.4 et les versions ultérieures : ALTER TABLE users ADD COLUMN plan INT DEFAULT 0 NOT NULL AFTER status ALGORITHM=INSTANT, LOCK=NONE;. Dans les deux cas, je vérifie au préalable que les options de la table prennent en charge un ROW_FORMAT compatible. Pendant l'exécution, je surveille des indicateurs tels que « Threads_running » et « I/O ». Une fois la modification effectuée, je vérifie les requêtes qui utilisent immédiatement la nouvelle colonne utiliser.
Modèles de migration sécurisés avec backfill et index
Dans les environnements de production, j'utilise en deux étapes Modifications. Étape 1 : ajouter la colonne « instant », pour commencer NULL-compatible et avec une valeur par défaut claire. Étape 2 : mettre à jour l'application via un feature flag afin que les nouvelles écritures remplissent déjà la colonne, tandis que les anciennes entrées restent vides. Le Remblai je procède de manière asynchrone par petits lots, par exemple via un worker qui utilise UPDATE ... WHERE new_col IS NULL ORDER BY pk LIMIT N répète l'opération et insère des pauses entre les cycles. Cela permet de contrôler la charge.
Si j'ai besoin d'un index secondaire sur la nouvelle colonne, je le dissocie de l'ajout de colonne. La création de l'index se fait généralement INPLACE, mais cela prend un temps proportionnel au volume de données. Grâce à cette dissociation, j'évite que la modification rapide du schéma ne soit bloquée par de longues opérations d'indexation. Ce n'est qu'une fois le backfill terminé que j'effectue, si nécessaire, un NOT NULL-étape par étape – mais uniquement si l'algorithme le permet sans reconstruction. Pour les retours en arrière, il suffit souvent de désactiver le drapeau de fonctionnalité et de laisser la colonne inutilisée jusqu'à ce qu'un retour en arrière propre soit prévu.
Performances et réplication
Les opérations instantanées réduisent la charge de travail que doivent supporter les répliques, car elles évitent les opérations de copie massives. Cela diminue le risque de décalage perceptible et allège la charge des processus s'exécutant en parallèle Requêtes. Dans les environnements comportant plusieurs sites ou des configurations en cascade, cela joue un rôle déterminant pour les objectifs RTO/RPO. Qui dispose de solutions adaptées Topologies de réplication permet de transmettre les modifications de manière ciblée et de structurer clairement les retours en arrière. Ainsi, le système reste opérationnel même en cas de pics de trafic réactif.
Je tiens néanmoins compte des formats des fichiers binlog et de la taille des événements afin d’éviter les effets secondaires. En cas de volume d’écriture très élevé, je surveille l’état des esclaves et la latence des threads SQL pendant la modification. Si un audit est nécessaire, il est possible de mettre en évidence la modification DDL dans le balisage du journal. Les tâches ETL en aval doivent être informées de la nouvelle colonne suffisamment tôt afin d’éviter que les exécutions nocturnes ne se déroulent en vain. Cette orchestration garantit une Déroulements.
Particularités de Galera/Cluster avec Instant-DDL
Dans les clusters à réplication synchrone (par exemple Galera), les opérations DDL ont souvent pour effet de TOI-Événement (Total Order Isolation). INSTANT réduit considérablement la coordination globale nécessaire à cet effet, mais un bref temps d'arrêt à l'échelle du cluster peut néanmoins se produire. Je continue donc à planifier ces modifications de manière réfléchie, je limite la durée des sessions et j'évite les transactions simultanées de longue durée qui MDL- pourraient prolonger les blocages. Je n'utilise les stratégies RSU (Rolling Schema Upgrade) que de manière ciblée, lorsque cela s'avère absolument nécessaire d'un point de vue technique – la charge opérationnelle est généralement supérieure aux avantages.
Particulièrement important : les déploiements de schémas et d'applications orchestrer Je m'assure que tous les nœuds disposent d'une vue cohérente avant les pics de charge. Je préviens les problèmes liés aux contrôles d'intégrité et aux tests de disponibilité en prévoyant de courtes fenêtres de maintenance et en définissant des critères d'abandon clairs. Ainsi, la Disponibilité reste élevé malgré la sérialisation DDL globale.
Planification dans les environnements d'hébergement
C'est dans les environnements gérés ou en cluster qu'Instant-DDL révèle tout son potentiel, car je n'ai plus besoin de lier les déploiements à de longues fenêtres de maintenance. Notamment avec le stockage SSD et un haut niveau de parallélisme, je réduis les pics d'activité au niveau des E/S et Cache. Je coordonne ces changements avec les déploiements d'applications afin que les indicateurs de fonctionnalité et le schéma soient activés dans un ordre précis. La surveillance reste active, mais les interventions sont moins fréquentes. Il en résulte des plans plus clairs et moins de tâches opérationnelles Risques.
Je tiens également compte des horaires de sauvegarde et des tâches batch en cours, afin que la modification n'intervienne pas entre deux rapports volumineux. Dans les scénarios multi-locataires, je coordonne la séquence d'exécution : certaines bases de données sont traitées en premier, puis d'autres suivent. Je garantis la cohérence en veillant à l'uniformité des configurations telles que ROW_FORMAT. Cela me permet d’éviter les surprises si d’autres colonnes s’avèrent nécessaires par la suite. La planification apporte ici un gain de temps notable. Charges.
Exemples concrets tirés de projets
Une boutique a besoin, à court terme, d'un champ de segmentation de la clientèle pour une campagne ; j'ajoute la colonne via INSTANT et le service marketing peut la remplir immédiatement. Une table de journaux enregistre de nouveaux paramètres techniques ; j'ajoute la colonne en cours de journée, tandis que des centaines d'opérations d'écriture se poursuivent chaque seconde et que l'application répond. Dans un système de reporting, j'intègre de nouveaux champs KPI sans compromettre les clôtures journalières. Les exigences réglementaires peuvent également être mises en œuvre plus rapidement lorsque les champs d'audit sont disponibles sans qu'il soit nécessaire de reconstruire le système. Ces petites modifications permettent d'obtenir rapidement Résultats.
Dans tous les cas, je vérifie ensuite les statistiques et j'analyse de manière ciblée des échantillons. Je vérifie si les ORM ou les outils de migration prennent immédiatement en compte la colonne. Les caches et les scripts de migration doivent connaître la nouvelle structure afin d'éviter toute interprétation erronée. Pour les équipes plus importantes, je documente le changement dans un manuel d'exploitation. Cela permet de conserver un historique et une justification claire de la décision. compréhensible.
Dépannage lorsque cela ne fonctionne pas immédiatement
Si un « Change » entre en collision avec ALGORITHME=INSTANTANÉ , je commence par rechercher les formats incompatibles tels que ROW_FORMAT=COMPRESSED ou selon des index spécifiques. Ensuite, je consulte les détails de la version : dans la version 10.3, la position de la colonne impose Fin, à partir du 10.4, on dispose d'une plus grande flexibilité. Si la base de données propose un plan de secours vers INPLACE ou COPY, j'interromps l'opération et j'adapte la stratégie ou le schéma. Les éléments significatifs sont AFFICHER LES AVERTISSEMENTS et AFFICHER CREATE TABLE pour les indicateurs de mise en page. Ce n'est que lorsque le cas de test fonctionnera instantanément que je prévois la mise en production Version.
Je pense également aux phases à forte charge transactionnelle : même de courts verrouillages de métadonnées peuvent perturber les points noirs lorsque les applications suivent des schémas défavorables. En planifiant plus finement pour cibler une plage horaire moins chargée, j’atténue ces effets. Je vérifie également si les déclencheurs, les colonnes virtuelles ou les clés étrangères ont des effets indésirables. Effectuer des vérifications minutieuses en amont permet de gagner beaucoup de temps en cas d’incident. Mon objectif reste de rendre la modification brève, réversible et transparent de tenir.
Surveillance et dépannage en production
Pendant le déploiement, j'effectue un suivi ciblé MDL- Temps d'attente et E/S. INFORMATION_SCHEMA.PROCESSLIST et INFORMATION_SCHEMA.METADATA_LOCKS me permettent de voir si des sessions attendent un DDL. En complément, j'utilise performance_schema-Événements permettant de corréler de courtes pauses. Sur les réplicas, je vérifie la latence des threads SQL et la valeur « Seconds_Behind_Master » afin de limiter, si nécessaire, les opérations de backfill ou les déploiements d’applications. Avec le mode INSTANT, le fichier binlog ne grossit que très peu ; les pics indiquent la présence d’étapes cachées (par exemple, la création d’index).
Après la modification, je valide avec EXPLAIN et les lectures d'échantillons, afin que les requêtes détectent correctement les nouvelles colonnes. Dans les tableaux de bord, j'observe Threads_running, le compteur de gestionnaires et le taux d'accès au pool de tampons, afin de détecter les effets secondaires. Si, malgré LOCK=NONE Lorsque des blocages surviennent, cela est généralement dû à un point noir DDL ou DML concurrent. Dans ce cas, une brève fenêtre de maintenance ou le report de l'opération à un moment plus calme peut aider. J'interromps délibérément les erreurs plutôt que de me laisser entraîner dans des solutions de repli floues – cela évite des reconstructions fastidieuses.
Comparaison des algorithmes DDL
Le tableau suivant présente une classification des commandes COPY, INPLACE et INSTANT et m’aide à évaluer de manière réaliste les risques et la durée. J’évalue également dans quelle mesure les accès simultanés sont affectés et quels blocages peuvent survenir. Pour mieux comprendre les blocages, il est utile de consulter Verrouillage par ligne et les répercussions sur le parallélisme. Cela me permet d'éviter les mauvaises décisions dans les processus critiques pour la production tableaux. Le tableau a été volontairement condensé et sert à fournir un aperçu rapide Comparaison.
| Algorithme | Verrouiller | Copie des données | Durée (tableaux volumineux) | Utilisation typique |
|---|---|---|---|---|
| COPY | plus forte Locks | entièrement | long (jusqu'à plusieurs heures) | modifications incompatibles, changement de format |
| INPLACE | modéré Locks | partiellement / riche en métadonnées | moyen (de quelques minutes à plus longtemps) | de nombreuses modifications en ligne sans refonte totale |
| INSTANT | court MDL-phases | non (métadonnées uniquement) | très court (de quelques millisecondes à quelques secondes) | ADD/DROP COLUMN, changement de position (à partir de la version 10.4) |
J'interprète ce tableau comme un arbre de décision : si INSTANT est possible, je le privilégie ; sinon, j'envisage INPLACE ; ce n'est que si ces deux options échouent que j'accepte COPY. La combinaison de la stratégie de verrouillage et de l'algorithme doit être adaptée au profil de trafic. C'est justement dans le cas d'applications à forte intensité d'écriture que je prévois au préalable une solution de repli. Ainsi, les déploiements restent stables même sous pression contrôlable. Si je l'applique systématiquement, je fais de belles économies Temps.
Compatibilité des applications et ORM
Les modifications de schéma ne sont „ invisibles “ que si le code de l'application est capable de les gérer. SELECT * et les accès par position ordinale constituent des facteurs de risque dès lors que je réorganise les colonnes (à partir de la version 10.4) ou que j'insère de nouveaux champs. Je privilégie donc les listes de colonnes explicites, les mappages vérifiés et la gestion des versions des DTO. Les ORM et les outils de migration mettent souvent les métadonnées en cache ; un redémarrage à chaud ou une commande „ Reprepare “ pour les instructions préparées permet d’éviter les erreurs d’interprétation. Dans les environnements de microservices, je coordonne les versions de manière à ce que seules les versions tolérantes soient actives simultanément pour le trafic.
En matière de rétrocompatibilité, je procède ainsi : j’ajoute d’abord la colonne, puis je déploie le code qui l’utilise de manière facultative ; ce n’est qu’une fois que toutes les instances ont été mises à jour et que le backfill est terminé que je renforce les contraintes. Cela permet de garantir la rapidité des déploiements et des retours en arrière, tout en préservant la robustesse du système. Pour les audits, je documente la justification, l'instruction SQL, la date, les critères de réussite et la procédure de retour en arrière – cela instaure la confiance et garantit la reproductibilité. Processus.
Évolutivité : partitionnement et DDL instantané
Le partitionnement et INSTANT se complètent parfaitement, car des unités physiques plus petites rendent les mises à jour encore plus prévisibles. En fractionnant logiquement les tables, je limite les points chauds et facilite les modifications ultérieures. Bon Stratégies de partitionnement contribuent à garantir la gestion durable de très grands ensembles de données. Au final, j'obtiens des latences plus faibles, des fenêtres de maintenance plus claires et moins de risques lors de Modifications. La nouvelle colonne sera alors disponible plus rapidement sur toutes les partitions concernées.
Je planifie l'ordre des opérations : d'abord la conception du partitionnement, puis les DDL, puis les « backfills » pour les valeurs facultatives. Cela me permet d'éliminer les conflits qui pourraient survenir en cas de modifications simultanées des index ou du stockage. Là encore, les tests restent mon outil le plus efficace. Grâce à des indicateurs clairs, je peux déterminer si l'étape est viable sur les systèmes de production. Cette approche rigoureuse évite les désagréments et permet à l'équipe de rester concentré.
Récupération après panne, sauvegardes et cohérence
INSTANT-DDL ne modifie que Catalogue et métadonnées. Cela rend l'opération rapide – et atomique. Soit la colonne est visible après un plantage, soit elle ne l'est pas du tout ; il n'y a pas d„“ état intermédiaire ». La charge sur le journal Redo/Undo reste minime, car aucune page de données n'est déplacée. En ce qui concerne la réplication : l’événement DDL est transmis proprement ; les répliques n’ont pas besoin de copier de lignes. Les sauvegardes physiques en cours lors de la modification doivent capturer le bref changement de métadonnées au moment de l’instantané – les outils dotés d’un système de points de contrôle cohérents y parviennent sans difficulté. Les sauvegardes logiques intègrent immédiatement la colonne dans CREATE TABLE-instructions, même si de nombreuses lignes comportent encore le Défaut porter.
Il est possible d'effectuer plusieurs modifications instantanées consécutives. Je veille toutefois à ne pas changer de position à tout va ni à supprimer puis recréer des colonnes sans raison. Les modifications fréquentes de la structure augmentent les efforts de coordination et peuvent, dans certains cas marginaux, conduire à ce qu'une refonte complète s'avère finalement judicieuse (par exemple, en cas de changements de format nécessaires). Grâce à une fenêtre de modification pragmatique et à une feuille de route claire, je maîtrise la dette technique.
En bref
Grâce à Instant ADD COLUMN, je peux apporter des modifications de schéma à de grandes tables en temps réel, en ne modifiant que les métadonnées et en laissant les blocs de données intacts. La bonne version, un ROW_FORMAT compatible et des options DDL claires telles que ALGORITHME=INSTANTANÉ et LOCK=NONE sont déterminants pour la réussite ou la refonte. Pour l'exploitation et la réplication, cela se traduit par un temps de latence réduit, des déploiements planifiables et une Disponibilité. J'utilise des tests, un suivi et une documentation rigoureuse pour éviter toute mauvaise surprise. Ainsi, ma base de données reste flexible et je peux intégrer de nouvelles exigences sans interruption dans le Fonctionnement en direct de.
