Plongée dans la migration MySQL 8.0 conduite par Facebook

Spread the love
Plongée dans la migration MySQL 8.0 conduite par Facebook

Facebook a annoncé la semaine dernière la finalisation du type de tâches que beaucoup d’entreprises redoutent : une mise à niveau majeure de sa base de données principale. Des craintes fondées : la migration mise en place par le réseau social a en effet rencontré son lot de difficultés.

Si les migrations de bases de données sont fréquentes, le retour détaillé de Facebook permet cette fois d’en tirer des enseignements précieux. Pour rappel, il s’agissait d’un projet massif et pluriannuel, notamment parce que Facebook dispose d’un grand nombre d’instances MySQL. Tout d’abord, pourquoi toute cette agitation ? Il ne fait aucun doute que MySQL représente une mise à niveau générationnelle majeure pour Facebook. Cette mise à niveau est si importante qu’Oracle, propriétaire de MySQL, a été incité à entreprendre un rafraîchissement et une mise à niveau majeurs de son propre service de cloud MySQL.

La liste des changements apportés à la version 8.0 est longue, mais nous allons en souligner quelques-uns ici. Tout commence par la facilité de gestion : MySQL 8.0 ajoute le dictionnaire de données transactionnel qui est par ailleurs la norme pour les bases de données d’entreprise. Il est d’une plus grande simplicité : toutes les tâches impliquées par le langage de définition des données (DDL) invoqué pour les commandes de routine sont désormais regroupées en une seule instruction.

Il n’est donc plus nécessaire d’écrire des instructions distinctes pour les mises à jour du dictionnaire de données, les opérations du moteur de stockage et les écritures dans le journal binaire. Le chiffrement des tables a été simplifié et la prise en charge des types de données étendus tels que BLOB, TEXT, GEOMETRY et JSON a été améliorée.

publicité

Des index invisibles ?

MySQL 8.0 apporte une nouvelle fonctionnalité intéressante : les “index invisibles”, qui permettent de tester l’impact de la suppression des index sans avoir à les supprimer physiquement. Elle est analogue aux fonctions d’indexation avancées d’Oracle Autonomous Database et de Microsoft Azure SQL Database qui permettent de tester des schémas d’indexation alternatifs pour évaluer si certains index gaspillent de l’espace, ou si des index nouveaux ou modifiés pourraient récupérer des données avec moins de frais de calcul.

Mais comme tout administrateur de base de données expérimenté peut en témoigner, il y a toujours un prix à payer lors d’une mise à niveau, comme la déstabilisation des applications, ce qui explique pourquoi la plupart des organisations reportent la migration jusqu’à ce que le besoin soit trop important. Ce n’est pas une coïncidence si la plupart des fournisseurs de DBaaS (Database-as-a-Service) font miroiter l’élimination de la douleur des mises à niveau pour soulager les clients de ces maux de tête.

Il n’est donc pas surprenant qu’en tête de liste des leçons apprises figure la gestion des problèmes de compatibilité. Débutons par les personnalisations, qui sont typiques des installations de données d’entreprise bien établies. Il n’est pas surprenant que ce problème se pose depuis longtemps dans le monde des applications d’entreprise, où les outils de migration automatisés ne s’occupent généralement pas des personnalisations. En fait, SAP encourage désormais ses clients à conserver les implémentations de base et à les abstraire au moyen d’API qui devraient rester stables. Facebook n’a pas eu ce luxe avec la migration MySQL.

Course d’obstacles

Un problème connexe est la compatibilité API, et c’est là que Facebook a découvert un “piège” caché. Comme nous l’avons indiqué, les clients remettent généralement à plus tard les migrations de grands systèmes d’entreprise en raison du temps et des perturbations qu’elles impliquent, et dans ce cas, cela signifie que Facebook a sauté un cycle. Au lieu de passer de MySQL 5.6 à 5.7, ils ont ignoré la version intermédiaire et sont passés directement à la version 8.0.

Le résultat a été la nécessité d’effectuer un travail de détection concernant les API prises en charge ; comme l’ont appris à leurs dépens les équipes de Facebook, un certain nombre d’API ont été modifiées dans la version 5.6 et n’étaient pas incluses dans la documentation 8.0. Cela a ajouté une pénalité de temps.

Dans certains cas, la migration a également concerné le moteur de stockage sous-jacent. MySQL est une base de données qui prend en charge les moteurs de stockage enfichables, et depuis 2016, Facebook a déplacé ses implémentations MySQL orientées utilisateur d’InnoDB, le moteur le plus couramment utilisé dans MySQL, vers MyRocks, un moteur de stockage open source qu’en fait Facebook a développé. L’avantage de MyRocks est une compression et des écritures plus efficaces.

Le passage d’InnoDB à MyRocks a nécessité un cadre de test “fantôme” qui capturait le trafic de production et le rejouait dans des instances de test. Mais ce processus n’était pas infaillible ; il a manqué des problèmes tels que la façon dont MyRocks gérerait les blocages d’écriture des transactions. La morale de l’histoire est que si vous pouvez simuler certains scénarios, dans certains cas, les bugs n’apparaîtront qu’après coup, et vous devez intégrer des corrections a posteriori dans tout plan de migration et de test.

Prudence est mère de sureté

De quoi pousser Facebook à la prudence. Au lieu du processus habituel de réplication des tableaux ou des instructions SQL, Facebook a procédé ligne par ligne – un processus très laborieux. La nécessité d’une action aussi radicale a été motivée par l’importance du portefeuille d’applications et la probabilité de rencontrer des interdépendances : certaines données susceptibles d’être utilisées par l’application A peuvent avoir été dérivées à la suite d’un traitement par l’application B.

La leçon est – sans surprise – que la migration des bases de données d’entreprise est rarement une entreprise triviale. C’est en grande partie la raison pour laquelle Facebook a emprunté une voie que les grandes entreprises ont l’habitude de repousser jusqu’à ce que ce soit absolument nécessaire. Parce que cela signifiait sauter une mise à niveau de version intermédiaire, le réseau social en a payé le prix. La question est finalement de savoir si cela sera bénéfique à Facebook lorsqu’une version 9.0 de MySQL sortira. Et là, la réponse ne va pas de soi.

Source : ZDNet.com

Leave a Reply