Migration iTop volumineuse : réduire une bascule de 14h à 4h30

Ce n’est pas tant la taille globale de la base de données en gigaoctets qui rend une migration complexe, mais sa structure interne et sa volumétrie réelle. Le véritable facteur de ralentissement réside dans le nombre de lignes par table, parfois en millions, notamment au sein des tables historiques très sollicitées. À cela s’ajoutent les pièces jointes, souvent nombreuses et lourdes, ainsi que les images insérées en copier/coller (inline) qui augmentent considérablement le volume des tables associées. Enfin, la présence d’index multiples et de triggers complexifie les opérations d’export et d’import, en rallongeant les temps de traitement et en augmentant le risque d’erreurs lors de la migration.

Certaines tables peuvent dépasser plusieurs millions d’enregistrements :

• ticket

• priv_change

• inlineimage

• attachment

• priv_search

À ce volume, un dump mono-thread (une seule tâche traite l’ensemble des données) devient un goulot d’étranglement.

Pour une Direction des Systèmes d’Information, une migration iTop ne doit jamais être perçue comme un pari technique, ni comme une opération irréversible génératrice de stress organisationnel.

Elle doit au contraire s’inscrire dans une démarche maîtrisée, structurée et sécurisée.

L’objectif est double : garantir la réversibilité complète en cas d’incident et assurer une maîtrise stricte du temps d’indisponibilité, afin de protéger la continuité de service.

Cela implique également de réduire au maximum les points critiques, d’anticiper les risques techniques et d’être capable de rejouer la procédure à l’identique lors des phases de test comme en production. En matière de migration à fort volume, la véritable clé n’est pas seulement la performance, mais la répétabilité et la fiabilité du processus.

Dans le cadre de cette migration, plusieurs options ont été étudiées. La sauvegarde incrémentale aurait pu constituer une solution pertinente dans un environnement homogène, tout comme l’utilisation d’un mysqldump classique peut convenir pour des bases de taille modérée. Toutefois, dans notre cas précis, la différence d’architecture entre les environnements source et cible, ainsi que la migration de MySQL vers MariaDB, rendaient ces approches inadaptées. L’incrémentation n’était pas exploitable et les méthodes traditionnelles mono-thread se révélaient beaucoup trop lentes au regard de la volumétrie.

Nous nous sommes donc orientés vers MyDumper / MyLoader, une solution open source capable de gérer des dumps multi-threads, de découper intelligemment les tables volumineuses, d’effectuer des imports en parallèle et de maîtriser finement la gestion des triggers et des events.

Plutôt que de considérer la migration comme une opération ponctuelle, nous avons fait le choix de l’industrialiser.

Concrètement, cela a consisté à travailler sur une base répliquée afin de pouvoir exécuter plusieurs cycles complets de dump et de restauration sans impacter la production. Chaque itération nous a permis d’identifier les points de ralentissement, d’ajuster le niveau de parallélisation et d’analyser finement les journaux d’exécution.

L’objectif n’était pas simplement d’accélérer le transfert, mais de fiabiliser le processus. Une migration réussie n’est pas celle qui fonctionne une fois, mais celle que l’on peut rejouer à l’identique.

Nous avons notamment porté une attention particulière :

• à l’optimisation du nombre de threads en fonction des ressources CPU disponibles,

• à la gestion des triggers et des événements,

• aux paramètres SQL susceptibles de provoquer des conflits entre l’environnement source et l’environnement cible.

L’utilisation de MyDumper et MyLoader nous a permis d’exploiter pleinement le parallélisme du serveur via un nombre de threads adapté à l’infrastructure. La compression des données a réduit les volumes à transférer, tandis que la gestion explicite des routines, triggers et événements garantissait l’intégrité fonctionnelle de l’application après import.

Un point particulièrement critique concernait les definers SQL. Dans un contexte où les environnements différaient (notamment lors du passage de MySQL vers MariaDB), la reprise automatique des definers pouvait générer des erreurs de droits ou des incohérences. L’option skip-definer s’est révélée essentielle pour sécuriser la migration et éviter les conflits d’utilisateurs entre les deux plateformes.

Enfin, certaines vues devenues inutiles dans iTop 3.2 ont volontairement été exclues afin d’alléger le processus et de limiter les éléments superflus.

Dump

• --threads=8 (adapté au CPU)

• --compress

• --routines

• --triggers

• --events

• --skip-definer

• --no-views (inutile en iTop 3.2)

Import

• --threads=8

• --overwrite-tables

• --skip-definer

Le paramètre skip-definer est particulièrement important pour éviter les conflits d’utilisateurs SQL entre environnement source et cible.
Pour plus de détails n’hésitez pas à consulter la documentation MyDumper documentation

• Création correcte des triggers

• Désactivation temporaire des notifications

• Surveillance des logs en temps réel

• Vérification post-import des index

• Gestion spécifique des tables volumineuses (attachment, inlineimage)

Résultat obtenu

Réduction : –75% du temps d’indisponibilité

Ce que cela signifie pour une DSI

Une migration maîtrisée permet :

• De planifier sereinement une montée de version iTop

• D’éviter les week-ends prolongés de support technique

• De réduire le risque opérationnel

• De sécuriser la trajectoire ITSM

Sur des environnements volumineux, l’outillage fait la différence.