Migration MySQL Sans Interruption À L’échelle Du Téraoctet

Comment nous avons migré une base MySQL de 2 To depuis des serveurs physiques vers Kubernetes, sans interruption.

  • MySQL
  • Kubernetes
  • Migration

Le problème

Une entreprise SaaS de la fintech exploitait une base MySQL de 2 To sur de vieux serveurs physiques. L’infrastructure arrivait en fin de vie. Les sauvegardes étaient manuelles et jamais testées. Il n’y avait aucune bascule : si le serveur principal tombait, la plateforme tombait avec lui. La migration devait avoir lieu bientôt, mais le coût d’une interruption était inacceptable.

Le défi

Il ne s’agissait pas seulement de déplacer des données. L’entreprise traite des milliards de transactions par an. Chaque seconde d’interruption coûte de l’argent. Une migration classique en une seule fois n’était pas envisageable.

La solution

Nous avons conçu et mené une migration sans interruption, en procédant par étapes :

Phase 1 : mise en place du réplica

  • Construction d’un Percona XtraDB Cluster (PXC) à 3 nœuds sur Kubernetes
  • Mise en place de la réplication MySQL depuis l’ancien serveur principal physique vers le nouveau cluster PXC
  • Validation du retard de réplication (constamment < 100 ms)
  • Exécution de requêtes sur le réplica pour vérifier l’exactitude des données

Phase 2 : routage des connexions

  • Déploiement de ProxySQL devant les deux clusters
  • Écriture de règles de routage pour envoyer les lectures vers le nouveau cluster
  • Écritures maintenues sur l’ancien serveur principal pendant le rattrapage de la réplication
  • Suivi continu du retard de réplication

Phase 3 : bascule

  • Une fois le retard de réplication à zéro pendant 24 heures, nous avons effectué la bascule
  • Redirection du trafic d’écriture de l’ancien serveur principal vers le nouveau cluster PXC (changement en 5 secondes)
  • Ancien serveur principal conservé comme réplica en lecture pour permettre un retour arrière immédiat
  • Surveillance pendant 2 heures sans incident, puis mise hors service de l’ancien matériel

Phase 4 : sauvegardes

  • Configuration de XtraBackup automatisé vers S3 (quotidien + incrémentiel)
  • Mise en place de la vérification des sauvegardes (restaurations quotidiennes de test sur une instance isolée)
  • Documentation des procédures de restauration

Technologies utilisées

  • MySQL 8.0 (InnoDB)
  • Percona XtraDB Cluster 8.0
  • ProxySQL 2.x (pooling de connexions et routage)
  • XtraBackup (automatisation des sauvegardes)
  • Amazon S3 (stockage des sauvegardes)
  • Kubernetes (gestion du cluster PXC)

Résultats

  • Zéro interruption pendant la bascule de la migration
  • Base de 2 To migrée avec succès et opérationnelle
  • Sauvegardes automatisées quotidiennes, avec validation
  • RTO < 5 minutes en cas de panne d’un nœud (le cluster se rétablit automatiquement)
  • RPO < 1 heure (sauvegardes quotidiennes avec restauration incrémentielle)
  • Confiance de l’équipe : la plateforme de base de données est désormais comprise et maîtrisée

L’entreprise a pu mettre hors service un matériel physique vieux de 20 ans et passer à une plateforme de base de données cloud native, sans aucune perturbation de la production.

Vous avez un défi similaire à discuter avec nous ?

Parlons de vos objectifs d’infrastructure.

Contactez-nous