Tutoriel – Déployer MySQL 5.7 InnoDB Cluster

août 21, 2018

Cet article remplace le précédent tuto : Tutoriel – Déployer MySQL innoDB Cluster.

Si tu utilises MySQL 8.0, alors lit plutôt ce tuto : Tutoriel – Déployer MySQL 8.0 InnoDB Cluster.

 

Je reçois pas mal de questions de clients et d’utilisateurs de MySQL 5.7, j’espère donc que ce post t’apportera l’essentiel des réponses et bonnes pratiques pour te permettre de déployer un cluster InnoDB avec MySQL 5.7.

De plus, les nouvelles versions de MySQL Router et de MySQL Shell amènent de sensibles améliorations qu’il faut que je te montre à tout prix 🙂


 

L’un des principaux besoins de mes clients est la Haute Disponibilité avec MySQL. On va voir, dans cet article, comment déployer et gérer un cluster MySQL 5.7 « from scratch » , sous la forme d’un tutoriel, grâce à la solution HA tout en un : MySQL (5.7) InnoDB Cluster.

Note: L’article traite de MySQL InnoDB Cluster, HA natif de MySQL Server (via le plugin Group Replication) avec pour moteur de stockage InnoDB, solution à ne pas confondre avec MySQL NDB Cluster (moteur de stockage NDB).

 

Le contexte

3 instances MySQL autonomes, <spoil altert> qui vont grâce au plugin MySQL Group Replication se transformer en une base de données distribuée.</spoil altert>

  • Instance MySQL 1 (mysql_5.7_node1) : 172.18.0.11; Nœud numéro 1 du cluster
  • Instance MySQL 2 (mysql_5.7_node2) : 172.18.0.12; Nœud numéro 2 du cluster
  • Instance MySQL 3 (mysql_5.7_node3) : 172.18.0.13; Nœud numéro 3 du cluster

1 instance applicative : 192.168.1.11; MySQL Router + mon application.

 

Note: J’utilise l’image Docker MySQL Server supportée par l’équipe MySQL d’Oracle.

Note: Je n’aborde pas dans cet article la redondance de MySQL Router. Plusieurs scénarios sont possibles, je te recommande de lire ça, ceci et cela.

 

MySQL Shell est installé sur toutes les instances.

En ce qui concerne les versions des logiciels, ce sont les plus récentes à ce jour (journée caniculaire du mois d’août 2018):

 

Note: Dans cet article j’utilise la dernière GA de MySQL 5.7. Je publierai un autre tuto avec MySQL 8.0. Cependant, en ce qu’il concerne MySQL Router et MySQL Shell, il faut TOUJOURS prendre la dernière version (branche 8.0).

 

Pour récapituler notre architecture, une image valant (au moins) 1000 mots, ça nous donne :

MySQL InnoDB Cluster PoC Architecture

 

Vérifier la configuration des instances

La première étape consiste à s’assurer que les instances MySQL sont correctement configurées pour l’utilisation de MySQL Group Replication, la couche haute disponibilité de notre architecture. A noter qu’il est préférable de provisionner ses instances déjà correctement configurées (comme détaillé dans cet article) pour MySQL Group Replication.

 

Note: J’utiliser le compte utilisateur root pour configurer le cluster, cependant ce n’est pas une obligation. Il est effectivement possible de créer un compte utilisateur spécifique (ou plusieurs), avec les droits qui vont bien (accès total sur les tables des méta-données d’InnoDB Cluster + des droits d’administration de l’instance MySQL). Plus d’info ici (Paragraphe « User Privileges) ».

 

La vérification de la configuration se fait grâce à MySQL Shell et la méthode dba.checkInstanceConfiguration() :

Dans mon cas, avec l’installation de MySQL 5.7 par défaut sous Ubuntu (avec l’image Docker), niveau configuration… bah j’ai tout à faire 🙂

La méthode renvoie un document JSON (pratique pour l’automatisation) avec la liste des tâches à effectuer pour être conforme… Configurons donc !

 

J’ai deux solutions :

  • 1/ je prépare mes instances « manuellement » (cette tâche peut bien évidemment s’automatiser e.g. Ansible, Puppet, Chef, …) comme expliqué dans l’article comment configurer un groupe.
  • 2/ je me connecte à chaque instance en local, et j’utilise la méthode : configureLocalInstance()

Et ensuite je ne dois pas oublier de redémarrer les instances 🙂

 

Soyons fou ! allons y pour la méthode 2 :

Ouppss!!! dba.configureLocalInstance ne fonctionne qu’en local, c’est-à-dire, si je suis connecté sur la machine hôte de l’instance MySQL (ce qui est une bonne chose). Du coup après m’être connecté à l’hôte 172.18.0.11 :

Note: Assure toi d’avoir les droits nécessaires pour mettre à jour le fichier de configuration de MySQL.

Les informations ajoutées dans le fichier de configuration se trouvent en fin de fichier :

172.18.0.11 est configurée !

Après redémarrage de l’instance MySQL, la sortie de checkInstanceConfiguration est beaucoup moins anxiogène :

OK ! Le membre est prêt pour faire parti d’un groupe.

La même procédure doit être appliquée sur les autres instances MySQL.

… <Quelques commandes de configuration>…

Et je me retrouve avec le résultat suivant:

All good!

 

Créer le cluster

Une fois les 3 instances correctement configurées, l’étape suivante consiste à créer le cluster avec createCluster. Cette méthode va être jouée sur le premier membre, l’instance MySQL sur  172.18.0.11,  elle va permettre de bootstrapper le cluster:

createCluster() prend comme paramètre le nom du cluster (pocCluster). Tu peux lui passer également quelques informations optionnelles comme la whitelist.

Tu peux ensuite vérifier l’état du nœud dans le cluster avec status() :

Notes : Assure toi que ton DNS (ou /etc/hosts) est correctement configuré, sinon tu vas avoir des soucis de connections…

 

L’ajouts des nœuds suivant se fait avec addInstance(), il est néanmoins conseillé d’exécuter checkInstanceState() au préalable pour s’assurer de la compatibilité des GTID sets :

Nœud 2

Au cas où l’instance ajoutée n’a pas un GTID set compatible avec le groupe checkInstanceState te le fait savoir :

En fonction du contexte, il faut alors soit restaurer une sauvegarde d’un membre du cluster sur l’instance problématique (celle qui diverge) ou alors si tu sais ce que tu fais, une synchronisation des GTIDs est toujours possible, voir un reset master.

 

Nœud 3

 

Le résultat final:

MySQL InnoDB Cluster PoC Architecture

Et voilà!

Un cluster MySQL Group Replication de 3 nœuds est déployé grâce à MySQL Shell !

La configuration actuelle est la suivante:

  • Nœud 1 (mysql_5.7_node1) = 172.18.0.11 : Primaire (lecture/écriture)
  • Nœud 2 (mysql_5.7_node2) = 172.18.0.12 : Secondaire (lecture seule)
  • Nœud 3 (mysql_5.7_node3) = 172.18.0.13 : Secondaire (lecture seule)

 

Si tu as été attentif, lors de l’ajout des nœuds (pareil donc pour la création du cluster), tu as noté que MySQL Shell me renvoi des « Warnings »,  cependant, rien de bien méchant !

En MySQL 5.7 la commande SET PERSIST n’existe tout simplement pas. Il n’est donc pas possible, à cette étape, d’automatiquement rendre  persistante la configuration ie l’écrire dans le fichier de configuration à distance (remote en bon franglais). Bref, en clair, la conf des nœuds  est en mémoire.

 

 

Persistance de la configuration

Pour rendre la configuration persistante, il faut alors exécuter, sur chacun des nœuds et après que le nœud soit configuré, la méthode (déjà vue)  dba.configureLocalInstance() :

A noter que cette opération ne peut se faire qu’en local.

Evidemment, à faire sur tout les autres nœuds:

Et le dernier:

Bien que pas obligatoire, je recommande de le faire systématiquement.

La suite ?

 

 

Configuration de MySQL Router

Les recommandations de MySQL sont d’installer MySQL Router sur la machine hôte de l’application, je vais donc l’installer sur la machine 192.168.1.11.

 

Note: Si tu ne peux (veux) pas mettre MySQL Router sur l’application, il va alors te falloir gérer le HA du Router. Plusieurs solutions sont envisageables comme :

 

 

Bootstrap MySQL Router

La première étape est le bootstrap:

Note: il se peut que tu rencontres un problème de permission. Probablement dû à la configuration de AppArmor… Google (ou équivalent) est ton ami 🙂 (si tu es sous Ubuntu click ici).

 

J’ai créé une configuration différente de celle par défaut, en personnalisant avec quelques options:

  • conf-base-port : le port proposé par défaut est 6446 pour la lecture/écriture. Dans mon cas, je veux utiliser le célèbre port 3306
  • directory : histoire de ranger tout le bazar de cette instance de Router dans le répertoire spécifié

La liste complète des options est disponible ici.

 

Pour résumer, 4 ports TCP ont été configurés, dont 2 pour les connexions MySQL traditionnelles:

3306 (au lieu de 6446 par défaut) : lectures / écritures pour le nœud primaire
3307 (au lieu de 6447 par défaut) : lectures seules pour les nœuds secondaires (en Round-Robin)
Et le pendant pour les connexions avec le protocole X (3308 & 3309 (au lieu de respectivement 64460 & 64470)), pour une utilisation NoSQL Document Store de MySQL.

 

Le fichier de configuration de MySQL Router contient quelques informations importantes, tel que le(s) port(s) à utiliser par l’application (comme vu précédemment) :

Il est évidemment possible de modifier ce fichier.

 

Ensuite, il faut démarrer MySQL Router avec le script start.sh

L’arrêt du Router se fait avec le script stop.sh (mais tu l’avais deviné)

Voilà pour MySQL Router !

 

 

Se connecter au cluster

A partir de maintenant, ton cluster et « up and running« . Ton application va donc devoir se connecter au port 3306 (car on l’a configuré comme cela, sinon c’est 6446 par défaut – je radote, je sais) pour utiliser la base de donnée. D’ailleurs du point de vue de l’application, la base de donnée est MySQL Router, sauf qu’en réalité ce n’est pas 1 instance, mais bel et bien 3 instances qui sont en backend et ceci en toute transparence (épatant! hein ?).

La partie utilisation du cluster est hors du scope de cet article, mais on peut facilement simuler le comportement de l’application avec un client MySQL (MySQL Shell ici) et MySQL router.

Je me connecte avec MySQL Shell en mode SQL (ça c’est l’applicatif), au cluster (à mysql_5.7_node1, nœud primaire InnoDB Cluster), par l’intermédiaire de MySQL Router en localhost (car je suis sur la machine 192.168.1.11) sur le port 3306.

Le paramètre report_host (défini dans mon fichier de configuration) me renvoi la valeur du  nœud 1, le primaire.

En cas d’arrêt du primaire, un nouveau va être automatiquement élu par le cluster (voir paragraphe failover plus bas) est la même commande me donnera un résultat différent:

 

 

 

Gestion des nœuds

Quelques commandes qui vont te simplifier la vie…

Performance_Schema

Quelques informations sont disponibles en SQL au niveau des instances.

Identifier le nœud primaire

 

Description des membres du cluster

 

 

Récupérer les méta-données d’un cluster

Les méta-données du cluster sont stockées sur les membres dans le schéma mysql_innodb_cluster_metadata :

Pour récupérer les informations relatives à l’état du cluster dans une nouvelle session il faut utiliser la méthode getCluster :

 

 

Failover

Le basculement niveau base de données (changement de primaire) est automatiquement géré par les membres du cluster entre eux.

Crash du noeud primaire (172.18.0.11)…

Nouveau primaire élu par le groupe : 172.18.0.13.

Et 172.18.0.11 est porté disparu (MIA).

 

Les données configuration cluster étant sauvegardées dans le fichier de configuration (voir paragraphe Persistance de la configuration), une fois le redémarré/réparé/restauré il fera automatiquement parti du cluster à nouveau. et il aura un rôle de secondaire.

En cas de configuration non persistante, un rejoinInstance() est nécessaire pour remettre le nœud dans le cluster. (voir paragraphe suivant Remettre un membre dans le groupe).

 

 

Remettre un membre dans le groupe

Nécessaire si la conf n’est pas persistante ou si la variable group_replication_start_on_boot = OFF.

Le nœud peut alors être remit dans le groupe avec la commande rejoinInstance() :

 

 

Supprimer une instance du groupe

Sans grande surprise, c’est la commande removeInstance

L’instance n’est alors plus listée dans les méta-données :

Pour la remettre dans le groupe, il faut donc rejouer le processus de l’ajout d’instance vu plus haut :

 

 

Perte du quorum

Si le cluster perd plus de la moitié de ses membres (crash ou split brain par exemple) il se retrouve dans un état assez désagréable, network partitioning, en clair il faut une intervention externe au cluster pour permettre aux membres restant de continuer à faire leur boulot.

 

Note: Par perte j’entend arrêt non prévu (crash). En cas d’arrêt normal ou propre, même si le cluster perd son quorum (dans ce cas présent arrêt normal de 2 nœuds), le nœud restant sait que les autres nœuds ne sont plus là (en clair pas de risque de split brain) donc le cluster continue de fonctionner. Mais c’est un cluster avec un seul nœud… 

 

Dans notre cas, avec 3 instances, il faut en perdre 2 d’un coup :

Perte des nœuds (crash) 172.18.0.11 & 172.18.0.12…  (Mayday, Mayday, Mayday!!!)

Le failover automatique ne peut pas s’enclencher, le nœud survivant (172.18.0.13) est bloqué.

Il faut donc intervenir :

Evidemment, sauf si tu es joueur 🙂 , il faut éviter de rester trop longtemps dans cet état.

Une fois les instances remisent en condition, il faut soit simplement les démarrer ou alors utiliser rejoinInstance() pour les remettre dans le cluster, en tant que secondaire.

 

 

Repartir après un arrêt total du cluster

La perte du quorum est une chose, mais il y a pire, perdre tout les nœuds…

En cas d’arrêt total du cluster i.e. toutes les instances sont éteintes, il faut utiliser, une fois les instances MySQL de nouveau démarrées  rebootClusterFromCompleteOutage() :

 

Le reboot doit se faire sur l’instance la plus à jour (ici la machine 172.18.0.13) :

Le membre sur lequel la commande est exécutée est le nouveau primaire.

 

Voilà c’est tout pour aujourd’hui 🙂

C’est très certainement l’un de mes derniers articles sur MySQL 5.7, cependant, vu le nombre élevé de retour que je reçois, je tenais à mettre à jour le tuto sur la version 5.7 de MySQL InnoDB Cluster.

 

Dans la même thématique :

 

Thanks for using MySQL!

 

2 Responses to “Tutoriel – Déployer MySQL 5.7 InnoDB Cluster”

  1. […] C’est ici. […]

  2. […] Si tu utilises MySQL 5.7 tu peux également mettre en oeuvre InnoDB Cluster, je te recommande cet article: Tutoriel – Déployer MySQL 5.7 InnoDB Cluster. […]

Leave a Reply