1 pièce(s) jointe(s)
Facebook explique les défis auxquels il a dû faire face lors de la migration de MySQL 5.6 vers la version 8.0
Facebook explique les défis auxquels il a dû faire face lors de la migration de MySQL 5.6 vers la version 8.0,
une migration qui a duré des années avec à la clé des gains non négligeables
Depuis le mois de mai, la dernière version du système de gestion de bases de données relationnelles MySQL est disponible. Facebook, qui utilise ce logiciel pour gérer les pétaoctets de données qu’il agrège, a effectué la migration vers MySQL 8.0 afin de profiter de toutes les dernières fonctionnalités de ce système de base de données. Toutefois, bien que hautement bénéfique au réseau social, cette migration ne s’est pas faite sans peine.
Facebook et MySQL : un amour inséparable
Lorsque les utilisateurs cliquent sur les boutons likes, font des commentaires ou partagent des éléments sur la plateforme sociale Facebook, toutes ces actions sont enregistrées dans un moteur de stockage. Dans MySQL, les principaux moteurs de stockage sont MyISAM et InnoDB. Pendant longtemps, Facebook a retenu InnoDB pour gérer ces activités ci-dessus sur ses serveurs de bases de données. Cependant, quoiqu'InnoDB offre des performances et une fiabilité exceptionnelles pour une variété de charges de travail, il présente des inefficacités en termes d'espace et d'amplification d'écriture lorsqu'il est utilisé avec un stockage flash.
Pour résoudre ces problèmes, Facebook a conçu de toute pièce un moteur de stockage nommé RocksDB qui est un fork de LevelDB de Google. Ce moteur de stockage est un magasin clé-valeur persistant et intégrable pour un stockage rapide. Il présente plusieurs avantages par rapport à InnoDB comme une meilleure compression des données, l’usage d’un plus petit nombre de lectures et écritures séquentielles, le gain d'espace avec la possibilité de supprimer des clés de préfixe identiques ou encore la possibilité de remplacer les identifiants de séquence par la valeur zéro. En outre, il offre d'autres avantages comme une réplication plus rapide et le chargement plus rapide de données.
En 2014, Facebook a commencé à rechercher l'intégration RocksDB et MySQL. Facebook n’a jamais voulu se séparer de MySQL, car il se prête facilement à l’automatisation et permet à une petite équipe de gérer facilement des milliers de serveurs MySQL tout en fournissant un service de haute qualité. L'automatisation comprend la sauvegarde, la restauration, le basculement, les modifications de schéma et le remplacement du matériel défaillant. En plus, MySQL dispose de fonctionnalités de réplication flexibles et extensibles, notamment la réplication asynchrone et la réplication semi-synchrone sans perte, ce qui permet d'effectuer un basculement sans perdre de données.
Facebook : MySQL 5.6 c’est bien, mais MyRocks basé sur MySQL 8.0, c’est mieux
En voulant combiner à la fois le moteur de base de données RocksDB et les fonctionnalités de MySQL avec des extensions ajoutées, cela a donné lieu au projet MyRocks qui permet d’avoir le meilleur des deux mondes. Pour ce faire, le réseau social s’est appuyé sur MySQL 5.6. Mais déjà à ce niveau, beaucoup de difficultés se sont fait sentir. Pour passer de la version précédente à la version 5.6 de MySQL, cela a pris un an. Et lorsque la version 5.7 de MySQL est sortie, les ingénieurs de Facebook étaient encore en train de développer le nouveau moteur de stockage MyRocks en s’appuyant sur la version 5.6 de MySQL. Vu le retard accumulé, Facebook a décidé d’ignorer MySQL 5.7 pour se concentrer sur la version 5.6 de MySQL dans le développement de MyRocks.
Mais avec la fin du cycle de vie de la 5.6 de MySQL qui approchait, Facebook a dû se résoudre à se tourner vers une version supérieure de MySQL 5.6. Le réseau social a choisi de migrer vers MySQL 8.0. Avec des améliorations comme le DDL instantané, les ingénieurs de Facebook se sont dit que cela pourrait accélérer les changements de schéma de MyRocks. Mais vu la charge de travail qui attendait les ingénieurs de Facebook, il était clair que passer à la version 8.0 serait encore plus difficile que de migrer vers la version 5.6 ou MyRocks.
Et pour cause, passer de MyRocks (la branche personnalisée de MySQL 5.6 intégrant RocksDB) à la version 8.0 exigerait de :
- porter 1700 correctifs de MyRocks vers MySQL 8.0 ;
- mettre à jour toute application utilisant les API de la version 5.6 de MySQL qui devenaient de facto obsolètes ou seraient éventuellement supprimées avec la mise à niveau vers version 8.0 de MySQL ;
- déprécier ou migrer un certain nombre de fonctionnalités de Facebook qui n’étaient pas compatibles avec les fonctionnalités similaires de la version 8.0 ;
- apporter des améliorations à MyRocks afin de pouvoir l’exécuter dans la version 8.0, y compris au niveau du partitionnement natif et la récupération après incident.
Pour mieux s’organiser à gérer tous ces soucis, Facebook a divisé ces problèmes en quatre catégories :
- Abandon : les fonctionnalités qui n'étaient plus utilisées ou qui avaient des fonctionnalités équivalentes dans la version 8.0 n'avaient pas besoin d'être portées ;
- Build/Client : des fonctionnalités non-serveur prenant en charge l’environnement de build et des outils MySQL modifiés tels que mysqlbinlog, ou des fonctionnalités supplémentaires telles que l'API client asynchrone, ont été portées ;
- Serveur non-MyRocks : les fonctionnalités du serveur mysqld qui n'étaient pas liées au moteur de stockage MyRocks ont été portées ;
- Serveur MyRocks : les fonctionnalités prenant en charge le moteur de stockage MyRocks ont été portées.
Avec tous les changements liés au client porté, Facebook a pu mettre à jour ses outils client et son code de connecteur vers la version 8.0. Une fois toutes les fonctionnalités du serveur non-MyRocks portées, le réseau a pu déployer mysqld 8.0 pour les serveurs InnoDB. La finalisation des fonctionnalités du serveur MyRocks a permis de mettre à jour les installations de MyRocks.
Certaines des fonctionnalités les plus complexes nécessitaient des modifications importantes pour la version 8.0, et quelques domaines présentaient des problèmes de compatibilité majeurs. Finalement, le serveur 5.6 a dû être patché pour qu'il soit compatible avec la version 8.0. Il a fallu quelques années pour terminer le portage de toutes ces fonctionnalités. Au moment où tout ce travail a été achevé, plus de 2 300 correctifs ont été comptabilisés et 1 500 d'entre eux ont été portés vers la version 8.0.
Et au final ?
« Malgré tous les obstacles sur notre chemin de migration, nous avons déjà vu les avantages de l'exécution de la version 8.0. Certaines applications ont opté pour une conversion anticipée vers la version 8.0 pour utiliser des fonctionnalités telles que Document Store et une prise en charge améliorée de la date et de l'heure. Nous avons réfléchi à la manière de prendre en charge les fonctionnalités du moteur de stockage telles que Instant DDL sur MyRocks. Dans l'ensemble, la nouvelle version développe considérablement ce que nous pouvons faire avec MySQL », a déclaré Facebook au soir de son périple.
Source : Facebook
Et vous ?
:fleche: Avez-vous migré vers la version 8.0 de MySQL ? Quels gains en avez-vous tirés ?
:fleche: Avez-vous déjà testé MyRocks de Facebook ? Qu’en pensez-vous ?
:fleche: À la suite du partage d’expérience de Facebook au sujet de la migration vers MySQL 8.0, pensez-vous que en vaut la peine ?
:fleche: Connaissez-vous d’autres moteurs de stockage qui offrent les mêmes avantages de MyRocks ? Lesquels ?
