Avec plaisir

J'ai recherché pas mal d'optimisations au niveau de la configuration du moteur InnoDB. Au final, sur mon laptop windows (baaaah) j'ai réussi à diviser par 80 le temps d'insertion de 200 000 enregistrements.

Je rédigerai un article précis dessus... plus tard

Bonjour tout le monde,

Je ne suis absolument pas du tout un expert MySQL, du coup je ne sais pas si on peut réellement parler de réplication ou pas, et si oui, quelle serait la marche à suivre... Je vais donc vous exposer mon problème, et prendre en compte vos remarques.

La problématique, en quelques axiomes :
- Nous avons 3 serveurs : dev, test, et prod
- Sur chacun de nos serveurs tourne un serveur MySQL avec un dump plus ou moins récent de la BDD de prod.
- J'ai totalement modifié le modèle existant et j'ai effectué la migration d'environ 10 millions d'enregistrements de l'ancien modèle vers le nouveau

Nous allons devoir mettre en place ce nouveau modele sur le serveur de prod. Nous prévoyons d'interrompre le service quelques heures le temps d'effecture la migration. (Sur mon simple PC, le seul import de donnéees prend 24h environ, le moteur étant InnoDB et je le laisse vérifier les contraintes)

La solution envisagée serait, pendant l'interruption de service, de répartir la migration sur 3 ou 4 serveurs qui s'occuperait de migrer chacun un tiers ou un quart des tables, puis de faire remonter le tout sur le serveur de prod.

L'idéal après ça serait une sorte de copier/coller des tables de ces serveurs sur le serveur de prod, sans prendre aucun temps de calcul.


Mes questions :
1) Est-ce une bonne technique ?
2) Sinon, comment faire au mieux, sans interrompre trop longtemps le service et en évitant des retards de réplications ?


Merci à vous,
Adrien