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!

 

1

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!

0

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

 

Vérifier la configuration des instances

Un moyen simple de savoir si les instances ont la configuration requise pour faire partie du cluster est d’utiliser : dba.checkInstanceConfiguration()

 

Créer le cluster

On a donc 3 instances MySQL, en standalone, configurées et prêtes à se transformer en une base de données distribuée.

Je vais donc me connecter à une de mes instances :

  • User : root
  • Host : localhost
  • Ports : 3310

 

Puis commencer la création effective de mon instance MySQL InnoDB Cluster, nommée testcluster

Je me retrouve pour le moment avec un cluster d’1 nœud. Certes, pas encore hautement disponible, mais c’est un début 🙂

La méthode status() me le confirme:

 

Avant de lui rajouter des petits copains, on va vérifier que toutes les instances ont la même liste de transactions exécutées:

Parfait !

 

Ajouter les autres nœuds

addInstance(), la bien nommée :

Ajout de localhost:3320

Ajout de localhost:3330

 

L’architecture de notre cluster est maintenant:

localhost:3310 est le primaire il est donc le seul à accepter les écritures. Les 2 autres membres ne sont accessibles qu’en lecture.

C’est le comportement par défaut de MySQL Group Replication est donc de MySQL InnoDB Cluster.  Pour avoir un cluster en multi-master, il faut le préciser lors de la création du cluster (dba.createCluster()).

 

Les informations révélées par les différentes commandes exécutée jusqu’ici, sont persistante. Elles sont en stockées dans les nœuds du cluster, dans le schéma mysql_innodb_cluster_metadata :

 

Déployer MySQL Router

MySQL Router étant déjà installé, on va le configurer pour l’interfacer avec notre cluster:

4 ports TCP ont été configurés, 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 bootstrap à généré un fichier de configuration pour MySQL Router

 

Utiliser MySQL Router

Evidemment il faut le démarrer

 

Un petit coup d’œil dans les logs:

 

Voila MySQL InnoDB Cluster configuré et prêt à être testé !

L’application doit se connecter au port 6446 (écritures et lectures vers le noeud primaire). Les lectures peuvent également être dirigées vers le port 6447.

 

Tests

Port de lecture

=> affiche : 3320, 3330, 3320, 3330, …

 

Port d’écriture

=> affiche : 3310, 3310, 3310, …

 

Failover automatique

Grâce à la méthode dba.killSandboxInstance() on peut simuler un crash du serveur primaire et ainsi voir à l’oeuvre le failover automatique du cluster.

Les 2 sessions qui suivent s’exécutent en parallèle:

Session 1

 

Session 2

=> La session 1 va afficher 3310 puis 3320 après le basculement de la base de données (database failover).

 

 

En complément je vous invite à lire :

et regarder la video de lefred : MySQL InnoDB Cluster: MySQL Shell starter guide

 

Documentation

 

Thanks for using MySQL!

2

FAQ Webinar MySQL Group Replication

mars 3, 2017

Mise-à-jour: 7 Mars 2017

Le 1er mars dernier, j’ai présenté lors d’un webinar, la technologie de haute disponibilité MySQL Group Replication. On a explosé notre record d’affluence et j’ai été inondé de questions, preuve s’il en faut de votre intérêt, toujours plus important, pour la base de données Open Source la plus populaire au monde.

Je n’ai malheureusement pas été en mesure de répondre à toutes les questions, ce qui me permet aujourd’hui de les centraliser dans cette FAQ. Cette dernière pourra être mise à jour de temps à autres, en fonctions des questions que je récupérerai du terrain.

En complément de cette FAQ

 


  • Sur quels OS peut on utiliser MySQL Group Replication ?

MySQL Group Replication est un plugin du serveur MySQL. Il est donc présent sur toutes les plateformes où MySQL 5.7 est disponible :

  • Linux
  • Windows
  • Solaris
  • OSX
  • FreeBSD

Liste complete

 

  • Est ce que la feature de multi-master nécessitera un update du driver MySQL ou cela sera vu comme un master « standard » d’un point de vu client ? 

L’architecture classique MySQL Group Replication est la suivante :

Client + MySQL Router      |      MySQL Group Replication

Client      |      ProxySQL      |      MySQL Group Replication

C’est du moins le cas en mode Single Primary car il faut pouvoir identifier le nœud primaire.

Cette architecture est valable également en mode multi-master (ou multi-Primaire), cependant dans ce cas, vu que tout les membres sont master, il suffit simplement que le driver contiennent la liste des membres.

 

  • Est-ce que l’on a une contrainte sur le nombre de nœuds minimum ?

Pas de contraintes par « design ».  Cependant, pour qu’un system distribué puisse fournir du failover automatique, il faut minimum 3 nœuds. Cela permet d’éviter le split brain.

A noter qu’il est possible de mettre en place un cluster MySQL Group Replication avec seulement 2 nœuds. Mais en cas d’arrêt non prévu (crash) d’un des membres, l’autre membre n’acceptera pas de nouvelles requêtes. On se trouve alors dans un cas de Network Partitioning,  et la partition doit être débloquée selon la procedure inscrite dans la doc.

Par contre si l’un des 2 membres est arrêté « gracieusement » (STOP GROUP_REPLICATION;), l’autre continue de fonctionner normalement.

 

  • Dans le cas d’une utilisation multi-master, est-ce que l’on peut ajouter/retirer des nœuds dynamiquement ?

Oui, dans les 2 modes (Single Primary ou multi-master) il est possible d’ajouter et/ou de retirer des nœuds dynamiquement.

 

  • Au sein d’un cluster MySQL Group Replication, l’élection d’un nœud master R/W est-il automatique ou manuel ?
  • Dans le mode Single Primary, lorsque le primaire tombe, comment est choisi le nouveau nœud primaire ?

Le process d’election est automatique et transparent pour le client. Alors pas mal de process se passent « behind the scene » !

Il faut notamment que les autres membres identifient le fait que le nœud ne fasse plus partie du cluster et puis ensuite enclencher le process d’élection du nouveau nœud primaire (le prochain dans la liste ordonnée en fonction de l’UUID de instances du cluster) et aussi désactiver le mode read-only.

Identifier le nœud primaire : https://dev.mysql.com/doc/refman/5.7/en/group-replication-find-primary.html

Exemples:

L’information qui permet de savoir quel nœud est primaire est disponible dans la table performance_schema.global_status :

En la joignant avec la table performance_schema.replication_group_members ont obtient un peu plus d’infos:

 

  • Est-ce que l’on a des limites en terme de taille de base de données pour MySQL Group Replication ?

Le moteur de stockage utilisé avec MySQL Group Replication est InnoDB. Les limites sont donc celles imposées par InnoDB.

 

  • Est-ce que l’on peut utiliser MySQL Router avec une replication asynchrone classique ?

MySQL Router 2.0, peut être utilisé avec MySQL Replication : https://dev.mysql.com/doc/mysql-router/2.0/en/

Le plugin Connection Routing fournit 2 modes de « routage »:

  • Le mode Read-Only : route les requêtes en mode round-robin sur une liste d’instances MySQL.
    => Cela a du sens pour router les requêtes de lectures sur les slaves.
  • Le mode Read-Write : route les requêtes sur le premier serveur de la liste, si celui si n’est plus accessible, les requêtes sont alors routées sur le suivant de la liste et ainsi de suite jusqu’au dernier.
    => Perso, je ne suis pas trop fan de ce mode pour MySQL Replication.

 

  • Sur une configuration multi-master, est il toujours conseillé de mettre en place un offset sur les ID pour chaque node pour éviter les conflits ?

Avec la réplication classique (asynchrone) de MySQL,  pour une architecture multi-master en actif/actif (que je ne conseille toujours pas), il est nécessaire de mettre en place différents offsets pour prévenir les conflits liés aux clés primaire en auto increment (details).

Dans le cas de MySQL Group Replication, ce problème se pose également en mode multi-master. C’est pour cela qu’il est géré automatiquement par le cluster. Il est cependant possible de modifier les paramètres manuellement (details).

 

  • La modification d’une table est-elle automatiquement répliquée ?

Toutes les modifications certifiées d’un nœud vont être répliquées sur les autres. Cela concerne évidemment les DDL.

A noter que certaines précautions doivent être prisent lorsque vous exécutez des DDL en mode multi-master (details).

 

  • Avec 3 nœuds, si on perd 1 nœud et que les 2 autres ne se voient plus, pas de quorum donc plus d’écriture ?

Avec une architecture MySQL Group Replication de 3 nœuds, l’arrêt non prévu (crash) d’1 membre génère la recomposition automatique du cluster avec 2 nœuds ie aucune intervention n’est nécessaire.

Par contre vous vous trouvez dans une situation « inconfortable » et il faut donc re-provisionner un 3ème nœuds ASAP. Parce qu’avec ce cluster de 2 membres, en cas de crash d’un des 2 ou en cas de split-brain, la recomposition automatique du cluster ne peut plus se faire.

On se trouve alors dans le cas du Network Partitioning (les membres n’acceptent plus d’écriture), et la partition doit être débloquée « manuellement ».

 

  • A quel format le log binaire doit être positionné ?

Seul le format ROW est valide (binlog-format=ROW)

 

  • Peut on contrôler les délais de réplication ?

Le Flow-control permet de maintenir les membres du groupe raisonnablement proches les uns des autres.

A noter que d’autres approches pour contrôler les délais de réplication seront disponibles dans le futur.

Je vous conseille la lecture de cet article qui traite du sujet des performances de MySQL group Replication.

 

  • Pourquoi 9 nœuds maximum ?

Selon les résultats de nos tests, jusqu’à 9 membres les performances restent très satisfaisantes. De plus ce nombre assure une très bonne disponibilité car le cluster peut alors gérer automatiquement jusqu’à 4 pertes de nœuds simultanément !

A noter qu’il est toujours possible de rajouter des slaves au cluster MySQL Group Replication.

 

  • Est-il possible d’avoir une configuration multi OS par exemple un membre sur Linux et un autre membre sur du Windows ?

Tout à fait !

Je peux par exemple avoir l’architecture MySQL Group Replication suivante :

Nœud A sur Linux
Nœud B sur Windows
Nœud C sur OSX

 


Quelques liens utiles

 

 

Thanks for using MySQL!

1

Configurer ProxySQL pour MySQL Group Replication

janvier 11, 2017

Cet article s’inspire de HA with MySQL Group Replication and ProxySQL de Frédéric Descamps aka @lefred

 

Dans un précédent article je vous ai présenté comment déployer un cluster MySQL Group Replication, la nouvelle solution de haute disponibilité de MySQL.

Ce type d’architecture est souvent utilisé avec un composant qui se place entre l’application et le cluster,composant généralement appelé proxy (quelque chose) ou router quelque chose. Dans cet article, je vais vous présenter le meilleur (selon moi) proxy open source du moment : ProxySQL (1.3.2 : la version GA à la date d’écriture).

Le but de cet article est de créer un PoC Solution HA Base de Données Open Source : MySQL Group Replication et ProxySQL.

 

L’article étant suffisamment long, je ne vais couvrir ni l’installation des nœuds MySQL (5.7.17), ni le déploiement du cluster. Mais comme je suis sympa, voici les ressources nécessaires pour accomplir ces différentes tâches:

 

Avertissement!
Ce qui suit est effectué par un professionnel… sur son ordi portable 🙂 Toutes les instances sont en local, car je suis fainéant par commodité.
Attention, à ne pas reproduire tel quel en production. 

 

MySQL Group Replication

MySQL Group Replication se présente comme un plugin embarqué dans MySQL à partir de MySQL 5.7.17.

Caractéristiques

  • Version du serveur : 5.7.17
  • Version du plugin : 1.0
  • Nœud 1 : 127.0.0.1 : 14418
  • Nœud 2 : 127.0.0.1 : 14419
  • Nœud 3 : 127.0.0.1 : 14420

 

A partir d’ici, on a donc un cluster MySQL Group Replication de 3 nœuds, installé, déployé et qui fonctionne :

 

Le cluster est en mode single primary, c’est à dire qu’un seul nœud est disponible en écriture (à la fois).

 

Pour pouvoir automatis