MySQL InnoDB Cluster avec Group Replication

Nous allons nous intéresser à la solution HA native de MySQL : MySQL InnoDB Cluster avec le plugin Group Replication disponible depuis la version 5.7.

Attention à ne pas confondre cette technologie avec MySQL NDB Cluster, qui repose quant à lui sur un moteur de stockage NDB.

MySQL HA : les différents mode de réplication

  • Asynchrone => MySQL Replication
    • Il s’agit de la réplication par défaut de MySQL. De manière parallèle, MySQL acquitte les transactions côté application et réplique les transactions vers le(s) slave(s).
    • Les performances sont au rendez-vous, mais au détriment du risque de perte de données en cas de défaillance de la base Master.
  • Semi-Synchrone => MySQL Replication avec plugin semisynchronous
    • A partir de MySQL 5.5+ et amélioré en MySQL 5.7.
    • La Master attends que les transactions soient reçues par la Slave et de manière parallèle acquitte les transactions coté client et applique les changements sur la Slave.
    • Performance intermédiaires, mais sans perte de données
  • Virtuellement-Synchrone => MySQL InnoDB Cluster avec MySQL Group Replication
    • Les transactions sont appliquées de manière parallèle sur tous les nœuds du cluster.
    • Mode Multi-Master disponible.
    • Performances intermédiaires, idéal pour les petites transactions. Pas de perte de données.
  • Synchrone => MySQL NDB Cluster
    • Le cluster attend que tous les nœuds du cluster aient appliqué la transaction avant d’acquitter la transaction côté applicatif.
    • Latences plus élevées, idéal pour les petites transactions. Pas de perte de données.

Sur quoi repose MySQL InnoDB Cluster ?

MySQL InnoDB cluster =

  • MySQL Group Replication
  • + MySQL Shell
  • + MySQL Router

MySQL Group Replication est un plugin MySQL développé par Oracle et disponible depuis la version 5.7.17.

MySQL Shell est une interface en ligne de commande (CLI), qui permet d’administrer le cluster au travers de l’AdminAPI.

MySQL Router permet la redirection automatique des connexions clientes vers les nœuds du cluster.

Group Réplication : le cœur de MySQL InnoDB Cluster

Le plugin Group Replication developpé par Oracle est disponible sur toutes les plateformes supportées par MySQL (Linux, Windows, Solaris, OSX, Freebsd). Comme il est nativement intégré dans le serveur MySQL et s’intègre aux composants de la base (InnoDB, Réplication, GTID, Performance Schema, …), il n’y a aucun besoin de télécharger de plugin supplémentaire.

Le plugin permet l’écriture simultanée sur l’ensemble du cluster (cluster nodes) de manière simultanée en préservant la consistance des données.

Chacun des nœuds représente une instance de la même base de données.

Un minimum de 3 membres est nécessaire, dû à la nécessité du cluster d’obtenir un quorum pour éviter les situations de split-brain. Le système est donc tolérant aux pannes et permet de gérer les crash et les pannes avec une reconnexion automatique des nœuds au cluster.

Les failovers et les transitions de rôles sont automatiques en cas de défaillance, il n’y a pas besoin d’actions manuelles ni de scripting complexe.

Group Replication permet également de créer des topologies permettant les mises à jour sur tous les nœuds (topologies Multi-Master).

La mise en place de la Haute-Disponibilité est donc grandement facilitée sur MySQL.

Cas d’usages

Scaling-out

Une utilisation typique de Group Replication est le scaling-out des lectures. Si une application requiert un nombre plus important de lectures au cours de la montée en charge, il est possible d’ajouter très simplement de nouvelles Slaves en les intégrant au cluster.

Tolérance aux pannes / Haute disponibilité

Que l’on ait déployé une topologie Single-Primary ou Multi-Primary, la haute disponibilité est gérée de manière quasi transparente pour les applications. On peut donc de manière élastique gérer de manière dynamique le nombre de serveurs nécessaires en fonction du workload.

Gestion des transactions

  • Execution Locale : Group Replication commence à répliquer une transaction lors de la phase de COMMIT, juste avant d’écrire dans les binary logs
  • Envoi vers tous les membres du cluster : Les transactions sont alors broadcastées sur le réseau via le protocole de communication Paxos
  • Certification indépendante de chaque transaction par les nœuds : Chaque membre du cluster reçoit les transactions dans l’ordre et exécute les algorithmes de certification afin de déterminer si les transactions peuvent être appliquée de manière sure.
  • Application Asynchrone : sur chacun des nœuds distants, les transactions certifiées sont écrites dans les relay-logs et appliquées de manière asynchrone. Sur le nœud local, la transaction peut alors être commitée dès lors qu’elle a reçu l’acquittement de la majorité des nœuds du cluster.

 

Résolution des conflits

Lors d’une transaction, un lock local (InnoDB) a lieu. Le moteur de réplication assume de manière optimiste (Optimistic Locking) qu’il n’y aura pas de conflit sur les autres nœuds (aucune communication n’a lieu vers les autres serveurs à ce stade).

La résolution de conflit a lieu par la suite lors de la phase de certification au moment du commit : Le premier à réaliser le commit l’emporte.

L’inconvénient de l’Optimistic Locking est qu’il est plus susceptible de se produire de conflits lors des transactions longues ou volumineuses.

Les pré-requis de Group Replication

  • Pas de support des tables sans PK,  toutes les tables à répliquer doivent posséder une clé primaire
  • Les données doivent être stockées dans le moteur InnoDB
  • IPv4 uniquement : la communication utilisée entre les serveurs du cluster se fait pour le moment uniquement via iPv4
  • Group Réplication est conçu pour être déployé sur un cluster dont les nœuds sont proches géographiquement. La latence et la bande passante sont des critères décisif pour garantir de bonnes performances.
  • Activation des log-bin nécessaire et Binlog_format = ROW
  • Activation des GTID (Global Transaction Identifiers)
  • Les metadonnées de réplication doivent être stockées dans les tables system :
    • –master-info-repository=TABLE
    • –relay-log-info-repository=TABLE
  • Writeset extraction activé : –transaction-write-set-extraction=XXHASH64
  • log-slave-updates activé

MySQL Router

MySQL Router est un middleware qui fournit un service de routage transparent entre les applicatifs et les serveurs MySQL backend.

L’interfaçage (bootstrap) avec les métadonnées du cluster InnoDB est automatique, il n’y pas de configuration à effectuer. Le routage est alors  automatique vers les serveurs MySQL appropriés en fonction des rôles de ces derniers (Primary / standby read-Only).

MySQL Router propose deux endpoints sur deux ports différents : un pour les accès Read/Write, un pour les accès Read-Only. C’est donc à l’application de choisir vers quel endpoint s’adresser, il n’y a pas de fonctionnalités de type Read/write splitting.

Toutefois, Il est possible d’utiliser le cluster InnoDB avec des Routeurs/proxy tiers (ProxySQL supporte Group Replication), afin de bénéficier de telles fonctionnalités avancées.

Typiquement, on installera le MySQL Router sur chaque serveur d’application ou sur chacun des serveurs de bases de données.

MySQL Shell

MySQL Shell est l’utilitaire en ligne de commande utilisé pour administrer le cluster. Il permet de masquer la complexité de configuration, de provisionning et d’Orchestration du cluster au travers de l’AdminAPI :

  • create clusters
  • get cluster info
  • start/stop MySQL Instances
  • Validate MySQL Instances…

Il permet le scripting et est multi-langage : Javascript, Python et SQL. Il peut être utilisé en mode batch ou interactif.

Supervision et Monitoring

MySQL Enterprise Monitor 4.0 supporte de manière native les clusters Group Replication :

  • Monitoring et alerting
  • Représentation graphique des topologies des clusters
  • Métriques détaillées et graphiques associés
  • Suggestion de best-practices

Les vues du schema performance_schema permettent également d’interroger le statut de réplication du cluster.

Exemple de déploiement d’un Cluster InnoDB

Afin de pouvoir déployer un cluster, il faut au minimum 3 serveurs. Toutefois, MySQL permet de réaliser une installation de type Sandbox afin de se familiariser avec la technologie, plusieurs membres du même cluster sont alors installés sur le même host. Nous ne traiterons pas ici le cas d’installation de type Sandbox.

Creation du user d’administration

Nous commençons tout d’abord par créer un user d’administration du cluster :

Ajout des pré-requis

Afin de permettre à la GROUP REPLICATION de fonctionner, les paramètres suivants sont obligatoires et doivent être ajoutés au fichier my.cnf se situant dans le répertoire d’installation de mysql/

Ajouter ces paramètres à la fin de la section mysqld :

Chaque serveur MySQL doit avoir un server_id différent.

Vérification des pré-requis

Installation du plugin group_replication

A partir de ce stade, la base de données Master faisant office de référence, est prête à être dupliquée vers les autres membres.

Copie Physique de la base master

Nous réalisons à cette étape une copie de la base de données modèle afin de la dupliquer sur les autres serveurs.

Cette copie peut se faire au choix en utilisant différents systèmes de sauvegarde/restore (mysqldump, mysql backup) ou bien par copie physique des fichiers (arrêt de la base nécessaire).

Avant de démarrer chaque instance de nouveau nœuds, il est nécessaire d’effectuer les taches suivantes.

Générer un nouveau server-uuid et modifier le server-id

Après avoir importé une copie du nœud master, il est impératif de générer un nouveau server-uuid, sur chaque nouveau nœud :

Il suffit de supprimer le fichier auto.cnf. Un nouveau server-uuid sera automatiquement généré au prochain démarrage.

Comme mentionné précédemment, il est nécessaire de modifier le server-id dans le my.cnf afin que celui-ci soit unique.

L’instance peut alors être démarrée.

Configuration de chaque instance pour MySQL Group Replication

 

Création du cluster InnoDB

La creation du cluster s’effectue depuis le nœud primary (ici nœud ayant pour server-id = 1 sur server1).

Nous créons ici un cluster en mode « single-primary » et l’appellons « prodCluster ».

Le cluster est initialisé, nous pouvons ajouter à présent chacun des nœuds du cluster. Pour le 2ème nœud :

Procéder de même pour le 3ème serveur.

Les warnings remontés par l’outil mysql shell nous indiquent qu’il faut à présent faire « persister » dans le fichier my.ini les changements de configuration dû à la configuration du cluster. Nous sommes ici sur du MySQL 5.7 et la commande SET PERSIST n’est disponible qu’à partir de la version 8.

Chaque ajout de nouveau nœud nécessitant de faire persister les modifications de configuration du cluster, nous réalisons sur chacun des nœud l’application des modification une fois tous les nœuds ajoutés au cluster.

Enregistrement de la configuration du cluster sur chaque nœud

Comme mentionné précédemment, nous faisons persister la configuration cluster grâce à mysql shell, au travers de la commande « dba.configureLocalInstance ».

Ainsi, localement sur chacun des nœuds, nous lançons la commande :

 

Confirmation du fonctionnement du cluster

Afin de s’assurer que le cluster est bien fonctionnel, nous interrogeons ce dernier pour connaitre son statut ainsi que sa topologie, depuis n’importe quel nœud nous utilisons mysql shell :

Nous voyons ici que le nœud server1 est master (R/W) et les deux autres nœuds sont slave (R/O).

Le cluster est fonctionnel.

Déploiement de MySQL Router

Nous déployons ici MySQL Router sur les serveurs d’application de la manière suivante :

 

About benjamin.bauer

Benjamin BAUER has written 1 post in this blog.

Laisser un commentaire

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

%d blogueurs aiment cette page :