Configurer ProxySQL 1.4 pour MySQL 5.7 Group Replication

janvier 9, 2018

Toute architecture de base de données se doit de se reposer sur 3 piliers, la supervision (monitoring) , la sauvegarde/restauration et la haute disponibilité. Mon premier article de l’année 2018  concerne l’un des meilleurs combos du moment, en matière de haute disponibilité niveau base de données :
MySQLProxySQL

 

Note 1: la réplication native (MySQL replication) reste évidemment une alternative de premier plan pour les besoins de haute dispos. D’ailleurs ProxySQL la gère également nativement.

Note 2: ProxySQL a pléthore de fonctionnalités, toutefois le but de cet article est son utilisation dans un contexte MySQL Group Replication.

 

ProxySQL est compatible avec MySQL Group Replication depuis la version 1.3 voir : Configurer ProxySQL pour MySQL Group Replication. Cependant, la version 1.4 supporte nativement MySQL Group Replication. Il est donc plus facile d’utiliser ensemble ces 2 technologies populaires, et c’est ce que nous allons voir immédiatement.

 

Dans cet article je vais faire les hypothèses suivantes :

 

MySQL Group Replication

Caractéristiques

  • Version du serveur : 5.7.20
  • Version du plugin : 1.0
  • Nœud 1 : mysql_node1, 172.22.0.10 : 3306
  • Nœud 2 : mysql_node2, 172.22.0.20 : 3306
  • Nœud 3 : mysql_node3, 172.22.0.30 : 3306

Ces caractéristiques représentent donc un cluster MySQL Group Replication de 3 nœuds, installé, déployé et qui fonctionne :

MySQL Enterprise Monitor nous donne une vue graphique du cluster et de son état (click to enlarge) :

MySQL

 

Le cluster est en mode single primary, c’est à dire qu’un seul nœud est disponible en lecture & écriture à la fois (alors que les 2 autres nœuds ne sont accessibles qu’en lecture seule).

MySQL Enterprise Monitor nous montre (click to enlarge):

MySQL

 

Je vais enrichir le schéma sys de MySQL 5.7 avec le script: addition_to_sys.sql

 

Je charge donc les fonctions et les vues dans le noeud primaire (mysql_node1) du cluster :

 

Ce script va permettre à ProxySQL de superviser l’état des nœuds du cluster.
e.g.

 

La dernière étape de configuration coté cluster, consiste en la création des utilisateurs de supervision qui vont être utilisés par ProxySQL (oui, il y a bien un rapport avec l’étape précédente) :).

Là encore j’utilise le primaire du groupe :

 

Il nous reste à configurer ProxySQL maintenant !

 

ProxySQL

Caractéristiques

  • Version du proxy : 1.4.4
  • Interface d’administration : 172.22.0.2:6032
  • Connexion au cluster : 172.22.0.2:3306

 

 

La configuration de ProxySQL peut se faire en ligne, ce qui est évidemment une très bonne chose.

Commençons par se connecter à l’interface d’administration sur le port 6032 avec l’utilisateur admin et le mot de passe… admin (!)

Données par défauts qui peuvent et qui doivent être changées dans la vraie vie.

 

Configurer les serveurs

Première étape, ajouter les nœuds du cluster au proxy :

 

Configurer les hostgroups

J’ai fais une présentation succincte des objets de ProxySQL 1.3 la dernière fois : Configurer ProxySQL pour MySQL Group Replication

La version 1.4 à quelques différences, la plus notable dans notre contexte est l’apparition de la table  mysql_group_replication_hostgroups :

 

La meilleure description trouvée est disponible dans l’article de mon collègue @LefredMySQL Group Replication: native support in ProxySQL

Je cite

 »

There are many new columns, let’s have a look at their meaning:

Column Name Description
writer_hostgroup the id of the hostgroup that will contain all the members that are writer
backup_writer_hostgroup if the group is running in multi-primary mode, there are multi writers (read_only=0) but if the amount of these writer is
larger than the max_writers, the extra nodes are located in that backup writer group
reader_hostgroup the id of the hostgroup that will contain all the members in read_only
offline_hostgroup the id of the hostgroup that will contain the host not being online or not being part of the Group
active when enabled, ProxySQL monitors the Group and move the server according in the appropriate hostgroups
max_writers limit the amount of nodes in the writer hostgroup in case of group in multi-primary mode
writer_is_also_reader boolean value, 0 or 1, when enabled, a node in the writer hostgroup will also belongs the the reader hostgroup
max_transactions_behind if the value is greater than 0, it defines how much a node can be lagging in applying the transactions from the Group, see this post for more info

 »

Pas mieux 🙂

Notre configuration est la suivante :

  • writer_hostgroup = 2
  • backup_writer_hostgroup = 4
  • reader_hostgroup = 3
  • offline_hostgroup = 1
  • active = 1
  • max_writers = 1
  • writer_is_also_reader = 1
  • max_transactions_behind = 0

Ce qui nous donne :

 

Configuration de la supervision

Un peu plus haut on a créé un utilisateur de supervision dans le cluster.

C’est cet utilisateur que va utiliser ProxySQL pour être au courant de l’état des différents nœuds du cluster :

 

Création de l’utilisateur applicatif

L’application se connecte au serveur MySQL avec un utilisateur et un mot de passe (dans le meilleur des cas :D).

Cet utilisateur doit bien évidemment exister dans les différents serveurs qui composent le cluster, avec les droits MySQL qui vont bien.

Cet utilisateur doit également être renseigné dans ProxySQL :

 

Modifier le port d’écoute

Par défaut l’application va se connecter au cluster à travers ProxySQL en utilisant le port 6032 (dans notre cas: 172.22.0.2:6032)

Dans la vraie vie, les applications se connectent à MySQL bien souvent en utilisant le port MySQL par défaut, 3306.

ll est donc possible (pas obligatoire donc) de modifier le port de ProxySQL pour qu’il écoute sur 3306 :

 

Note 3: Pour une mystérieuse raison, ce dernier changement de configuration ne se charge pas à chaud (runtime). En clair je dois donc redémarrer ProxySQL pour que ce changement soit pris en compte.

 

 

La configuration de ProxySQL pour MySQL Group Replication est maintenant terminée \o/

J’en profite pour vous présenter une nouvelle table dans la version 1.4 : mysql_server_group_replication_log.

Elle est utile pour la supervision :

 

Playtime

Pour rappel, le workflow est le suivant:

  • L’application se connecte à ProxySQL (i.e. elle ne voit et ne connait que le proxy)
  • ProxySQL récupère les transactions et les redirigent sur le noeud primaire du cluster MySQL Group Replication.
  • En cas de crash/arrêt du Primaire,
    • MySQL Group Replication élit un nouveau primaire
    • ProxySQL identifie le nouveau primaire et dirige les transactions vers ce nouveau primaire

 

L’application doit donc être configurée pour se connecter à ProxySQL. Par exemple, si mon application est Drupal mon fichier settings.php ressemblera à l’extrait de code suivant :

  • Utilisateur : app_user
  • Mot de passe : app_pwd
  • Port : 3306 (ProxySQL)
  • Host : 172.22.0.2 (ProxySQL)

CQFD!

 

Simulons tout cela en ligne de commande !

Mon application est le client texte mysql. Pour simplifier mes commandes je crée au préalable un fichier de configuration pour le client mysql qui contient les informations suivantes :

 

Mes serveurs sont configurés avec la variable report_host renseignée (voir http://dasini.net/blog/2016/11/08/deployer-un-cluster-mysql-group-replication/).

Le primaire du cluster est encore mysql_node1 (pas encore de database failover depuis le début de l’article, mais on y arrive).

 

Maintenant testons le failover avec un exemple légèrement plus complexe.

Au préalable, créons la table test.poc au format InnoDB :

 

L’application test jouera les 2 requêtes suivante :

  • INSERT INTO test.poc (host) VALUES (@@report_host);
  • SELECT * FROM test.poc;

 

Grâce à ces 2 requêtes, le petit scripts ci-dessous et à un kill -9 opportun,  on va être en mesure de suivre les processus de routage (ProxySQL) et de failover (MySQL Group Replication).

Les transactions 1 & 2 (ids 2 et 9) sont jouées sur mysql_node 1.

A partir de la troisième transaction (ids 11 et 18), elles sont jouées sur le nouveau primaire mysql_node 3, car mysql_node 1 a crashé.

Terminons ce tuto en image.

 

MySQL Enterprise Monitor

Comme énoncé en introduction, une architecture de base de données doit de se reposer sur les 3 piliers : Monitoring / Backup process / High Availability.

Je vous présente de façon succincte, MySQL Enterprise Monitor (MEM) qui est l’outil de supervision de MySQL, disponible avec la version commerciale de MySQL (MySQL Enterprise Edition). Il permet la détection et l’alerte des problèmes, la supervision des serveurs, des backups… des différents types de réplications, y compris Group Replication.

Pour essayer les différents outils Enterprise, c’est par ici.

Ci-dessous quelques captures d’écrans des différents états du cluster supervisé par MySQL Enterprise Monitor (click to enlarge):

MySQL

MySQL

MySQL

MySQL

MySQL

MySQL

MySQL

MySQL

 

 

Le(s) mot(s) de la fin

Fin 😀

Vous connaissez déjà les technologies, MySQL Replication et MySQL semi-synchronous Replication.

MySQL Group Replication est un outil supplémentaire qui apporte notamment la notion de « Automatic Database Failover » qu’il manquait à MySQL.

Ces architectures s’utilisent la plupart du temps avec un proxy. ProxySQL est sans aucun doute aujourd’hui l’une des meilleures solutions pour MySQL.

 

Note 4: MySQL propose MySQL InnoDB Cluster, package comprenant MySQL Group Replication, MySQL Router et MySQL Shell.
Tuto : Tutoriel – Déployer MySQL innoDB Cluster

 

 

References

dasini.net

MySQL Group Replication

ProxySQL

 

Thanks for using MySQL!

 

1

Où télécharger MySQL ?

juillet 24, 2017

Read this post in English

Lorsque l’on démarre un nouveau projet, il est en général conseillé de partir sur la version la plus récente de MySQL, histoire de profiter des toutes dernières fonctionnalités mais aussi (surtout ?) d’être certain d’être à jour au niveau des patchs de sécurité.

Powered by MySQL
Cet article centralise les différentes URLs pour télécharger la base de données Open Source la plus populaire au monde.

 

MySQL Community Edition

Si tu cherches le dernier binaire compilé, les paquets client et/ou serveur, ou tout simplement les sources à compiler toi même, en 64 ou 32 bits, pour l’OS de ton choix (Linux, Windows, Mac, Solaris, FreeBSD) :

 

Dépôts Linux

Sur ta distribution Linux, le MySQL embarqué est bien souvent très ancien (ou pire encore, tu peux te retrouver, à ton insu, avec autre chose que MySQL) .

La solution ? Installer le dépôt MySQL qui permet une installation aussi simple que pratique de la dernière GA, mais aussi des autres produits de l’écosystème :

 

Autres

Image Docker, créée, maintenue et supportée par MySQL :

 

Dépôt GitHub créé, maintenu et supporté par MySQL :

 

MySQL NDB Cluster

MySQL NDB Cluster, la base de données distribuée temps réel est disponible dans les dépôts ci-dessus, ainsi que dans ces 2 URLs dédiées :

 

MySQL Enterprise Edition

Si tu es client Oracle MySQL connecte toi à ton compte My Oracle Support :

 

L’Oracle Software Delivery Cloud (e-delivery) permet de tester les produits MySQL Enterprise :

 

MySQL Enterprise Edition est également disponible sur le Cloud, exclusivement sur Oracle Cloud :

 

Anciennes versions

Parfois on n’a pas le choix, une version précise est impérative. Tu la trouveras dans les archives :

 

 

Thanks for using MySQL!

 

2

Topo sur les premières versions publique de MySQL

juillet 19, 2017

Read this blog post in English

j’ai régulièrement l’opportunité de rencontrer les utilisateurs des produits MySQL, et je suis toujours un peu surpris de voir des applications critiques qui tournent sur des versions pas vraiment récente (pour employer un euphémisme) 🙂

La bonne nouvelle est que manifestement les anciennes versions de MySQL sont suffisamment stables et performantes pour faire tourner du business moderne. Cependant, et ce même si je comprend bien qu’il est parfois pertinent de figer toutes les couches d’une architecture, il est souvent dommage de ne pas profiter des dernières améliorations d’un point de vue, performance, stabilité, sécurité et bien entendu des nouvelles fonctionnalités de la dernière GA:

 

La notion de temps étant relative, je te propose un petit jeu de mise en perspective des dates des premières versions publique (non GA), une sorte de blind-test MySQL…

 

MySQL 3.22 | 1998

  • Voiture la plus vendue en France : Renault Clio II (phase 1)
  • Meilleure vente de Singles en France : Garou, Daniel Lavoie et Patrick Fiori, Belle
  • Evénement : 12 juillet 1998, la France bat le Brésil lors de la finale de la coupe du monde de football 3 buts à 0

 

Sources:
http://dev.cs.ovgu.de/db/mysql/News-3.22.x.html
http://www.auto-moto.com/occasion/souvenirs-souvenirs/voiture-la-plus-vendue-par-annee-les-statistiques-de-1947-a-nos-jours-55637.html#item=18
https://fr.wikipedia.org/wiki/Liste_des_titres_musicaux_num%C3%A9ro_un_en_France_en_1998
https://fr.wikipedia.org/wiki/1998_en_France

 

MySQL 3.23 | 1999

  • Voiture la plus vendue en France : Renault Clio II (phase 1)
  • Meilleure vente de Singles en France : Lou Bega, Mambo No. 5
  • Evénement : 11 août 1999, une éclipse totale de Soleil se produit sur le Nord de la France

 

Sources:
http://mysql.localhost.net.ar/doc/refman/4.1/en/news-3-23-x.html
http://www.auto-moto.com/occasion/souvenirs-souvenirs/voiture-la-plus-vendue-par-annee-les-statistiques-de-1947-a-nos-jours-55637.html#item=18
https://fr.wikipedia.org/wiki/Liste_des_titres_musicaux_num%C3%A9ro_un_en_France_en_1999
https://fr.wikipedia.org/wiki/1999_en_France

 

MySQL 4.0 | 2001

  • Voiture la plus vendue en France : Peugeot 206 (phase 1)
  • Meilleure vente de Singles en France : Star Academy 1, La musique
  • Evénement : 27 juin, fin de la conscription. L’armée française est désormais entièrement professionnelle

 

Sources:
http://mysql.localhost.net.ar/doc/refman/4.1/en/news-4-0-x.html
http://www.auto-moto.com/occasion/souvenirs-souvenirs/voiture-la-plus-vendue-par-annee-les-statistiques-de-1947-a-nos-jours-55637.html#item=19
https://fr.wikipedia.org/wiki/Liste_des_titres_musicaux_num%C3%A9ro_un_en_France_en_2001
https://fr.wikipedia.org/wiki/2001_en_France

 

MySQL 4.1 | 2003

  • Voiture la plus vendue en France : Renault Clio II (phase 2)
  • Meilleure vente de Singles en France : DJ BoBo, Chihuahua
  • Evénement : 30 mai, dernier vol du Concorde d’Air France entre Paris et New York

 

Sources:
http://mysql.localhost.net.ar/doc/refman/4.1/en/news-4-1-x.html
http://www.auto-moto.com/occasion/souvenirs-souvenirs/voiture-la-plus-vendue-par-annee-les-statistiques-de-1947-a-nos-jours-55637.html#item=20
https://fr.wikipedia.org/wiki/Liste_des_titres_musicaux_num%C3%A9ro_un_en_France_en_2003
https://fr.wikipedia.org/wiki/2003_en_France

 

MySQL 5.0 | 2003

  • Voiture la plus vendue en France : Renault Clio II (phase 2)
  • Meilleure vente de Singles en France : DJ BoBo, Chihuahua
  • Evénement : 30 mai, dernier vol du Concorde d’Air France entre Paris et New York

 

Sources:
http://ftp.nchu.edu.tw/MySQL/doc/refman/5.0/en/news-5-0-x.html
http://www.auto-moto.com/occasion/souvenirs-souvenirs/voiture-la-plus-vendue-par-annee-les-statistiques-de-1947-a-nos-jours-55637.html#item=20
https://fr.wikipedia.org/wiki/Liste_des_titres_musicaux_num%C3%A9ro_un_en_France_en_2003
https://fr.wikipedia.org/wiki/2003_en_France

 

MySQL 5.1 | 2005

  • Voiture la plus vendue en France : Renault Clio III (phase 1)
  • Meilleure vente de Singles en France : Ilona Mitrecey, Un monde parfait
  • Evénement : 31 mars, lancement de la TNT (14 chaînes gratuites).

 

Sources:
http://ftp.nchu.edu.tw/MySQL/doc/refman/5.1/en/news-5-1-x.html
http://www.auto-moto.com/occasion/souvenirs-souvenirs/voiture-la-plus-vendue-par-annee-les-statistiques-de-1947-a-nos-jours-55637.html#item=22
https://fr.wikipedia.org/wiki/Liste_des_titres_musicaux_num%C3%A9ro_un_en_France_en_2005
https://fr.wikipedia.org/wiki/2005_en_France

 

MySQL 5.5 | 2009

  • Voiture la plus vendue en France : Peugeot 207
  • Meilleure vente de Singles en France : Helmut Fritz, Ça m’énerve
  • Evénement : 15 avril, entrée en vigueur des nouvelles plaques d’immatriculations sur les véhicules neufs. La nouvelle numérotation est attribuée à vie pour chaque véhicule et comporte deux lettres, un tiret, trois chiffres, un tiret et deux lettres. Un numéro de département au choix ainsi que le logo de la région correspondante est apposée sur la droite

 

Sources:
https://dev.mysql.com/doc/relnotes/mysql/5.5/en/
http://www.auto-moto.com/occasion/souvenirs-souvenirs/voiture-la-plus-vendue-par-annee-les-statistiques-de-1947-a-nos-jours-55637.html#item=23
https://fr.wikipedia.org/wiki/Liste_des_titres_musicaux_num%C3%A9ro_un_en_France_en_2009
https://fr.wikipedia.org/wiki/2009_en_France

 

MySQL 5.6 | 2011

  • Voiture la plus vendue en France : Renault Clio III (phase 2)
  • Meilleure vente de Singles en France : Israel Kamakawiwo’ole : Over the Rainbow
  • Evénement : 14 mai : arrestation à New-York de Dominique Strauss-Kahn, directeur général du FMI, dans le cadre d’une accusation de crimes sexuels à l’encontre de Nafissatou Diallo

 

Sources:
https://dev.mysql.com/doc/relnotes/mysql/5.6/en/
http://www.auto-moto.com/occasion/souvenirs-souvenirs/voiture-la-plus-vendue-par-annee-les-statistiques-de-1947-a-nos-jours-55637.html#item=24
https://fr.wikipedia.org/wiki/Liste_des_titres_musicaux_num%C3%A9ro_un_en_France_en_2011
https://fr.wikipedia.org/wiki/2011_en_France

 

MySQL 5.7 | 2013

  • Voiture la plus vendue en France : Renault Clio IV
  • Meilleure vente de Singles en France : Daft Punk, Get Lucky
  • Evénement : 9 février, la découverte de viande de cheval camouflée dans des préparations surgelées réputées pur bœuf renforce les soupçons de tromperie sur la traçabilité agroalimentaire à l’échelle de la communauté économique européenne

 

Sources:
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/
http://www.auto-moto.com/occasion/souvenirs-souvenirs/voiture-la-plus-vendue-par-annee-les-statistiques-de-1947-a-nos-jours-55637.html#item=25
https://fr.wikipedia.org/wiki/Liste_des_titres_musicaux_num%C3%A9ro_un_en_France_en_2013
https://fr.wikipedia.org/wiki/2013_en_France

 

MySQL 8.0 | 2016

  • Voiture la plus vendue en France : Renault Clio IV (phase 2)
  • Meilleure vente de Singles en France : M Pokora, Cette Année la
  • Evénement : 1er janvier, entrée en vigueur du nouveau découpage des régions

 

Sources:
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/
http://www.auto-moto.com/occasion/souvenirs-souvenirs/voiture-la-plus-vendue-par-annee-les-statistiques-de-1947-a-nos-jours-55637.html#item=26
https://fr.wikipedia.org/wiki/Liste_des_titres_musicaux_num%C3%A9ro_un_en_France_en_2016
https://fr.wikipedia.org/wiki/2016_en_France

 

Sakila in Norway

Thanks for using MySQL!

1

PHP Tour 2017 – Slides MySQL InnoDB Cluster

mai 26, 2017

Olivier DASINI aka @freshdazLa dernière édition du PHP Tour s’est déroulée les 18 et 19 mai 2017 à Nantes. Ce que j’en garde : un très bon cru, de bien belles rencontres, de bonnes bières ainsi qu’une excellente organisation (merci l’AFUP).

 

J’ai également eu l’opportunité de présenter MySQL InnoDB Cluster, la nouvelle solution native de haute disponibilité de MySQL :

MySQL InnoDB Cluster – A complete High Availability solution for MySQL from Olivier DASINI

 

Vidéo de la conférence : https://youtu.be/Y48cbFqd5QA

 

Les photos sont disponibles sur le groupe Flickr du PHP Tour 2017 Nantes.

Les vidéos des conférences sont disponibles sur le site de l’AFUP.

 

Thanks for using MySQL!

0

Tutoriel – Déployer MySQL innoDB Cluster

mai 11, 2017

Dans les épisodes précédents on a vu comment  déployer « manuellement » MySQL Group Replication,  comprendre et tester MySQL InnoDB Cluster  ainsi que comment  gérer aisément un cluster Group Replication déja déployé avec MySQL Shell.

Aujourd’hui, dans la série Haute Disponibilité avec MySQL on va voir comment déployer et gérer un cluster from scratch , sous la forme d’un tutoriel, grâce à la solution tout en un : MySQL InnoDB Cluster.

Note: 
L’article traite de MySQL InnoDB Cluster, HA natif de MySQL Server (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 : 192.168.1.22; Nœud numéro 1 du cluster
  • Instance MySQL 2 : 192.168.1.50; Nœud numéro 2 du cluster
  • Instance MySQL 3 : 192.168.1.48; Nœud numéro 3 du cluster

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

MySQL Shell est installé sur toutes les instances.

En ce qui concerne les versions des logiciels:

Avec un schéma sa donne (à peu près) ça :

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.

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

Dans mon cas, avec l’installation par défaut sous Ubuntu, niveau configuration 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) comme expliqué dans l’article comment configurer un groupe.
  • 2/ je me connecte à chaque instance en local, et j’utilise la méthode : configureLocalInstance()

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 192.168.1.22 :

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 :

192.168.1.22 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.

 

 

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  192.168.1.22,  elle va permettre de bootstrapper le cluster:

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

On peut 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 contient plus de transactions que le groupe checkInstanceState 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

Et voilà!

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

  • Nœud 1 : 192.168.1.22 : Primaire (lecture/écriture)
  • Nœud 2 : 192.168.1.50 : Secondaire (lecture seule)
  • Nœud 3 : 192.168.1.48 : Secondaire (lecture seule)

 

Pour rendre la configuration persistante ie l’écrire dans le fichier de configuration, il faut exécuter, après que le noeud soit configuré, la méthode dba.configureLocalInstance() :

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

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.

 

Bootstrap MySQL Router

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

6446 : lectures / écritures pour le noeud primaire
6447 : lectures seules pour les nœuds secondaires (Round-Robin)
Et le pendant pour les connexions avec le protocole X (64460 & 64470), pour une utilisation NoSQL Document Store de MySQL.

 

Le fichier de configuration du Router contient quelques informations importantes, tel que le(s) port(s) à utiliser par l’application :

Il est évidemment possible de modifier ce fichier. Par exemple, souvent les applications se connectent au port 3306, ça peut donc avoir du sens de modifier le port du noeud primaire en le passant de 6446 à 3306 :

Ton application va donc (continuer à) se connecter au port 3306, sauf que maintenant ce n’est pas 1 instance, mais bel et bien 3 instances qui sont en backend, et ceci en toute transparence.

 

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é)

 

 

Gestion des nœuds

Quelques commandes qui vont te simplifier la vie…

 

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 ces informations 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 (192.168.1.22)…

Nouveau primaire élu par le groupe : 192.168.1.48.

Et 192.168.1.22 est porté disparu (MIA).

 

Un rejoinInstance() est nécessaire pour remettre le membre dans le cluster. Il aura un rôle de secondaire (voir paragraphe suivant Remettre un membre dans le groupe).

 

 

Remettre un membre dans le groupe

Un membre avec son instance MySQL qui tourne et qui est correctement configuré peut être remis (après un redémarrage de l’instance par exemple) 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 il se retrouve dans un état assez désagréable, network partitioning, en clair il faut une intervention externe au groupe pour permettre aux membres restant de continuer à faire leur boulot de serveur MySQL.

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

Perte des nœuds (crash) 192.168.1.22 & 192.168.1.50…  (Mayday, Mayday, Mayday!!!)

Le failover automatique ne peut pas s’enclencher, le membre survivant (192.168.1.48) est en lecture seule. Il faut donc intervenir :

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

Une fois les instances en condition, il faut utiliser rejoinInstance() pour remettre les membres dans le cluster, en tant que secondaire (voir paragraphe Remettre un membre dans le groupe).

 

 

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 membre sur lequel la commande est exécutée est le nouveau primaire.

 

Dans la même thématique :

 

Thanks for using MySQL!

 

0

Slides du meetup « Mise en bouche PHP »

mai 3, 2017

Mardi soir, j’ai eu le plaisir d’échanger avec la communauté PHP parisienne et de présenter MySQL InnoDB Cluster lors du meetup « Mise en bouche PHP » organisé par l’AFUP Paris et sponsorisé par Oracle MySQL.

Voici les slides

MySQL InnoDB Cluster – Meetup Oracle MySQL / AFUP Paris from Olivier DASINI

 

Prochain rendez-vous, le 18 mai pour le PHP Tour 2017 à Nantes.

 

Thanks for using MySQL!

0

Mes confs MySQL pour avril et mai 2017

avril 24, 2017

J’aurai le plaisir de vous rencontrer (et accessoirement de parler de MySQL) les 25 avril, 2 et 18 mai.
 

MySQL The world's most popular open source database

MySQL Day Paris

Toutes l’info MySQL par l’équipe MySQL France

Info et inscription

 

Mise en bouche PHP – Paris

Meetup organisé par l’antenne AFUP Paris

Info et inscription

 

PHP tour 2017 – Nantes

La prochaine étape du cycle de conférences itinérant, réunissant toutes les communautés PHP se déroule à Nantes

Info et inscription

 

 

0

Adopte un… cluster MySQL Group Replication

avril 10, 2017

Autant le dire tout de suite, rien avoir avec un site internet de rencontre en ligne! 🙂
C’est bel et bien un nouvel article dans la série, Haute Disponibilité avec MySQL.

Au menu d’aujourd’hui : comment passer de l’administration « manuelle » de votre solution HA MySQL Group Replication à une administration plus simple, plus fun mais surtout facilement automatisable avec le pack MySQL InnoDB Cluster. En clair, on va voir comment utiliser MySQL Shell pour l’administration et l’orchestration du cluster et MySQL Router pour rediriger automatiquement les transactions de l’application vers le noeud primaire du cluster.

Quelques pré-requis sont nécessaire pour optimiser ta compréhension de cet article, je te conseille donc la lecture préalable des articles suivants:

 

Note: 
L’article traite de MySQL InnoDB Cluster, HA natif de MySQL Server, solution à ne pas confondre avec MySQL NDB Cluster.

 

Le contexte

Pour ce PoC, j’ai un cluster MySQL Group Replication de 3 nœuds, fonctionnel, en mode « Single Primary » (déployé avec Docker Compose):

  • Instance 1 : mysql_node1 (172.19.0.2)
  • Instance 2 : mysql_node2 (172.19.0.4)
  • Instance 3 : mysql_node3 (172.19.0.3)

 

MySQL Router et mon application (simulée avec le client texte mysql) sont sur la machine host (par commodité). C’est également le cas de MySQL Shell.

En ce qui concerne les versions des softs:

  • MySQL Server 5.7.17
  • MySQL Router 2.1.2 rc
  • MySQL Shell 1.0.8-rc

Docker 1.12.6 & Docker-compose 1.11.2. Docker est hors du cadre de cet article, mais tu trouveras à la fin de cet article le fichier docker-compose.yml utilisé.

 

Ah oui, j’ai failli oublier :

TL;DR
Tu as un cluster MySQL Group Replication configuré/administré manuellement et qui tourne. Tu peux l’administrer / le configurer avec MySQL Shell et gérer le routage des requêtes applicatives avec MySQL Router, ces 3 composants forment MySQL InnoDB Cluster.

MySQL InnoDB Cluster Overview

 

MySQL Group Replication

Les étapes de déploiement du cluster Group Replication ont déjà été traitées ici.

Voici mes 3 instances MySQL 5.7

MySQL 5.7.17 plus précisément.

 

A quoi ressemble mon cluster Group Replication ?

Je peux avoir la description de l’architecture avec la table performance_schema.replication_group_members :

L’identification du noeud primaire peut se faire de la manière suivante :

Le noeud mysql_node1 est donc en mode lecture écriture aka le noeud primaire (cette info nous sera utile pour la suite) et les 2 autres en lecture seule (super read only activé):

 

On a donc un cluster MySQL Group Replication avec 3 nœuds online.
Le membre mysql_node1 est (pour le moment) le primaire, mysql_node2 et mysql_node3 sont les secondaires.

 

L’étape suivant consistera à gérer le cluster avec MySQL Shell.

 

MySQL Shell, interface pour gérer son cluster

On va se connecter avec le client MySQL Shell au noeud primaire :

Ensuite, je « crée » mon cluster, en fait je vais rendre persistante les informations relatives à l’architecture du groupe dans mon cluster (plus d’info sur ce sujet plus bas).

La méthode createCluster() prends comme paramètres, le nom du cluster (pocCluster) ainsi que des paramètres optionnels comme ipWhitelist (172.19.0.0/16)…

Pour plus de détails connecte toi à MySQL Shell (mysqlsh) et tape : dba.help(‘createCluster’)

 

Vérifions l’état du cluster

MySQL Shell nous confirme ce que nous savions déjà:

je m’auto cite; un grand (1m89) DBA à dit un jour :

« On a donc un cluster MySQL Group Replication déployé avec 3 nœuds online. Le membre mysql_node1 est (pour le moment) le primaire, mysql_node2 et mysql_node3 sont les secondaires. »

 

En zoomant dans les entrailles du groupe, on constate que la méthode createCluster() a écrit des données dans le cluster :

Le schéma mysql_innodb_cluster_metadata a donc été créé pour contenir les informations relatives au cluster.

Le nom des tables est assez explicite :

hosts

 

clusters

 

replicasets

 

instances

 

 

Déploiement de MySQL Router

Le déploiement du router est trivial, il faut pour commencer le bootstrapper au cluster, c’est à dire le lier au cluster en le connectant aux méta-données :

Les paramètres directory et name sont optionnels.

 

Lancer MySQL Router :

L’application doit se connecter (par défaut) au port 6446 (écritures et lectures vers le noeud primaire). En cas de besoin de read scalability, les lectures peuvent être dirigées vers le port 6447.

 

Inspectons de nouveau les méta données :

routers

 

hosts

 

Voilà, mon cluster Group Replication paramétré « à la main » fait maintenant partie intégrante de mon InnoDB Cluster, je peux donc l’administrer avec MySQL Shell et je peux vous assurer que c’est vraiment pratique.

Mais ceci est une autre histoire et fera l’objet d’un autre article 🙂

 

Annexe

Le fichier docker-compose est le suivant :

 

Thanks for using MySQL!

2

Tester MySQL InnoDB Cluster

mars 13, 2017

MySQL InnoDB Cluster est la (future) solution out-of-the-box HA de MySQL (à ne pas confondre avec MySQL NDB Cluster). Ce produit est composé de 3 éléments :

  • MySQL Group Replication
    • Plugin de réplication multi-maître, avec résolution de conflits et basculement (failover) automatique.
  • MySQL Router
    • Middleware léger et performant qui fournit un routage transparent entre l’application et le cluster.
  • MySQL Shell
    • Client interactif Javascript, Python et SQL qui permet d’administrer le cluster.

MySQL InnoDB Cluster Architecture
MySQL Group Replication est GA et peut donc être utilisé tel quel hors MySQL InnoDB Cluster (voir Déployer un cluster MySQL Group Replication).

Ce n’est par contre pas encore le cas pour les 2 autres composants, MySQL Shell et MySQL Router qui sont en Release Candidate (RC), il n’est donc pas recommandé à ce jour de les utiliser dans un environnement de production.

 

Note: 
L’article traite de MySQL InnoDB Cluster, HA natif de MySQL Server, solution à ne pas confondre avec MySQL NDB Cluster.

 

Installer MySQL InnoDB Cluster

Dans le cadre de cet article, les versions utilisées sont:

  • MySQL Server : 5.7.17
  • MySQL Shell : 1.0.8-rc
  • MySQL Router : 2.1.2 rc

Pour utiliser MySQL InnoDB Cluster, il faut simplement installer ces 3 composants :

 

Déployer les instances de test

MySQL Shell permet de déployer simplement des instances MySQL de test (sandbox).

Connexion avec MySQL Shell :

 

Déployer la 1ère instance MySQL qui fera partie de notre cluster :

  • Host : localhost
  • Port : 3310

Il suffit de rentrer le mot de passe root, puis l’instance est crée dans ~/mysql-sandboxes :

 

Créons 2 autres instances pour le cluster:

  • Host : localhost
  • Ports : 3320 & 3330

On a donc 3 instances MySQL dans notre sandbox.

 

A Noter que si vous avez déjà un cluster MySQL Group Replication actif, MySQL InnoDB Cluster est capable de l’adopter. Ceci fera l’objet d’un prochain article.

 

Gérer les instances

D’autres méthodes existent pour gérer les instances:

  • Stop
    • dba.stopSandboxInstance()
  • Start
    • dba.startSandboxInstance()
  • Kill  : permet de simuler le crash d’un nœud
    • dba.killSandboxInstance()
  • Delete : suppression totale de l’instance de la sandbox
    • dba.deleteSandboxInstance()

 

Exemple – Arrêt et suppression d’une instance

 

L’aide est disponible dans MySQL Shell avec dba.help()