home Développement Web Nouveautés MySQL 5.7 : InnoDB Cluster, Document Store et MySQL 8.0 en prévision

Nouveautés MySQL 5.7 : InnoDB Cluster, Document Store et MySQL 8.0 en prévision

Il est temps de parler un peu de MySQL. C’est un produit que j’affectionne et que j’utilise tous les jours. La dernière version est la 5.7 à l’heure où j’écris ces lignes et elle apporte pas mal de nouveautés que je vais maintenant vous exposer.

InnoDB Cluster : la nouvelle haute disponibilité de MySQL

MySQL propose un nouveau système de cluster InnoDB qui met en avant une vraie haute disponibilité de MySQL. D’ailleurs pour MySQL, haute disponibilité rime avec :

  • Redondance des services/données
  • Réduire l’impact d’une panne
  • Assurer un basculement lors d’un problème ou lors d’une maintenance
  • Récupération de la perte de la redondance

Il existe actuellement 3 types de réplication MySQL :

  • réplication asynchrone (async)
  • réplication semi-synchrone (semi-sync)
  • réplication de groupe (group replication)

C’est ce dernier type qui est nouveau dans les dernières versions MySQL car comme vous allez le voir cette méthode est très puissante en plus d’être bien pensée.

Jusqu’à présent, MySQL proposait un système de réplication simple où nous avions idéalement un serveur maître et plusieurs esclaves. Les esclaves se basaient sur les logs binaires pour répliquer la base de données du maître. Le problème dans ce cas de figure c’est que suivant la performance du réseau la réplication pouvait être retardée et il n’y a que les esclaves récupèrent chacune des transactions du maître. En clair, il était très fréquent de se retrouver avec des esclaves ne correspondant pas du tout aux données présentes sur le maître ce qui n’était pas très fiable pour le coup. En plus pour couronner le tout, rien n’est automatisé. Si votre maître tombe, c’est à vous de faire le nécessaire pour définir votre nouveau maître et donc votre nouvelle stratégie de réplication. Question haute disponibilité ce n’est vraiment pas top.

Heureusement ce temps est révolu avec les outils MySQL Group Réplication, MySQL Router et MySQL Shell.

MySQL Group Réplication

MySQL Group Réplication est un plugin fourni avec MySQL et développé pour MySQL et par MySQL.

Il implémente la théorie « Replicated Database State Machine ». Il permet d’écrire sur tous les membres du groupe (noeuds du cluster ». Il détecte les conflits et permet la récupération distribuée automatique. Cerise sur le gâteau : il est supporté sur toutes les plateformes MySQL (Linux, Windows, OSX, FreeBSD).

La haute disponibilité est bien respectée puisqu’il n’est plus nécessaire d’effectuer un basculement du rôle des serveurs manuellement, cela se fait automatiquement. Il gère également les pannes.

Mais comment fonctionne MySQL Group Replication ?

Grâce à la réplication des « transactions » qui se fait de manière synchrone en certifiant la transaction (certification) puis il applique les changements de façon asynchrone.

Explication en images :

Le premier serveur reçoit la transaction et il la distribue aux autres serveurs qui composent le noeud.

La logique de MySQL Group Réplication se met en place et il utilise un système de majorité. C’est à dire que dans notre exemple notre noeud est composé de 3 serveurs si 2 d’entre eux répondent qu’ils l’ont bien reçu alors la majorité est appliquée (1+1).

Remarque : le 3ème serveur a juste reçu la transaction mais il n’a pas encore répondu que c’était ok pour lui, ce qui n’est pas grave puisque la majorité est respectée.

La seconde étape est le processus de certification de la transaction, celle qui va dire si oui ou non le serveur peut l’appliquer. Nous sommes désormais dans de l’asynchrone. Dans le cas du premier serveur, la certification se génère puis le commit est appliqué. La certification pour les 2 autres serveurs se fait de manière asynchrone donc en décaler. La certification commence puis s’applique.

Puis le commit est appliqué. Pour information, la certification a pour unique but d’informer si la transaction peut être écrite.

Quelles sont les principales exigences pour utiliser cette technologie ?

  • Il faut absolument que vos tables utilisent le moteur InnoDB. Si vous continuez encore à utiliser MyISAM en 2017, je ne peux vous dire qu’une chose : honte à vous :-)!
  • Chacune de vos tables doit posséder une clé primaire
  • Il vous faut un réseau en IPv4 (IPv6 sera supporté prochainement)
  • Avoir un bon réseau avec peu de latence, ça aide
  • Un noeud peut être composé que de 9 serveurs maximum
  • log-bin doit être activé et seul le format ROW est supporté

Quelles sont les principales limites de cette technologie ?

  • le checksum des événements répliqués n’est pas supporté
  • Les savepoints ne sont pas supportés avant MySQL 5.7.19 et 8.0.1

MySQL Router

MySQL Router est un middleware léger qui fournit un routage transparent entre l’application et n’importe quel serveur MySQL. C’est lui qui permet d’acheminer efficacement le trafic vers les serveurs MySQL appropriés. C’est un outil complémentaire à la haute disponibilité.

Ce qui est génial avec cet outil c’est que vous n’avez rien à configurer. En fait, il se configure automatiquement via les métadonnées du MySQL InnoDB Cluster.

Pour faire simple, votre application ne se connecte pas à un serveur MySQL que vous avez préalablement choisi mais elle va se connecter à MySQL Router qui lui va se charger pour vous de rediriger la demande vers le bon serveur.

MySQL Shell

MySQL Shell est une interface interactive en Javascript, Python, ou SQL qui prend en charge le développement et l’administration du serveur MySQL. MySQL Shell peut être utilisé pour effectuer des requêtes et des modifications de données ainsi que diverses opérations d’administration. Mais pas que.

Il fournit :

  • la possibilité d’effectuer des opérations interactives et de « batch »
  • l’utilisation d’API CRUD Document et relationnelles
  • un accès aux protocoles MySQL Standard et X

Il est tout à fait possible d’utiliser cet outil pour par exemple votre cluster InnoDB MySQL.

Quelques compléments d’informations

La solution complète de MySQL InnoDB Cluster permet maintenant de gérer plusieurs maîtres dans un même cluster (ce qui n’était pas le cas auparavant).C’est très intéressant pour faire de la répartition de charge lorsque vous avez une grosse application avec des milliers d’accès et requêtes par minute.

La solution est capable de détecter qu’un serveur maître est indisponible pour rechercher l’esclave le plus à jour afin de le faire devenir le nouveau maître et ceux de manière transparente et automatique pour les utilisateurs.

Document Store : le NoSQL à la sauce MySQL

Depuis que MySQL est passé en 5.7, il apporte une nouvelle fonctionnalité appelée le Document Store, le NoSQL à la sauce MySQL.

Pour rappel le NoSQL est un système de stockage de données très flexible puisque que contrairement aux bases de données relationnelles on a nul besoin d’un schéma. Aucune formalisation n’est nécessaire.

Concrètement, le Document Store de MySQL permet de stocker des données sous format JSON.

Pourquoi MySQL a t-il fait ce choix ?

Tout simplement parce que ce format est très utilisé dans nos applications. En effet, celui-ci est très proche du frontend, natif en JavaScript et très utilisé en Node.js

Voici un résumé des avantages du NoSQL et du SQL :

Et si on faisait du NoSQL dans du MySQL ?

C’est, je pense, l’énorme point fort du NoSQL de MySQL car oui je vous avais bien lu il est possible d’utiliser MySQL d’un côté, NoSQL de l’autre mais aussi de faire cohabiter le NoSQL dans du SQL classique.

Il est donc possible avec ces technologies de récupérer une valeur d’un objet JSON contenu dans le Document Store et de l’exploiter dans du SQL classique c’est à dire dans une base de données relationnelle MySQL. MySQL est capable de générer une colonne pour l’une de vos tables (on dira alors que c’est une colonne virtuelle) afin que vous puissiez l’exploiter dans vos requêtes SQL.

Encore plus fort, cette colonne virtuelle peut être indexée, une clé étrangère ou même une vue.

Comment bénéficier du Document Store dans MySQL ?

Si vous téléchargez et que vous installez MySQL 5.7, le wizard de MySQL va vous proposer d’activer X Plugin. X Plugin permet de transformer MySQL en Document Store.

Mon avis sur la solution

C’est une solution très jeune mais très prometteuse. MySQL propose une bonne cohésion entre le MySQL et le NoSQL. Mieux encore MySQL a permis de faire communiquer et travailler ces 2 types de bases de données, ce qui est très différent d’un Redis ou d’un MongoDB par exemple.

Le choix d’utiliser JSON pour le NoSQL est un très bon choix car très facile à prendre en main.

Reste à suivre l’affaire concernant les performances de recherche de données dans le NoSQL à partir du MySQL. J’ai des doutes sur les performances que MySQL peut promettre sur des gros volumes de données mais comme la technologie est récente il faut lui donner sa chance comme on dit.

MySQL 8.0 en prévision

Nous sommes actuellement à la version 5.7 et la prochaine version sera la 8.0. Pourquoi y’a t-il un saut de version entre les 2 ? Il faut savoir que MySQL 6 a été abandonné lorsque Oracle a racheté MySQL. MySQL 7 quant à lui existe déjà, c’est la version MySQL Cluster. Donc naturellement c’est la version 8.0 qui va bientôt se montrer et elle a l’air très prometteuse .

Gaëtan Cottrez

CHOOSE A JOB YOU LOVE AND YOU WILL NOT HAVE TO WORK A DAY IN YOUR LIFE

Partagez cette article sur :
Gaëtan Cottrez

Gaëtan Cottrez

CHOOSE A JOB YOU LOVE AND YOU WILL NOT HAVE TO WORK A DAY IN YOUR LIFE

2 réflexions sur “Nouveautés MySQL 5.7 : InnoDB Cluster, Document Store et MySQL 8.0 en prévision

  1. Bonjour Gaetan. Voila un article très détaillé qui apporte pas mal de réponses à mes interrogations, mais je me pose encore qq questions. MySQL Group Replication apporte de la haute disponibilité grâce au Maitre-Maitre c’est trés clair.
    Mais concernant la scalabilité, j’ai un doute. Si tous les maitres travaillent en même temps lorsqu’ils reçoivent une requête, en quoi le système permet-il de faire de la répartition de charge ?
    Je veux dire que si tous les bases MYSQL se mettent au travail pour traiter la requête, ou se trouve le gain ?

    Dans mon cas aujourd’hui, j’ai un serveur MYSQL qui devient lent en réponse, et je cherche une solution de répartition de charge sans avoir besoin de toucher au code car je ne veux pas reecrire toutes les requêtes.

    1. Bonjour Antoine,

      L’outil MySQL Router gère de manière automatique les répartitions de charge si besoin. L’outil va questionner tous les membres de ton cluster pour savoir vers lequel il va rediriger l’utilisateur qu’il fait une demande. Si l’un de tes serveurs est « down » ou en surcharge, le Group Replication sera en mesure de le dire à MySQL Router.

      Maintenant pour ton problème de lenteur sur ton serveur sans savoir le nombre de connexions et de requêtes qu’il subit chaque minute, c’est difficile vraiment de savoir d’où vient le problème mais ce que je vous conseille par expérience c’est de procéder par étape à savoir la partie serveur en premier en vérifiant si vous ne pouvez pas lui allouer des ressources supplémentaires (CPU + RAM). Ensuite la mise à jour MySQL où par expérience j’ai migré des bases de données d’une MySQL 5.5 à une 5.7 (la dernière donc). Les performances au niveau de certaines requêtes longues sont devenues très rapides au changement de version.

      Enfin si tout cela ne solutionne pas vos problèmes de lenteur, alors il faut revoir la conception de votre application au niveau des requêtes SQL malheureusement. MySQL Workbench sera ton ami pour identifier et analyser les requêtes lentes.

      Enfin si tu as trop de connexions/requêtes simultanées, la répartition de charge pourra pallier ton problème.

      Bien à toi

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Apprenez gratuitement les 7 secrets de l'art de bien coder
Vous saurez comment avoir les bons réflexes, une bonne méthodologie de travail, une meilleure lisibilité et sécurité de votre code