Crédit : Octopus Deploy
Cette semaine, l'organisation de développement de Facebook a annoncé l'achèvement du type de tâches que les entreprises redoutent : une mise à niveau majeure de sa base de données principale. Larry Dignan a souligné les points forts de son bilan d'hier. Et dans cet aperçu, il a plus qu'insinué sur les épreuves et les tribulations rencontrées par la migration.
Les migrations de bases de données se produisent tout le temps, et les conseils sur la façon de les mener ne manquent pas. Mais le billet de blog détaillé de Facebook a donné des leçons précieuses, que nous aborderons plus en détail ici. C'était un projet massif et pluriannuel, surtout parce que Facebook dispose d'un si grand nombre d'instances MySQL.
Tout d'abord, de quoi s'agissait-il ? Il ne fait aucun doute que MySQL représente une mise à niveau générationnelle majeure de cette plate-forme. La mise à niveau était si importante qu'Oracle, propriétaire de MySQL, a été invité à entreprendre une actualisation et une mise à niveau majeures de son propre service MySQL dans le cloud.
Il y a une longue liste de changements dans la version 8.0, mais nous en soulignerons quelques-uns ici. Tout commence par la facilité de gestion : MySQL 8.0 ajoute le dictionnaire de données transactionnelles qui est par ailleurs standard pour les bases de données de niveau entreprise. Il y a plus de simplicité : toutes les tâches impliquées avec le langage de définition de données (DDL) invoqué pour les commandes de routine sont désormais combinées en une seule instruction. Ainsi, vous n'avez pas besoin d'écrire des instructions distinctes pour les mises à jour du dictionnaire de données, les opérations du moteur de stockage et les écritures de journaux binaires. Le chiffrement des tables a été rationalisé et la prise en charge des types de données étendus tels que BLOB, TEXT, GEOMETRY et JSON est améliorée.
Il y a la nouvelle fonctionnalité intéressante des “index invisibles” qui permet de tester les impacts de la suppression des index sans avoir à les supprimer physiquement. C'est analogue aux fonctionnalités 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 DBA expérimenté l'attestera, il y a toujours un prix à payer lors de la mise à niveau, comme la déstabilisation des applications, c'est pourquoi la plupart des organisations reportent la migration jusqu'à ce que le besoin soit trop important. Ce n'est pas par hasard que la plupart des fournisseurs de bases de données en tant que service (DBaaS) dans le cloud tiennent la promesse d'éliminer la douleur des mises à niveau, car ils soulagent les clients de ces maux de tête.
Il n'est donc pas surprenant qu'en haut de la liste des leçons apprises se trouvent les problèmes de compatibilité. Commençons par les personnalisations, qui sont typiques des installations de données d'entreprise bien établies. Sans surprise, cela constitue également depuis longtemps un problème dans le monde des applications d'entreprise, où les outils de migration automatisés s'arrêtent généralement en matière de personnalisation. En fait, SAP encourage désormais les clients à conserver les implémentations de base à la vanille et à faire abstraction des implémentations via des API qui devraient rester stables. Facebook n'a pas eu ce luxe avec la migration MySQL. Comme Larry l'a noté dans son compte, seuls 1500 des 2300 correctifs personnalisés ont fait le déplacement, le reste étant obsolète.
Un problème connexe est la compatibilité des API, et c'est là que Facebook a découvert un « piège » caché. Comme indiqué, les clients reportent généralement les migrations des systèmes des grandes entreprises en raison du temps et des perturbations impliqués, et dans ce cas, cela signifiait que Facebook sautait un cycle. Au lieu de passer de MySQL 5.6 à 5.7, ils ont ignoré la version intermédiaire et sont passés directement à 8.0. Le résultat était la nécessité d'effectuer un travail de détective concernant les API prises en charge ; comme ils ont appris à leurs dépens, un certain nombre d'API ont été modifiées dans la version 5.6 qui n'étaient pas incluses dans la documentation 8.0. Cela a ajouté une pénalité de temps.
La migration dans certains cas impliquait également 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 destinées aux utilisateurs d'InnoDB, le moteur le plus couramment utilisé dans MySQL, vers MyRocks, un moteur de stockage open source développé par Facebook. L'avantage de MyRocks est une compression et des écritures plus efficaces.
Le passage d'InnoDB à MyRocks nécessitait un framework 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 de transaction. La morale de l'histoire est que même si vous pouvez simuler certains scénarios, dans certains cas, les bogues n'apparaîtront qu'après coup, et vous devez intégrer des correctifs après coup dans tout plan de migration et de test.
En raison de tous les problèmes de compatibilité attendus et inattendus, Facebook a joué très prudemment lorsqu'il s'agissait de déplacer des données. Au lieu du processus habituel de réplication de tables ou d'instructions SQL, Facebook a procédé ligne par ligne – un processus très laborieux. La nécessité d'une telle action drastique était motivée par le vaste portefeuille d'applications et la probabilité de rencontrer des interdépendances : certaines données qui pourraient être utilisées par l'application A peuvent avoir été dérivées du traitement par l'application B.
La leçon sans surprise est que la migration des bases de données d'entreprise est rarement triviale.
C'est en grande partie la raison pour laquelle Facebook a pris un chemin qui est courant pour les grandes entreprises d'attendre jusqu'à ce que cela soit absolument nécessaire, et parce que cela impliquait de sauter une mise à niveau de version intermédiaire, cela a payé un prix. Cela a conduit Larry à se demander dans son article si tous les efforts en valaient la peine.
La question est de savoir si ces maux de tête pourraient être évités ou minimisés à l'avenir, quand disons, il existe un MySQL 9.0. Une réponse – si vous n'êtes pas Facebook – est de passer au cloud Database-as-a-Service DBaaS), où les fournisseurs de cloud maintiennent continuellement la version à jour et isolent supposément les clients des changements de plate-forme sous-jacents.
Mais si vous essayez toujours cela à la maison, Larry a fait allusion à la réponse : commencez à planifier dès maintenant pour cette éventualité. Plus précisément, effectuez les mises à niveau de la version dot, mais peut-être qu'à long terme, commencez à faire abstraction des personnalisations à l'aide d'API, si possible. Peut-être qu'à l'avenir, l'apprentissage automatique pourrait fournir une aide pour prédire où des problèmes de compatibilité pourraient survenir, mais c'est certainement un cas où l'intuition humaine doit rester sous contrôle.
Big Data
Où se trouve la rampe de lancement du cloud hybride d'IBM ? Sept façons de faire de la technologie en temps réel une réalité pour votre organisation L'apprentissage automatique à la périphérie : TinyML prend de l'ampleur Quelle est la prochaine étape pour Cloudera ? McDonald's veut « démocratiser » l'apprentissage automatique pour tous les utilisateurs de ses opérationsSujets connexes :
Gestion des données Transformation numérique Robotique Internet des objets Innovation Logiciel d'entreprise 