Archive pour la catégorie ‘4.1’

15 secondes pour installer une réplication MySQL avec MySQL Sandbox, pari tenu ?

Vendredi 10 octobre 2008

« Installez-moi une configuration MySQL composée d’un master et deux slaves, vous avez 15 secondes. Top chrono »…

Non, ça n’est pas la dernière énigme à la mode pour rentrer chez Google mais plutôt une question qui pourrait devenir presque banale pour un entretien d’embauche pour un DBA MySQL à l’avenir, qui sait ?

Face à un tel défi, trois solutions :

- La fuite (mais faites une croix sur la « recommandation » Linkedin)
- Le kernel panic
- MySQL Sandbox !

Bien vu, MySQL Sandbox est la réponse la plus stratégique pour la poursuite de votre carrière.

Giuseppe Maxia (dont le blog figure dans notre blogroll, allez y jeter un oeil) est l’auteur de cet outil vraiment très pratique.  Que propose t-il ?

L’idée est d’automatiser l’installation de plusieurs serveurs MySQL sur une même machine. Rien que nous ne puissions faire manuellement c’est vrai, cependant la procédure habituelle consistant à ne pas mélanger les répertoires d’installation, choisir un port différent par serveur, appliquer mysql_secure_installation… Tout cela gagnerait à être automatisé non ? De plus ces installations manuelles sont potentiellement sources d’erreurs.

MySQL Sandbox est compatible avec toutes les versions MySQL de la 3.23 à la 6.0. Les différentes installations effectuées sont indépendantes les unes des autres, on peut ainsi faire cohabiter sans risque de conflits plusieurs versions différentes de MySQL sur une même machine (ports, répertoires et sockets indépendants).

En plus d’automatiser ces processus d’installation (gain de temps), MySQL Sandbox ne s’arrête pas là et  propose également des commandes très simples pour gérer les serveurs une fois installés.

Concernant le gain de temps, son auteur promet (notamment en page 2 de cette présentation) l’installation d’une réplication MySQL en 15 secondes. Info ou intox ?

Lire le reste de cet article »

Mots-clefs : ,
Publié dans 4.0, 4.1, 5.0, 5.1, MySQL, réplication | 4 commentaires »

Générer un jeu de données : shell, mysqlslap, et procédure stockée

Mardi 19 août 2008

Le prochain article de notre série consacrée aux index MySQL approche et j’ai besoin pour ce prochain épisode de générer une table de test de la forme suivante :

CREATE TABLE `t` (
`id` mediumint(8) unsigned NOT NULL auto_increment,
`date` timestamp NOT NULL,
`flag` tinyint(4) NOT NULL default '0',
PRIMARY KEY  (`id`),
KEY `flag` (`flag`)
) ENGINE=MyISAM;

La structure est définie, reste à alimenter la table, disons 1 million d’enregistrements.

La valeur du champ « flag » est importante pour nos tests ultérieurs, sa valeur doit pour le moment être comprise entre 0 et 1, le tout à peu près uniformément distribué.

La requête sera la suivante :

INSERT INTO test.t (flag) VALUES (ROUND(RAND()));

Il faut maintenant exécuter celle-ci 1 million de fois.
Voyons ce que cela donne en utilisant le shell, mysqlslap ou bien encore une procédure stockée.

Lire le reste de cet article »

Mots-clefs : ,
Publié dans 4.0, 4.1, 5.0, 5.1, MySQL | 6 commentaires »

Les index MySQL : types, placements, efficacité

Vendredi 27 juin 2008

Déjà trois semaines d’écoulées depuis que certains d’entre vous, les « héros », ont posé leurs questions (oui il est possible de devenir un héros rien qu’en lisant dbnewz ! Les véritables héros sont d’ailleurs abonnés au tout nouveau flux feedburner ;) )

Trois semaines d’attente, cela mérite un billet digne de ce nom, c’est parti.

Indexer, pourquoi ?

L’indexation peut avoir plusieurs buts :
- Accéder à ses données plus rapidement, les index sont en effet l’outil le plus puissant pour accélérer les temps d’exécution de vos requêtes jusqu’à parfois plusieurs centaines de % !
- Définir le degré d’unicité d’une colonne donnée : chaque champ doit-il être unique ? les doublons sont-ils autorisés ?

Principe de fonctionnement

Lorsque vous envoyez une requête à votre serveur MySQL, celle-ci est d’abord confiée au « parseur » SQL qui a pour but de vérifier si la syntaxe de votre demande est correcte. Cette étape franchie, la requête passe par « l’optimiseur ». Il s’agit ici de déterminer le plan d’exécution de la requête afin que celle-ci s’exécute le plus rapidement possible.

L’optimiseur détecte si d’éventuels index sont disponibles, si c’est le cas il décidera de s’en servir… ou pas : il est parfois plus rapide de ne pas se servir d’un index ! Nous verrons pourquoi au cours de cette série d’articles.

Une fois le plan d’exécution achevé, c’est le moteur de stockage qui prend le relais, celui-ci peut être vu comme un « module » de MySQL :

Les moteurs de stockage MySQL sont des \

Lire le reste de cet article »

Mots-clefs : ,
Publié dans 4.0, 4.1, 5.0, 5.1, MySQL | 24 commentaires »

DBDesigner 4 : générer son MCD par reverse engineering

Dimanche 22 juin 2008

Disposer d’un MCD (modèle conceptuel de données) lorsqu’on travaille sur une requête SQL impliquant différentes tables représente un gain de temps.
Il est en effet plus rapide de jeter un coup d’oeil sur un MCD afin de repérer quels sont les champs qui lient une table à une autre plutôt que d’enchaîner les « DESC ma_table », puis repérer la clé primaire et les éventuelles clés étrangères, et rebolote sur la ou les tables de destination…

La prochaine série d’articles sur les index MySQL va nous amener à enchaîner quelques requêtes sur une des deux bases d’exemple disponibles sur le site de MySQL : world et sakila, le prétexte est donc tout trouvé pour évoquer ici la solution que j’ai retenu pour obtenir le MCD de ces tables : DBDesigner 4.

Cet outil n’est pas nouveau, son successeur officiel est même déjà connu, il s’agit de MySQL Workbench. Celui-ci n’étant pas encore disponible sous linux, nous utiliserons son ancêtre et plus particulièrement sa fonctionnalité de « reverse engineering » : une fois connecté à votre base, DBDesigner 4 va générer sous forme graphique vos tables, leurs descriptions, et si tout se passe bien, les relations entre vos tables.

Lire le reste de cet article »

Mots-clefs : ,
Publié dans 4.0, 4.1, 5.0, 5.1, MySQL | 3 commentaires »

« Les index MySQL » : la série dont vous êtes le héros

Jeudi 5 juin 2008

Un titre sans doute bien étrange pour certains et qui rappelera des souvenirs à d’autres, surtout à ceux qui ont déjà parcouru un de ces livres « dont vous êtes le héros« …

Afin que les choses soient claires pour tout le monde, je vous propose en fait de participer à la conception du sommaire de la future série d’articles sur les index qui sera publiée prochainement sur dbnewz.

L’indexation est en effet un thème auquel il faut absolument s’intéresser, tout d’abord pour éviter des catastrophes et bien sûr pour optimiser les performances !

Lire le reste de cet article »

Mots-clefs :
Publié dans 4.0, 4.1, 5.0, 5.1, MySQL | 7 commentaires »

Choisir l’implémentation de ses index : « B-TREE » ou « HASH », quelles différences ?

Lundi 19 mai 2008

Préambule technique à une série de futurs articles, je ne vous en dis pas plus, l’épisode du jour a pour point de départ un moteur de stockage MySQL avec à la clé la possibilité, ou pas, de définir l’implémentation de ses index : B-TREE ou HASH.

Ce choix n’est en effet pas toujours disponible, c’est même plutôt rare puisque seul le moteur de stockage MEMORY vous permet depuis la version 4.1 de MySQL, d’effectuer ce choix. Nous ne parlerons pas ici du MySQL Cluster et de son moteur NDB qui sera abordé spécifiquement dans un autre épisode.

Pourquoi alors se soucier de ce type d’implémentation si seul le moteur MEMORY offre la possibilité de choisir ?
- MyISAM et InnoDB pourraient à l’avenir proposer ce choix.
- Afin de comprendre plus finement comment fonctionnent les index que vous utilisez tous les jours, se pencher sur la façon dont ils sont implémentés permet de mieux appréhender certains résultats.

Lire le reste de cet article »

Mots-clefs : ,
Publié dans 4.1, 5.0, 5.1, MySQL | 5 commentaires »

Lancer un script mysql sans donner ni l’utilisateur ni le mot de passe sur la ligne de commande

Jeudi 4 octobre 2007

Voici mon problème du jour : Comment lancer un script (de maintenance par exemple) qui fait appel à mysql, sans stocker en dur le nom de l’utilisateur et le mot de passe (ce qui est mal, très très mal). Le but est que seul un utilisateur privilégié (je n’ai pas forcément dit root ! je pense plutôt à un compte système comme mysql par exemple) puisse lancer ce script.

C’est plutôt facile, et je fournis trois solutions pour la peine :

  1. Avoir un fichier de configuration pour le script accessible seulement par l’utilisateur privilégiéOn définit dans le fichier de configuration des variables d’environnement, une pour le user, une autre pour le mot de passe. Dans le script il ne reste qu’à utiliser la commande source pour récuperer ses variables (seul l’utilisateur privilégié pourra lire le fichier). Simple et efficace.
  2. Avoir un fichier de configuration pour mysql accessible seulement par l’utilisateur privilégiéVariante de la précédente : on crée un fichier de configuration spécifique pour mysql (que l’on pourra mettre par exemple dans /etc/mysql mais il n’y a aucune obligation). Et on utilise l’option –defaults-file pour que mysql lise le contenu du fichier (il lit notamment les sections [client] et [mysql]). Exemple de fichier:

    [client]
    host = localhost
    user = votre_user
    password = votre_mot_de_passe
    socket = /var/run/mysqld/mysqld.sock

    Bonus : on peut spécifier d’autres options pour influer sur mysql (en vrac, le nom de serveur, le jeu de caractères…).
  3. Pour ceux qui ont plusieurs scripts mais qui ont des options qui diffèrent légèrementVous avez des scripts quasiment identiques mais les options diffèrent légèrement (ou vous voulez centraliser tout en un seul fichier) : c’est possible. C’est une variante du cas précedent : on écrit un fichier de configuration mysql que l’on découpe en plusieurs sections. Ensuite, on fait appel au programme my_print_defaults ! my_print_defaults examine le fichier de configuration (option -c pour spécifier le votre…) et donne en sortie les paramètres à passer à mysql sous forme d’argument. Exemple :

    $ my_print_defaults -c /etc/mysql/maconf.cnf client
    --host=localhost
    --user=votre_user
    --password=votre_mot_de_passe
    --socket=/var/run/mysqld/mysqld.sock

    Il ne reste plus qu’à passer cela à mysql en récuperant la sortie dans une variable (ou en utilisant cette petite merveille de xargs).

Mots-clefs :
Publié dans 4.0, 4.1, 5.0, 5.1, MySQL | Aucun commentaire »

Heidelberg ou le plongeon dans le monde de C++

Vendredi 21 septembre 2007

Le séjour n’est pas encore fini mais je peux déjà vous livrer quelques sentiments de cette immersion dans le monde des développeurs MySQL. L’ambiance y est excellente, tout le monde est heureux d’être présent. Néanmoins ce ne sont pas des vacances pour autant. Le petit déjeuné est pris en 7:30 et 8:15 et est suivi par de nombreux team meetings. L’après midi se concentre plus sur des sessions université MySQL.. Ces sessions étant vraiment orienté développeur je dois dire que j’ai vu en quelques jours plus de code C++ que je n’en ai vu en des années… Enfin c’est un vrai plaisir de voir les nouveautés présentées par leur auteurs. Cet événement réuni plus d’une centaine de « MySQLers », principalement développeurs mais aussi quelques formateurs, QA,… et une dizaine d’invités externes…

Les différences avec la conférence utilisateurs:

  • pas de sales, ni de marketing, tout y est très technique, nous parlons plus d’optimisation, de modifications de MySQL que d’utilisation de la base
  • beaucoup moins de personnes, ce qui permet de rencontrer le maximum de personne et discuter de sujets variés.

En parlant de User Conférence, la prochaine est déjà prévue du 15-18 Avril 2008, toujours à Santa Clara et j’y serai évidement. Je dois trouver ce que je pourrai y présenter avant le 30 octobre…

Mots-clefs :
Publié dans 4.1, MySQL Developer Meeting, User Conference 2007 | Aucun commentaire »

Seconds_behind_master?

Jeudi 2 août 2007

Lorsque vous faites un SHOW SLAVE STATUS pour savoir l’état d’un de vos slaves dans votre chaîne de réplication, vous avez cet intéressant paramètre Seconds_behind_master, ceci évidemment si vous utilisez MySQL 4.1 et plus. Sur un serveur j’ai eu la désagréable surprise de voir cette valeur alterner constamment entre 0 et 2 heures…Humm? Ceci m’a poussé à regarder plus en détail le calcul de cette valeur.

Quand un slave se connecte au master, par la entendez le Slave I/O thread, il enregistre la valeur dm = SELECT UNIX_TIMESTAMP() ce qui revient à connaître la date actuelle du master (dm: date master) puis fait la même chose sur lui même ds = SELECT UNIX_TIMESTAMP() (ds: date slave). De la il calcule la différence D = ts – tm.

Dans les log de réplication (binlog) sont enregistrés les dates d’exécutions de chaque requête. Ainsi lorsque le Slave SQL thread rejoue ces même requêtes, il calcule:

seconds_behind_master = SELECT UNIX_TIMESTAMP() sur le slave – date d’exécution de la requête sur le master – D

Premier point, ce paramètre nous donne la différence entre le moment où une requête est mise dans le relay log et le moment ou elle a été executé sur le master. En aucun cas nous connaissons le temps qu’il a fallu pour la récupérer du master. Donc imaginons maintenant que votre slave est lent à les récupérer mais une fois récupérées, elles soient exécutées instantanément… Votre valeur Seconds_behind_master sera 0 alors qu’en réalité votre slave peut ne pas être à jour.

Quand le SQL thread est au niveau, pas d’autre relay log à jouer, Seconds_behind_master sera 0. Si votre connexion réseau est rapide, le slave I/O thread sera proche du masteret donc ce champ vous donnera une bonne approximation. Dans le cas contraire, le valeur sera 0 car le SQL thread est en attente du I/O thread et non car votre slave est à jour.

NULL est un autre valeur possible pour ce champ, si l’I/O thread est en pause ou en train de se reconnecter, celle valeur est mise à NULL.

En résumé, celle valeur est informative et peut éventuellement vous mettre sur la piste d’un problème réseau mais elle n’est pas à prendre pour argent comptant.

Mots-clefs :
Publié dans 4.1, MySQL, réplication | Aucun commentaire »

Réplication et Log binaires

Vendredi 6 avril 2007

Qui n’a jamais utilisé MySQL sans la réplication? La réplication permet à votre application de supporter un nombre de lecture beaucoup plus important. Les updates se font sur une base de donnée « maître » (master) et sont ensuite répliquées sur plusieurs « esclaves » (slaves). Le maître n’a pas à supporter les requêtes venant de clients qui sont gérées par les esclaves. Un autre jour je rentrerai plus en détails la dessus mais en résumé, le maître écrit dans des fichiers toutes les requêtes qui ont modifié ses informations (insert, update et delete). Les slaves viennent à leur tour récupérer ces fichiers (binary logs) et les « copie » localement (relay logs) avant de les rejouer.

Il est conseillé en général de dédier un disque pour ces fichiers car beaucoup d’écriture entraîne une baisse de vos performances. Dans le cas qui nous intéresse, l’activité du CPU m’a très étonné. En effet jusqu’à 60% du temps CPU étaient utilisé par ‘USER’ juste en activant la réplication.
Lire le reste de cet article »

Mots-clefs : , ,
Publié dans 4.1, MySQL, réplication | Aucun commentaire »