C’était une étape que nous devions franchir. Nous avons eu du mal à nous décider, même si nous savions que tôt ou tard cela nous poserait problème, comme cela a fini par arriver.
Il y a deux semaines, un jour comme un autre, un processus habituel du programme de gestion d’entrepôt nous a fait tomber le site. Ce n’était pas excessivement grave, puisque 20 secondes plus tard le site était de nouveau en ligne et sans problème, mais ce fut la goutte d’eau qui a fait déborder le vase et nous a décidés à changer le moteur des tables MySQL.
Le problème, c’était que le moteur fourni par défaut dans osCommerce, MyISAM, est beaucoup plus rapide pour effectuer des requêtes de lecture, mais en contrepartie il verrouille une table pendant le temps nécessaire à l’exécution d’une requête, et si c’est une table gigantesque avec 135 requêtes en file d’attente pour accéder à cette même table, nous avons un problème et, par conséquent, le site se bloque. Une fois la requête « bloquante » tuée, tout revient à la normale, mais… jusqu’à quand ? Et pire encore : si nous ne sommes pas là pour nous en rendre compte ?
Nous avons donc décidé de trancher dans le vif et, sur recommandation du responsable de nos serveurs, nous sommes passés à InnoDB. Pour cela, nous avons préparé une batterie de tests et de vérifications que nous avons lancés avant et après le changement de moteur sur nos serveurs locaux, puis en préproduction. Même s’il y avait un risque avec les jointures entre tables, leur immense quantité dans notre code ne nous permettait pas de les analyser une par une en détail ; nous avons donc choisi de lancer cette batterie de tests, assez complète malgré tout.
Une fois vérifié en préproduction que tout se passait comme prévu, clavier en main et les yeux rivés à l’écran, à 5 h du matin — quand il n’y a presque pas de visiteurs — nous avons pris notre courage à deux mains et commencé par la sauvegarde de la base de données, puis immédiatement après par le changement de moteur des tables. D’abord les plus lourdes une par une, puis les plus légères par groupes, afin de ne pas pénaliser les performances pour ces quelques courageux qui nous rendaient visite à des heures aussi indues. En un peu plus d’une heure et demie, nous avions déjà tout changé et la batterie de tests était passée. Aucune erreur, aucun souci, rien d’étrange. Étrange, non ? Eh bien c’est vrai : cette fois, Murphy était de notre côté.
Les résultats obtenus sont ceux attendus : aucun verrouillage de tables, au prix de performances un peu moins bonnes dans 10 % des cas, ce que nous espérons résoudre bientôt en découpant en plusieurs parties les deux ou trois tables mastodontes que nous avons. Dans quelques jours — ou semaines — je vous raconterai aussi comment s’est passée cette division. Je vous encourage à le lire à ce moment-là, mais en attendant, je vous laisse quelques liens pour celles et ceux qui voudraient approfondir le sujet :
- http://www.arsys.info/programacion/myisam-o-innodb-elige-tu-motor-de-almacenamiento-mysql/
- http://dev.mysql.com/doc/refman/5.0/es/converting-tables-to-innodb.html
- http://stackoverflow.com/questions/7335515/migrating-from-myisam-to-innodb
Laisser un commentaire