Audit Et Optimisation MySQL 5 Bonnes Pratiques Pour l'Administrateur

Propriété de Albiri Sigue <[email protected]>customer 27921 at Fri Mar 11 20:13:17 +0100 2011

97

82

21

21

26

34

1

Audit et optimisation MySQL 5

Bonnes pratiques pour l’administrateur

P a s c a l B o r g h i n o

O l i v i e r D a s i n i

A r n a u d G a d a l

P.

Bo

rg

hin

oO

. D

as

ini

A.

Ga

da

lM

ySQ

L 5

Aud

it et

opt

imisa

tion

Les auteursPascal Borghino est architecte de bases de données chez Yahoo! International. Il est confronté au quotidien à de nombreux problèmes, tant au niveau du design, de l’extensibilité que des performances. Il est président et fondateur du MySQL User Group Francophone (LeMUG.fr) et créateur du blog www.dbnewz.com. Olivier Dasini a 10 ans d’expérience en tant que consultant et formateur certifi é MySQL. Aujourd’hui expert en bases de données chez Orange Business Services, il milite pour la promotion des logiciels libres et est également fondateur du blog de vulgarisation autour de MySQL http://dasini.net/blog. Il est co-fondateur du MySQL User Group Francophone LeMUG.fr.

Arnaud Gadal est l’administrateur des bases de données MySQL de Virgin Mobile. Il est certifi é MySQL 5 (développement, administration, cluster), membre du MySQL User Group et principal auteur sur www.dbnewz.com

La grande majorité des applications web s’adossent à la base de données MySQL et imposent à l’administrateur de base de données des contraintes de performances et de fi abilité.

Un concentré d’expertise pour le DBA MySQL : les bonnes pratiques, de la conception à l’optimisation Cet ouvrage s’adresse à tous ceux qui conçoivent, exploitent et maintiennent une base de données MySQL et souhai-tent optimiser les performances de leurs serveurs ou rencontrent des problèmes de charge. Il répond aux questions de l’administrateur : que faire en cas de problèmes de performances liés à la base de données ? Quelles directions prendre face à un serveur MySQL réticent, en pleine situation d’urgence alors que les utilisateurs grondent ?Qu’il s’agisse d’une mauvaise gestion de la mémoire vive, de disques saturés, d’une gestion perfectible des index, de requêtes trop gourmandes, de moteurs de stockage inadaptés, etc., cet ouvrage aidera l’administrateur ou le développeur MySQL à trouver le goulet d’étranglement en cause. Non sans décortiquer le fonctionnement du serveur MySQL et de ses différents moteurs (InnoDB, MyISAM, Merge, Memory/HEAP, Archive….), les auteurs guident le DBA à travers toutes les bonnes pratiques d’audit et d’optimisation, de la conception du schéma de la base jusqu’à la résolution des problèmes liés à la réplication, sans oublier de l’éclairer sur les choix matériels à faire pour ses serveurs.

Au sommaireDiagnostic d’urgence et traitements de choc • Procédures adaptées au niveau d’urgence : dix minutes, une heure, une journée • Dans les entrailles de votre serveur MySQL • Caractéristiques physiques et éléments clés du serveur • Mémoire • Disques • CPU • Réseau • 64 bits • Limites de MySQL face au hardware • CPU multicoeur • Réplication monothreadée • Fonctionnement de MyISAM et d’InnoDB • Étude des différents moteurs de stockage • Comprendre son moteur de stockage • MyISAM • InnoDB • Doit-on forcément sacrifi er les performances à la stabilité ? • Analyser le fonctionnement de son serveur MySQL : monitoring • Où trouver les informations pertinentes • Variables système et variables d’état • Quels outils choisir ? • Outils propres à MySQL • mysqladmin / mysqladministrator • Outils externes • iostat et vmstat • top et htop • Détecter les goulets d’étranglement • I/O disques • CPU • Réseau • Évaluer les performances de son serveur • Benchmarks et dimensionnement (capacity planning) • Exploiter les logs • Logs d’erreur • Détection des requêtes coûteuses : slow queries log • Logs système • syslog • dmesg • Problèmes liés à la réplication • Solutions aux problèmes fréquents • Réplication et performance • Réplication et fi abilité • Reprise sur arrêt d’une réplication • Tuning du serveur MySQL • Analyser les tables • Analyser les index • Vérifi er les droits des utilisateurs • Fichier de confi guration de MySQL • Le « trop » ennemi du « bien » ? • Les paramètres qu’il faut maîtriser • Où trouver de l’aide • Blogs • Forums.

Code

édi

teur

: G

1263

4IS

BN :

978

-2-2

12-1

2634

-1

Conc

eptio

n :

Nor

d Co

mpo

35 €

À qui s’adresse cet ouvrage ?– À tous les administrateurs de bases de données en quête de performances ;– Aux DBA MySQL souhaitant aiguiser leur capacité à auditer et optimiser leurs bases ;– Aux administrateurs système souhaitant approfondir leur compréhension des relations entre une base MySQL et les

matériel et système d’exploitation sous-jacents ;– Aux développeurs (Java, PHP, Ruby, Python…) utilisant MySQL et rencontrant des problèmes de performances.




Bonnes pratiques pour l’administrateur




P.

Bo

rg

hin

oO

. D

as

ini

A.

Ga

da

lM

ySQ

L 5

Aud

it et

opt

imisa

tion

Les auteursPascal Borghino est architecte de bases de données chez Yahoo! International. Il est confronté au quotidien à de nombreux problèmes, tant au niveau du design, de l’extensibilité que des performances. Il est président et fondateur du MySQL User Group Francophone (LeMUG.fr) et créateur du blog www.dbnewz.com. Olivier Dasini a 10 ans d’expérience en tant que consultant et formateur certifi é MySQL. Aujourd’hui expert en bases de données chez Orange Business Services, il milite pour la promotion des logiciels libres et est également fondateur du blog de vulgarisation autour de MySQL http://dasini.net/blog. Il est co-fondateur du MySQL User Group Francophone LeMUG.fr.

Arnaud Gadal est l’administrateur des bases de données MySQL de Virgin Mobile. Il est certifi é MySQL 5 (développement, administration, cluster), membre du MySQL User Group et principal auteur sur www.dbnewz.com

La grande majorité des applications web s’adossent à la base de données MySQL et imposent à l’administrateur de base de données des contraintes de performances et de fi abilité.

Un concentré d’expertise pour le DBA MySQL : les bonnes pratiques, de la conception à l’optimisation Cet ouvrage s’adresse à tous ceux qui conçoivent, exploitent et maintiennent une base de données MySQL et souhai-tent optimiser les performances de leurs serveurs ou rencontrent des problèmes de charge. Il répond aux questions de l’administrateur : que faire en cas de problèmes de performances liés à la base de données ? Quelles directions prendre face à un serveur MySQL réticent, en pleine situation d’urgence alors que les utilisateurs grondent ?Qu’il s’agisse d’une mauvaise gestion de la mémoire vive, de disques saturés, d’une gestion perfectible des index, de requêtes trop gourmandes, de moteurs de stockage inadaptés, etc., cet ouvrage aidera l’administrateur ou le développeur MySQL à trouver le goulet d’étranglement en cause. Non sans décortiquer le fonctionnement du serveur MySQL et de ses différents moteurs (InnoDB, MyISAM, Merge, Memory/HEAP, Archive….), les auteurs guident le DBA à travers toutes les bonnes pratiques d’audit et d’optimisation, de la conception du schéma de la base jusqu’à la résolution des problèmes liés à la réplication, sans oublier de l’éclairer sur les choix matériels à faire pour ses serveurs.

Au sommaireDiagnostic d’urgence et traitements de choc • Procédures adaptées au niveau d’urgence : dix minutes, une heure, une journée • Dans les entrailles de votre serveur MySQL • Caractéristiques physiques et éléments clés du serveur • Mémoire • Disques • CPU • Réseau • 64 bits • Limites de MySQL face au hardware • CPU multicoeur • Réplication monothreadée • Fonctionnement de MyISAM et d’InnoDB • Étude des différents moteurs de stockage • Comprendre son moteur de stockage • MyISAM • InnoDB • Doit-on forcément sacrifi er les performances à la stabilité ? • Analyser le fonctionnement de son serveur MySQL : monitoring • Où trouver les informations pertinentes • Variables système et variables d’état • Quels outils choisir ? • Outils propres à MySQL • mysqladmin / mysqladministrator • Outils externes • iostat et vmstat • top et htop • Détecter les goulets d’étranglement • I/O disques • CPU • Réseau • Évaluer les performances de son serveur • Benchmarks et dimensionnement (capacity planning) • Exploiter les logs • Logs d’erreur • Détection des requêtes coûteuses : slow queries log • Logs système • syslog • dmesg • Problèmes liés à la réplication • Solutions aux problèmes fréquents • Réplication et performance • Réplication et fi abilité • Reprise sur arrêt d’une réplication • Tuning du serveur MySQL • Analyser les tables • Analyser les index • Vérifi er les droits des utilisateurs • Fichier de confi guration de MySQL • Le « trop » ennemi du « bien » ? • Les paramètres qu’il faut maîtriser • Où trouver de l’aide • Blogs • Forums.

Conc

eptio

n :

Nor

d Co

mpo

À qui s’adresse cet ouvrage ?– À tous les administrateurs de bases de données en quête de performances ;– Aux DBA MySQL souhaitant aiguiser leur capacité à auditer et optimiser leurs bases ;– Aux administrateurs système souhaitant approfondir leur compréhension des relations entre une base MySQL et les

matériel et système d’exploitation sous-jacents ;– Aux développeurs (Java, PHP, Ruby, Python…) utilisant MySQL et rencontrant des problèmes de performances.



Audit et optimisation

MySQL 5Bonnes pratiques

pour l’administrateur


Chez le même éditeur

J.-M. Defrance. – Premières applications web avec Ajax, jQuery et PHP. N°12672, 2010, 474 pages

J. Gabès. – Nagios 3 pour la supervision et la métrologie. Déploiement, configuration et optimisation. N°12473, 2009, 510 pages

T. sarlanDie. – Programmation iPhone OS 3. Conception, ergonomie, développement et publication. N°12477, 2009, 276 pages

S. Jaber. – Programmation GWT 2. Développer des applications RIA et Ajax avec le Google Web Toolkit. N°12569, 2010, 484 pages

P. sultan, dirigé par N. Makarévitch. – Asterisk. Études de cas. (coll. Cahiers de l’Admin). N°12434, 2010, 298 pages.

r. riMelé. – Mémento MySQL. N°12720, 2e édition 2010, 14 pages.

c. Pierre De Geyer, G. Ponçon. – Mémento PHP 5 et SQL. N°12457, 2e édition 2009, 14 pages.

r. M. stallMan, s.WilliaMs, c. Masutti (Framasoft). – Richard Stallman et la révolution du logiciel libre. Une biographie autorisée. N°12609, 2010, 344 pages.

H. bersini, i. Wellesz. – La programmation orientée objet. Cours et exercices en UML 2 avec Java 5, C# 2, C++, Python et PHP 5. N°12441, 4e édition, 2009, 602 pages (collection Noire).

v. MessaGer rota. – Gestion de projet. Vers les méthodes agiles. n°12518, 2e édition 2009, 272 pages (collection Architecte logiciel).

J.-L. bénarD, l. bossavit , r. MéDina , D. WilliaMs. – Gestion de projet eXtreme Programming. N°11561, 2002, 300 pages (collection Architecte logiciel).

A. fernanDez-toro, préface de h. schauer (HSC Consultants). – Management de la sécurité de l’information. Implémentation ISO 27001. Mise en place d’un SMSI et audit de certification. N°12622, 2e édition, 2009, 284 pages.

G. Ponçon. – Best practices PHP 5. Les meilleures pratiques de développement en PHP.N°11676, 2005, 480 pages.

L. Bloch, C. WolfhuGel. – Sécurité informatique. Principes et méthode à l’usage des DSI, RSSI et administrateurs. N°12525, 2009, 292 pages.

F. Potencier et H. haMon. – Symfony. Mieux développer en PHP avec Symfony 1.2 et Doctrine.N°12494, 2009, 510 pages.

G. Ponçon et J. Pauli. – Zend Framework.N°12392, 2008, 460 pages.

pII.indd 1 02/03/10 17:41





Audit et optimisation

MySQL 5Bonnes pratiques

pour l’administrateur


Éditions Eyrolles61, bd Saint-Germain75240 Paris Cedex 05

www.editions-eyrolles.com

Le code de la propriété intellectuelle du 1er juillet 1992 interdit en effet expressément la photocopie à usage collectif sans autorisation des ayants droit. Or, cette pratique s’est généralisée notamment dans les établissements d’enseignement, provoquant une baisse brutale des achats de livres, au point que la possibilité même pour les auteurs de créer des œuvres nouvelles et de les faire éditer correctement est

aujourd’hui menacée.En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou partiellement le présent ouvrage, sur quelque support que ce soit, sans l’autorisation de l’Éditeur ou du Centre Français d’exploitation du droit de copie, 20, rue des Grands Augustins, 75006 Paris.© Groupe Eyrolles, 2010, ISBN : 978-2-212-12634-1

pII.indd 2 02/03/10 17:41

Un ouvrage en français pour aller plus loinL’idée de départ de cet ouvrage fut d’écrire ce que nous-mêmes aurions aimé trouveren librairie au rayon MySQL.

Le contenu que nous vous proposons aujourd’hui, et qui sera détaillé dans quelquesparagraphes, est le fruit de la diversité de nos expériences respectives (un administra-teur base de données, un expert MySQL et un architecte bases de données). En par-courant ce livre, vous profiterez de nos expériences acquises auprès de grandscomptes de l’univers Internet, tels que Orange Business Services, Virgin Mobile ouencore Yahoo!

Nous souhaitions écrire un livre permettant de mieux comprendre à la fois MySQLen tant que pièce logicielle, mais aussi son lien avec le serveur physique sur lequelcette base de données est installée. Cette subtile interaction entre logiciel et matérieloù interviennent plusieurs centaines de variables et autres paramètres, est susceptibled’atteindre de hautes performances lorsque tous agissent de concert.

Cependant, il ne s’agit pas uniquement de décrire les mécanismes responsables desmultiples comportements de MySQL observés ; il faut surtout les expliquer.

Directement issu de nos vies professionnelles, cet ouvrage est un reflet condensé denos différentes expériences. Ce que vous lirez ici, nous l’avons vraiment vécu. Lesfortes charges, les pics d’affluence, les corruptions de données, les requêtes qui n’enfinissent pas, une volumétrie qui explose, des réplications en échec, des serveursMySQL à l’agonie... nous y avons tous goûté !

Fort heureusement, les problèmes que nous venons d’évoquer ne sont pas une fatalitéet les bonnes pratiques exposées dans cet ouvrage vous permettront de les éviter pourla plupart ou, en tout cas, de les gérer au mieux. Rassurez-vous, les différents chapi-tres qui vont suivre ne sont pas une suite de récits de cataclysmes MySQL ! Au con-

Avant-propos


MySQL 5 – Audit et optimisationVI

traire, il s’agit plutôt de prévenir ces écueils en adoptant les bonnes techniques quivous permettront, à vous qui gérez ou utilisez au quotidien des bases MySQL, de lesutiliser le mieux possible.

Le titre, MySQL 5 - Audit et optimisation, résume le cœur de l’ouvrage. En analysanttechniquement un serveur MySQL lors de la phase d’audit, nous établissons un dia-gnostic qui permettra les optimisations appliquées sur cette machine. C’est ainsi quetous les chapitres apportent leur valeur ajoutée à cette thématique.

Nous ne connaissions pas d’ouvrage en français rassemblant l’étendue des thèmesévoqués ici. Le livre que vous tenez entre les mains n’est pas simplement du contenupointu « en français ». Sa plus-value réside également dans notre fort intérêt pourMySQL. Nous sommes trois passionnés de cette base de données (bloggeurs, asso-ciation LeMug.fr) et notre but tout au long du livre est de vous faire partager cettepassion tout en décortiquant les mécanismes de MySQL de façon claire et pratique.Encarts, schémas et exemples étayeront notre propos et vous guideront tout au longdu chemin que nous vous avons tracé vers l’optimisation de vos serveurs MySQL.

À qui s’adresse cet ouvrage ?Cet ouvrage est particulièrement destiné à tous ceux qui ont déjà des connaissancesde base en MySQL et qui sont soumis à des problèmes liés à une activité croissantesur leurs bases de données.

Qu’il s’agisse d’une audience croissante, de données de plus en plus lourdes ou encored’engranger rapidement de nouvelles connaissances pointues sans avoir à parcourirtoute la blogosphère anglophone, ce livre saura vous apporter des solutions concrètesou vous aiguiller vers la bonne façon de faire.

De par son contenu, cet ouvrage s’adresse plutôt aux administrateurs de bases dedonnées, qu’ils soient spécialistes de MySQL ou pas, qu’aux développeurs. Cepen-dant, les plus curieux d’entre eux trouveront des informations sur l’optimisation deleurs requêtes et sur les différences entre les moteurs de stockage, par exemple.

Pour les administrateurs MySQL, nous avons essayé d’apporter le maximum d’infor-mations utiles à leur métier, notamment sur les outils que nous utilisons pour auditerun serveur, l’optimiser, mesurer ses performances, anticiper ses problèmes... Vous ytrouverez donc tous nos meilleurs conseils.


Avant-propos VII

Structure de l’ouvrageL’ouvrage est découpé en huit chapitres qu’il est possible d’aborder indépendammentles uns des autres. Si certains thèmes sont abordés dans plusieurs chapitres, nous lesignalons par des renvois appropriés. De notre point de vue, seul le chapitre « Gérerune situation d’urgence avec MySQL » devait apparaître en premier, l’ordre de lec-ture des autres chapitres n’ayant que peu d’importance.

Si vous êtes particulièrement intéressé par la réplication, vous avez notre bénédictionpour attaquer directement par le chapitre 7.

Outre les liens entre chapitres que nous venons d’évoquer et la possibilité de ne lireque certains chapitres, c’est en lisant l’intégralité de l’ouvrage que vous aurez une vued’ensemble de toutes les techniques décrites, ce qui vous rendra plus efficace.

De plus, nous n’avons pas multiplié le nombre de chapitres artificiellement maischoisi au contraire de restreindre notre champs d’étude aux notions les plus impor-tantes selon nous concernant l’audit et l’optimisation d’un serveur MySQL.

Nous débuterons donc par MySQL et l’urgence (chapitre 1). Que faire quand rienne va plus ? Les bases de données sont un domaine où ne rien faire est parfois lameilleure des solutions... dans l’attente de trouver une réponse adaptée ; et où« tenter » quelque chose sans en analyser les conséquences est potentiellement dra-matique et à éviter. Dix minutes, une heure ou une journée, voici les trois scénarios« d’urgence » que nous vous proposons de résoudre dans ce premier chapitre, le toutagrémenté de nos meilleurs conseils dans un tel contexte.

Le chapitre 2, « Choisir son serveur MySQL », met l’accent sur les impacts du maté-riel sur MySQL. La mémoire, les disques (RAID et cartes contrôleur, SSD), les pro-cesseurs (quantité, combien de cœurs ?), ces éléments ont une importance crucialepour la base de données. Apprenez à les choisir.

InnoDB, MyISAM, Memory, Archive... une des spécificités de MySQL est de pou-voir connecter au serveur plusieurs « moteurs » de stockage, encore faut-il le faire àbon escient. Rendez-vous au chapitre 3 pour mesurer quels sont les impacts du choixd’un moteur par rapport à un autre. Saviez-vous par exemple que le plan d’exécutionde vos requêtes varie en fonction du moteur ? Comment fonctionnent les index oules caches selon les moteurs, quelles sont les forces et les faiblesses de chacun ?Toutes les informations dont vous avez besoin pour choisir le moteur qu’il vous fautse trouvent ici.

Le chapitre 4 vous aidera à connaître l’état de santé de votre serveur MySQL.Prendre le pouls d’un serveur nécessite de comprendre le fonctionnement des varia-bles système et des variables de statut. Quels sont les liens qui les unissent et lesoutils qui les exploitent ? Vérifier l’état de santé du moteur InnoDB lui-même, pré-


MySQL 5 – Audit et optimisationVIII

voir la capacité maximale de votre système (capacity planning) et une étude de cassont au programme.

Les journaux MySQL sont détaillés au chapitre 5. Ne sous-estimez pas la puissancedes logs. Bien exploités, ils seront un allié de premier ordre non seulement en cas decoup dur mais également au quotidien. Jugez plutôt : journalisation des erreurs, logsdes requêtes lentes, logs binaires pour la réplication, les logs sont partout.

Les chapitres 6 et 7 baignent dans l’optimisation. Les index, les requêtes, l’étude duserveur lui-même (variables clés du fichier my.cnf), les caches en tous genres, maisaussi les optimisations propres à certains moteurs de stockage ainsi que le partition-nement sont autant de notions abordées dans ce chapitre.

La réplication se dévoile au chapitre 8. Cette fonctionnalité cruciale offerte parMySQL y est traitée avec beaucoup de détails. À quoi sert-elle, comment la mettreen place, quelles sont les commandes clés sur le maître et l’esclave ? Les différentesarchitectures disponibles et la résolution des problèmes liés à cette technologie sontégalement au programme.

Enfin, si d’aventure notre ouvrage vous laissait avec des questions en suspens, lechapitre 8 indique où trouver de l’aide. Souhaitez-vous obtenir une aide de touteurgence ou simplement poser une question générale sur un forum ou une mailing-listadéquate ? Peut-être cherchez-vous les meilleurs blogs francophones ou anglophonespour enrichir vos connaissances ? Vous y trouverez nos meilleures adresses.

RemerciementsPlus attendue que la gloire éternelle liée à la rédaction d’un ouvrage technique, l’écri-ture de ces quelques paragraphes de remerciements fait sans doute partie d’une desmotivations principales d’un auteur, nous nous plions donc volontiers à cette tradition.

Écrire ce livre à plusieurs mains a été pour moi une expérience enrichissante engrande partie grâce au professionnalisme de mes co-auteurs. Je tenais donc première-ment à remercier Arnaud et Olivier pour leur travail et leur bonne humeur. Ensuite,nos éditrices Muriel Shan Sei Fan et Sophie Hincelin, ainsi que Pascale Sztajnbok etGaël Thomas de l’équipe éditoriale d’Eyrolles qui ont pu gérer avec patience noslégers retards et nous ont permis de nous focaliser sur le contenu et le fond. Ce livren’aurait pas vu le jour non plus sans Véronique Loquet d’ALX communication, dontla passion et la connaissance du monde de l’open source ont su nous ouvrir les portesnécessaires. Encore merci Véronique !


Avant-propos IX

Je voulais aussi remercier mes managers qui ont permis mon implication dans lemonde de MySQL, dans l’ordre : Rémy, Bruno, Dana et Rusty... Je n’oublie pas nonplus mes formidables amis de la communauté MySQL elle-même : merci Jeremy,Éric et toute la bande.

Enfin, merci à mes parents Daniel et Danielle qui seront toujours à la source de tousmes accomplissements...

Pascal Borghino

Je remercie mes deux amis, co-auteurs et gourous MySQL, Arnaud et Pascal, sansqui ce livre n’aurait jamais vu le jour. Je tiens également à y associer toute l’équipe deMySQL France, notamment Stéphane Varoqui et Serge Frezefond pour leur savoirinfini. Merci à tous les passionnés du logiciel libre rencontrés au fil des années, sur lesforums, les salons, dans les associations (LeMUG.fr, l’AFUP, l’April...) et sur monblog (http://dasini.net/blog/).

Une tendre pensée pour mes parents Jean et Jocelyne, mes sœurs Karen et Linda,mon frère Floriant et à Kapinou (pour ta patience).

Enfin, je dédie ce livre à la mémoire de Valérie et Paul BERCHEL, ainsi que celle deRaymond DASINI.

Olivier Dasini

Je ne crois pas au destin mais plutôt au timing et un peu au hasard. Début 2006, jequittais Paris pour trois ans au détour d’un job d’ingénieur développement PHP pourle soleil de Sophia-Antipolis. Au bout d’un an, alors que je renforçais sérieusementmes connaissances MySQL, deux collègues là-bas ont probablement fait basculer macarrière. Tout d’abord Gilles Oliveri (merci), qui a remarqué que je serais peut-êtremieux employé à faire du MySQL que du PHP chez Orange, puis Cyril Scetbon(merci) qui m’a fait confiance et m’a accueilli dans la cellule Bases de données où j’aipu apprendre, parfaire mes connaissances et surtout les mettre en pratique.

En 2008, ma passion pour MySQL m’a poussé à me rendre à la conférence annuellede MySQL en Californie. Là-bas, Damien Seguy (merci) m’a présenté à Pascal(merci) qui m’a proposé de blogger pour dbnewz.com lors d’un MySQL Quizz Showalors que je lui reprochais de ne pas publier assez souvent ! Pas rancunier l’animal...

Quant à Olivier (merci), j’ai rencontré sa bonne humeur légendaire lors d’un forumPHP/MySQL il y a quelques années. À croire que toutes les routes mènent àMySQL...


MySQL 5 – Audit et optimisationX

Mi-2009, Pascal et Olivier m’ont proposé d’être le troisième homme pour la rédac-tion de cet ouvrage. J’ai accepté avant de savoir que j’aurais à les relire... Une purefolie... que je ne regrette pas ! Merci encore à tous les deux.

À toute l’équipe Eyrolles qui a pris soin de nous pendant toute cette aventure, merci.

Enfin, à vous qui lisez ces quelques lignes, merci. Autant de motivation pour lire unavant-propos est très bon signe pour la suite.

Bonne lecture !

Arnaud Gadal


Table des matières

CHAPITRE 1Gérer une situation d’urgence avec MySQL ................................ 1

À chaque degré d’urgence sa panoplie d’outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Temps de résolution : dix minutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Étape 0 : informez et communiquez ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Ne restez pas seul et discutez avec d’autres administrateurs . . . . . . . . . . . . . . . . 3Consultez les informations système : journal d’erreurs, activités disques et processeur... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Tentez de vous connecter à la base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

ATTENTION Précautions à prendre avec une table MyISAM corrompue . . . . . . . . . . . . . . . . 4ASTUCE Défilement page par page pour SHOW FULL PROCESSLIST . . . . . . . . . . . . . 5À SAVOIR Éviter l’empilement des requêtes et décrypter le SHOW PROCESSLIST . . . . . . 5REMARQUE Se référer aux chapitres concernés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Supprimer les requêtes les plus lourdes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6PRATIQUE Supprimer des requêtes rapidement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Éviter que l’authentification des utilisateurs repose sur un DNS : l’erreur unauthenti-cated user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Consulter son système de surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Tranche de vie d’une campagne marketing improvisée . . . . . . . . . . . . . . . . . . . . . . . . 9Temps de résolution : une heure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

La chasse aux requêtes lentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10À LIRE Un chapitre consacré à l’étude des journaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Réécrire les requêtes trop coûteuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10ASTUCE Les tables statiques à la rescousse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Les problèmes de réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Temps de résolution : une journée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13LIRE Chapitre 8 consacré à la réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13PRATIQUE Un problème peut en cacher un autre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Conseils généraux face à l’urgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Tirer profit du passé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Anticiper les problèmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

ATTENTION Modifications à chaud, en production . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15


MySQL 5 – Audit et optimisationXII

L’entraînement à l’urgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Enregistrer les données de l’incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16L’état d’esprit à adopter dans l’urgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Trouver de l’aide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

CHAPITRE 2Choisir son serveur MySQL ......................................................... 19

La mise à jour matérielle, une étape nécessaire ? . . . . . . . . . . . . . . . . . . . . . . . . . . 20Les questions à se poser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20ASTUCE Identifier les goulets d’étranglements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20ASTUCE Optimiser son serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21JARGON Scaling up, scaling out et scaling back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Du 64 bits oui... mais partout ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Limites des systèmes 32 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23ATTENTION Ne soyez pas trop gourmands ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23RESSOURCES EN LIGNE Davantage de détails sur l’adressage mémoire . . . . . . . . . . . . . . . . . . 24

Choisir ses processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25État des lieux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Les solutions face aux problèmes de montée en charge . . . . . . . . . . . . . . . . . . 25JARGON Architecture SMP vs NUMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25REMARQUE La compétition omniprésente entre les différents acteurs . . . . . . . . . . . . . . . . 26À LIRE ÉGALEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Choisir son processeur : les critères de choix . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Quelle est l’utilisation actuelle de vos processeurs ?. . . . . . . . . . . . . . . . . . . . . . . 27À SAVOIR MySQL et la gestion des threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Fréquence vs nombre de cœurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28JARGON OLTP, OLAP : deux catégories de systèmes à gérer différemment . . . . . . . . . . . 28

Benchmarks, encore et toujours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29À LIRE ÉGALEMENT Mesurer les performances de son système . . . . . . . . . . . . . . . . . . . . . . . . 29RAPPEL Configurer son serveur MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30ASTUCE Pour aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Choisir ses disques et son système RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31À SAVOIR Temps d’accès mémoire vs temps d’accès disques . . . . . . . . . . . . . . . . . . . . . . . 32Temps d’accès versus taux de transfert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32À RETENIR Lecture/écriture aléatoire ou séquentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 33La technologie RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34ATTENTION La réplication et la montée en charge des écritures . . . . . . . . . . . . . . . . . . . . 34

Les principaux niveaux de RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34REMARQUE Les opposants au RAID 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36RESSOURCES EN LIGNE D’autres niveaux de RAID existent . . . . . . . . . . . . . . . . . . . . . . . . . 37

Les deux implémentations du RAID : logicielle et matérielle. . . . . . . . . . . . . . . 38REMARQUE Carte contrôleur RAID, force et faiblesse à la fois . . . . . . . . . . . . . . . . . . . . . 38


Table des matières XIII

Intérêt du cache sur une carte contrôleur RAID . . . . . . . . . . . . . . . . . . . . . . . . 39RAPPEL Le cache de requêtes en amont de la carte RAID . . . . . . . . . . . . . . . . . . . . . . . 40BON À SAVOIR Les outils pour vérifier les réglages de sa carte contrôleur . . . . . . . . . . . . . . . 41

Indispensable batterie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42EN PRATIQUE Durée de vie de la batterie d’une carte RAID . . . . . . . . . . . . . . . . . . . . . . 42

Le cache interne des disques : une arme à double tranchant . . . . . . . . . . . . . . . . 42JARGON innodb_flush_method = O_DIRECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43À LIRE ÉGALEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Les SSD : futur hit ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

MySQL et la mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Comment MySQL utilise-t-il la mémoire ? . . . . . . . . . . . . . . . . . . . . . . . . . . 46

CHAPITRE 3Les moteurs de stockage ............................................................ 49

Mécanismes d’un moteur de stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Installation et suppression d’un moteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52ATTENTION Suppression d’un moteur de stockage utilisé par une table . . . . . . . . . . . . . . . . 54Les forces en présence : moteurs utilisé par l’application . . . . . . . . . . . . . . . . . 54B.A.-BA Créer ses tables à partir de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55CONVENTIONS TERMINOLOGIQUES Base de données, serveur, instance, schéma . . . . . . . . . . . . . . . . 57Les critères de choix d’un moteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Moteurs disponibles : InnoDB, MyISAM, Merge, Memory, Archive . . . . . . . . 58Le moteur InnoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58B.A-BA Les propriétés ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60BON À SAVOIR Le MVCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60ASTUCE Sortir une table d’un tablespace partagé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63POUR ALLER PLUS LOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63MyISAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Mécanismes internes de MyISAM et formats de stockage . . . . . . . . . . . . . . . . . 67B.A.-BA Chaud, froid ou tiède ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67RAPPEL Mécanisme d’une commande ALTER TABLE . . . . . . . . . . . . . . . . . . . . . . . 68Le moteur MERGE pour agréger plusieurs tables MyISAM . . . . . . . . . . . . . 69Le moteur MEMORY (anciennement HEAP) . . . . . . . . . . . . . . . . . . . . . . . 71Le moteur ARCHIVE pour un archivage compressé . . . . . . . . . . . . . . . . . . . 72Autres moteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

XtraDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Falcon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Federated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Blackhole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74


MySQL 5 – Audit et optimisationXIV

IBMDB2I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74NDB (Network Database) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Moteurs communautaires et autres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Maria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75PBXT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75BLOB Streaming Engine (MyBS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Mdbtools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Kickfire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77TokuDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Spider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Rethinkdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

CHAPITRE 4Surveiller son serveur MySQL..................................................... 81

Où trouver les informations pertinentes ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Variables système et variables de statut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82DÉFINITION Variables système ou de statut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82ALTERNATIVE Récupérer les variables système ou de statut . . . . . . . . . . . . . . . . . . . . . . . . 82Quels outils choisir ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83À SAVOIR Variables système et my.cnf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83ATTENTION Une valeur peut en cacher une autre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84À SAVOIR Différence entre un client et un outil MySQL . . . . . . . . . . . . . . . . . . . . . . . . 84Intérêt des outils de surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84B.A.-BA key_buffer_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Outils et commandes fournis par MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85ATTENTION Variables globales vs variables de session . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Catégorie General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87B.A.-BA MySQL vs mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88ASTUCE Les jokers dans les commandes MySQL : % et _ . . . . . . . . . . . . . . . . . . . . . . . 89LE SAVIEZ-VOUS Deux descripteurs de fichiers pour une table MyISAM . . . . . . . . . . . . . . . 89

Catégorie Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91À SAVOIR Le cache de requête (Query Cache ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91RAPPEL Le cache MyISAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93RAPPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94À SAVOIR Ajuster la taille du cache d’index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94ATTENTION Sortir un serveur client de la liste noire d’un serveur MySQL . . . . . . . . . . . . . 99À SAVOIR Droits nécessaires aux commandes SHOW STATUS et SHOW VARIABLES . . 99ASTUCE Optimiser et analyser une requête avec USE INDEX/IGNORE INDEX . . . . . 104La commande SHOW ENGINE INNODB STATUS . . . . . . . . . . . . . . . . 104À SAVOIR Différence entre mutex et sémaphores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106ASTUCE Créer un deadlock délibéré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108À LIRE ÉGALEMENT Le MVCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109


Table des matières XV

INFORMATION_SCHEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Connaître et savoir exploiter les outils de surveillance . . . . . . . . . . . . . . . . . . . . 114

Qu’est-ce que la performance ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115À LIRE Technologie du disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116LVM : la gestion des volumes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117JARGON Transactionnel et cohérence, quelles différences ? . . . . . . . . . . . . . . . . . . . . . . 118B.A.-BA Les différents types de sauvegardes (backups) . . . . . . . . . . . . . . . . . . . . . . . . 119

Étude de cas : analyse d’un serveur MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120RAPPEL write-through/write-back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Mesurer l’activité du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Les outils système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

La commande iostat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125La commande vmstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Les commandes netstat et mpstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

ALTERNATIVE oprofile, dtrace, fincore et filefrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Outils d’audit : MySQLTuner et mysqlreport . . . . . . . . . . . . . . . . . . . . . . . . 127ASTUCE Surveiller son serveur à distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Outils d’analyse temsp réel : mytop, mtop, innotop et maatkit . . . . . . . . . . . . 131

Évaluer les performances d’un système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131JARGON Le smoke test, un test aux limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132MÉTHODE Dimensionnement : les bons tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Bien dimensionner un système (capacity planning) . . . . . . . . . . . . . . . . . . . . 136À SAVOIR La notion de seuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138À LIRE La montée en charge matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138À LIRE Pour aller plus loin dans le domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

CHAPITRE 5Exploiter les journaux de MySQL............................................. 141

Le journal des erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142ASTUCE Rotation des journaux avec logrotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Identifier et résoudre les problèmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Modifier le tablespace ou les journaux d’InnoDB . . . . . . . . . . . . . . . . . . . . . 143Paramètre incorrect dans le fichier de configuration . . . . . . . . . . . . . . . . . . . 144Erreurs liées à la réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Erreurs diverses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147ATTENTION Effets de bord de l’option myisam_recover . . . . . . . . . . . . . . . . . . . . . . . . . 148

Le journal des requêtes lentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148ATTENTION Effets de bord de l’option log_queries_not_using_indexes . . . . . . . . . . . . . . . 149ALTERNATIVE Autres outils d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Journaliser dans une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152


MySQL 5 – Audit et optimisationXVI

Le journal général des connexions et requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . 153Exemples d’utilisations de la journalisation générale ? . . . . . . . . . . . . . . . . . . 154

La journalisation binaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155REMARQUE L’option sync_binlog peut avoir un impact sur les performances . . . . . . . . . . 155TRANCHE DE VIE La technique de Point In Time Recovery en pratique . . . . . . . . . . . . . . . 157REMARQUE Taille du journal binaire en fonction du mode de journalisation . . . . . . . . . . 158

Bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

CHAPITRE 6Optimiser sa base de données : du schéma aux requêtes ..... 163

Conception de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Normalisation/dénormalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164BON À SAVOIR La normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164OUTILS Logiciels de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Ajouter des colonnes dans une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Création de tables d’agrégation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Création de schémas orientés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Des types de données ajustés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167MÉTHODE Un type optimal à un moment donné . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Les jointures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Les index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Index B-tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173B.A.-BA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173BON À SAVOIR Index Fulltext (Plaintext) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Index B+tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175BON À SAVOIR La table de hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Index hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177ALTERNATIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Optimisation des requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Connaître l’optimiseur pour mieux le comprendre . . . . . . . . . . . . . . . . . . . . . 181B.A.-BA La sélectivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181BON À SAVOIR Optimiseurs à base de règles ou de coût (cost based ou rules based) . . . . . . . . 182La commande EXPLAIN pour analyser l’exécution des requêtes . . . . . . . . . . 182PRATIQUE Visualiser le plan d’exécution d’un DELETE ou d’un UPDATE . . . . . . . . . 183REMARQUE Attention à la fonction RAND() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185OUTILS Représentation graphique du plan d’exécution avec Maatkit . . . . . . . . . . . . . . 186BON À SAVOIR Optimisation des index et réorganisation des tables avec ANALYSE TABLE et OPTIMIZE TABLE . . . . . . . . . . . . . . . . . . . . . . . . 187Exemple d’optimisation d’un plan d’execution . . . . . . . . . . . . . . . . . . . . . . . . 187

Indexer les premiers caractères d’une colonne . . . . . . . . . . . . . . . . . . . . . . . . . . 189Index couvrant (covering index) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190


Table des matières XVII

Préfixe d’index (leftmost prefix indexes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190BON À SAVOIR Pas de préfixes d’index pour les index hash . . . . . . . . . . . . . . . . . . . . . . . 190

Taille des index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Récapitulatif des bonnes pratiques d’optimisation des requêtes . . . . . . . . . . . 190

Découper les requêtes complexes en plusieurs plus simples. . . . . . . . . . . . . . . . . 191

CHAPITRE 7Optimiser son serveur mySQL .................................................. 193

Tuning serveur : variables de session, variables globales, handlers . . . . . . . . . . . 193VOCABULAIRE Cache et buffer (tampon) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Les variables de session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

read_buffer_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195read_rnd_buffer_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195sort_buffer_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195join_buffer_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196tmp_table_size et max_heap_table_size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Les variables globales au serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Le cache de table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Le cache de thread. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Table_locks_immediate et Table_locks_waited. . . . . . . . . . . . . . . . . . . . . . . . 198Aborted_clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Aborted_connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Les handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Exemple d’optimisation d’une requête. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Les droits des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Optimisations pour InnoDB, MyISAM et MEMORY . . . . . . . . . . . . . . . . . . 204

Optimisation InnoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Optimisation MyISAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Cache d’index multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Optimisation Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207ATTENTION Limiter la taille des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207RAPPEL Limitations du moteur Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Le cache de requêtes (query cache) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Gestion du cache de requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210ATTENTION Taille du cache de requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Le partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211Le partitionnement par RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213Le partitionnement par LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Le partitionnement par HASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Le partitionnement par KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Partitionner sur différents disques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215


MySQL 5 – Audit et optimisationXVIII

Partitionner sur différents disques avec MyISAM . . . . . . . . . . . . . . . . . . . . . 215BON À SAVOIR Évolution du partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

CHAPITRE 8La réplication MySQL ................................................................ 217

Introduction à la réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Intérêt de la réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Le dimensionnement horizontal (scale out) . . . . . . . . . . . . . . . . . . . . . . . . . . 219La sauvegarde à chaud (hot backup) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Le basculement automatique (Failover) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Redondance géographique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Le cas du décisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Tester une nouvelle version de MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

À l’intérieur de la réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Mise en place de la réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Configuration du maître . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222ATTENTION Mot de passe en clair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222BON À SAVOIR Filtrage des données répliquées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Configuration de l’esclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225REMARQUE Mettre à jour l’esclave avant le maître . . . . . . . . . . . . . . . . . . . . . . . . . . . 226ATTENTION Ancienne méthode de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Configuration avancée de l’esclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Commandes de la réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Sur l’esclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228ATTENTION Conséquences d’un RESET SLAVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228ASTUCE Comment savoir si le serveur esclave a du retard ? . . . . . . . . . . . . . . . . . . . . 230

La commande SHOW SLAVE STATUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Sur le maître . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232ASTUCE Déconnexion d’un serveur esclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232ATTENTION RESET MASTER peut casser la réplication . . . . . . . . . . . . . . . . . . . . . . 233

Problèmes liés à la réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233IO_THREAD stoppé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234SQL_THREAD stoppé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234DANGER Ignorer les erreurs peut provoquer des incohérences . . . . . . . . . . . . . . . . . . . . 235BON À SAVOIR Tables temporaires et réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Architectures de réplication avancées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237REMARQUE MySQL Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Dual master en actif/passif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237DANGER Une réplique n’est pas une sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239OUTILS Supervision des serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239


Table des matières XIX

Exemple : switchover pour une mise à jour online des serveurs MySQL . . . . . 239Récapitulatif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

ALTERNATIVE Commencer par le maître . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Dual master en actif/actif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Récapitulatif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Réplication circulaire (nombre de réplications > 2) . . . . . . . . . . . . . . . . . . . . 244Esclave relais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Récapitulatif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Partitionnement adapté au décisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Récapitulatif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250À SAVOIR Le sharding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

CHAPITRE 9Où trouver de l’aide ? ............................................................... 253

Trouver de l’aide en urgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Les ressources internes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Les ressources externes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Les moteurs de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Le support officiel MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Les organismes externes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Trouver de l’aide hors contexte d’urgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Formations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Où poser votre question ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256L’association LeMug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Les blogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Les forums et mailing-lists MySQL officiels . . . . . . . . . . . . . . . . . . . . . . . . . 257

Aller plus loin et enrichir ses connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257La blogosphère de la communauté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Les séminaires web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Outils et sources de MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259La conférence MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Les certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Index........................................................................................... 261



Problème majeur ou incident moins dramatique, l’un comme l’autre méritent la plushaute attention. En effet, tous deux sont susceptibles d’être résolus rapidement ou aucontraire d’impacter gravement la production. Voici nos conseils pour minimiser lesconséquences de ces aléas qui ponctuent la vie d’une base de données.

Il serait illusoire de recenser ici l’ensemble des problèmes et des solutions associéesque vous pourriez rencontrer sur un serveur MySQL. En revanche, il est possible delister quelques bonnes pratiques en fonction du temps dont vous disposez face à unincident en production. Inutile en effet de se lancer dans un audit poussé du systèmesi vous n’avez que quelques minutes pour rétablir une situation compromise. Cepen-dant, avec un peu plus de temps, une heure voire une journée, le mode opératoire dif-fère complètement. Il est alors possible de rechercher plus longuement les causes duproblème et d’activer si possible d’autres ressources en interne ou en externe, parexemple via du support. Bref, analyser le problème afin qu’il ne se reproduise plus.

À chaque degré d’urgence sa panoplie d’outilsDix minutes, une heure et une journée sont les trois différents degrés d’urgence (arbi-traires) que nous vous proposons dans ce chapitre. Cette distinction peut bien sûr êtrediscutée, l’idée étant néanmoins de classer les problèmes par ordre de priorité. À bien yréfléchir, ces ordres de grandeur ne sont finalement pas si éloignés de la réalité.

1Gérer une situation d’urgence

avec MySQL


MySQL 5 – Audit et optimisation2

Les incidents gravissimes (serveur MySQL qui ne redémarre pas, connexion à la baseimpossible sur un serveur en fonctionnement...) nécessitent une réponse immédiatede votre part car ils ont une incidence directe sur la production. Un délai de résolu-tion de 10 minutes est souhaitable mais laissera malgré tout des traces dans vostableaux de statistiques mesurant les temps de disponibilité de vos applications.

Légèrement moins urgents, les problèmes que l’on souhaite voir régler dans l’heurene sont pas à prendre à la légère non plus. En effet, il peut s’agir de difficultés deréplication, de droits absents ou incomplets pénalisant des utilisateurs ou des scripts,de crash de tables, etc.Enfin, les problèmes de performance sont susceptibles d’appartenir à la catégoried’incidents dont la résolution, ou tout du moins le diagnostic, ainsi qu’un éventail desolutions adaptées, relève de la journée.

Temps de résolution : dix minutesBienvenue à ceux qui savent gérer leur temps ! Joueurs d’échecs, un plus. Voici uneannonce qui sortirait sûrement du lot pour une entreprise souhaitant attirer dans sesfilets un administrateur de bases de données (DBA). En effet, tel un joueur d’échecsconfronté à une partie ultrarapide (5 minutes), le DBA en situation de crise disposede très peu de temps pour tenter de renverser la situation. En cela, dix minutes cons-tituent à la fois un laps de temps très court à l’échelle d’une journée, par exemple,mais on peut également considérer que c’est amplement suffisant pour détecter l’ori-gine du problème. Nous parlons ici de détection, pas encore de résolution.

Étape 0 : informez et communiquez !Identifiez la ou les personnes auxquelles vous devez référer en cas de problème.Celle-ci relayera le message si besoin. L’informatique est plus qu’une question detechnique : un accident grave sur les bases passe rarement inaperçu et vous oblige àcommuniquer. Un incident, en particulier s’il est majeur, sera mieux vécu si les utili-sateurs concernés par cet incident sont mis au courant plutôt que s’ils sont obligés decontacter eux-mêmes les services techniques pour tenter de comprendre pourquoileur application ne répond plus. Prenez les devants et annoncez les conséquences :une réplication hors service implique au mieux un état figé des données sur certainesapplications et au pire un arrêt de certaines d’entre elles, tout dépend de la robustessedu code sous-jacent.

De plus, indiquer aux utilisateurs qu’il existe un problème leur permet d’attendrevotre feu vert avant de renouveler leurs opérations plutôt que de tenter des rafraîchis-sements ou validations supplémentaires qui n’arrangent rien.


Gérer une situation d’urgence avec MySQLCHAPITRE 1

3

Si vous ne pouvez d’ores et déjà annoncer un délai de rétablissement, dites-le. Outrele fait que les utilisateurs soient avertis au plus tôt, communiquer en amont vouspermet également de rester concentré en réduisant le nombre de personnes cherchantà se renseigner auprès de vous (téléphone, messagerie interne, de vive voix...).

Ne restez pas seul et discutez avec d’autres administrateursEn cas d’extrême urgence, partager ses observations, avec un administrateur systèmepar exemple, est une bonne chose. Si le DBA pense en termes de bases (réplication,droits, tables corrompues), l’administrateur système a souvent une vue complémen-taire (place disque, réseau, connectivité aux disques, scripts programmés) ; c’est sou-vent lui qui a installé, ou tout du moins participé à l’installation, de la machine surlaquelle le serveur MySQL s’exécute. Ses connaissances purement techniques ajou-tées à la visibilité qu’il possède sur les machines utilisées par votre département enfont un allié de choix en cas de crise.

Consultez les informations système : journal d’erreurs, activités disques et processeur...Lorsqu’une alerte critique liée à la base de données est levée, une des premièresactions à mener, si l’on ne dispose que d’informations vagues du type « systèmeindisponible », est de consulter le journal d’erreurs de MySQL... À condition depouvoir le faire bien sûr. Si l’un des disques système n’est plus accessible, l’incidentbascule tout d’un coup du côté des administrateurs système. Vous êtes seul et occupezles deux fonctions ? Échangez votre casquette de DBA contre celle de l’administra-teur système le temps que le problème matériel et/ou système soit résolu.

Les journaux d’erreurs sont un passage absolument obligé lorsqu’un incident relatif àla base de données survient. Sa simple lecture peut faire gagner un temps précieux !Problème de réseau ou de réplication, arrêt du serveur, table corrompue, syntaxeincorrecte du fichier de configuration, impossibilité de démarrer un moteur de stoc-kage, etc., l’éventail couvert par le fichier d’erreurs est vaste et bien souvent explicite.

Si sa lecture ne vous a pas suffi, ou s’il n’y a aucune information pertinente à l’inté-rieur, ce qui arrive, quelques commandes système basiques sont à exécuter :• Tout d’abord df -kh pour s’assurer qu’aucune de vos partitions n’est pleine à

100 % ; cela dit le log d’erreurs vous l’aurait signalé.• iostat -dx 5 pour obtenir une vue sur l’activité des disques. • htop ou top permettent quant à eux de repérer si vos processeurs, ou cœurs pour

être plus précis, sont mobilisés et dans quelle proportion.

Espace disque disponible, activité processeur et activité du système disque sont quel-ques investigations qui doivent normalement contribuer à vous éclairer.



Le plus important ici est de récupérer le fichier qui contient la base .MYD. En effet, sivous connaissez la définition de la table concernée, il sera possible de recréer un .frmlui correspondant. Le fichier .MYI, quant à lui, peut également être reconstruit :REPAIR TABLE utilisé avec l’option USE_FRM repartira justement du .frm et les indexseront totalement créés à nouveau.

Pensez également aux logs binaires. Cette remarque est aussi valable pour un moteurtel que InnoDB. Si la partition sur laquelle se trouvaient vos tables MyISAM estperdue, récupérez vos sauvegardes et les logs binaires, puis réinjectez le tout dansMySQL et vous en serez quitte pour une bonne frayeur.

Attention toutefois à exclure de vos logs binaires l’éventuelle instruction SQL dévas-tatrice responsable du carnage... À ce sujet, reportez-vous au chapitre 8, consacré à laréplication.

Tentez de vous connecter à la baseAu-delà des outils système, pouvez-vous vous connecter à la base ? Pouvoir effectuer lacommande SHOW FULL PROCESSLIST est très utile dans ce type de situation. Lorsque labase est chargée, il est efficace de passer par une ligne de commandes pour écrire dansun fichier texte le contenu de cette commande, exemple :

Il sera alors possible d’éditer facilement l’ensemble des requêtes SQL et de les con-server pour étude, le cas échéant, une fois la tempête passée.

L’utilisation de la commande SHOW FULL PROCESSLIST n’est pas forcément chosefacile dans tous les cas : encore faut-il pouvoir se connecter !

ATTENTION Précautions à prendre avec une table MyISAM corrompue

Le maître mot est ici : sauvegardez ! En effet, la documentation le stipule elle-même : il est possible queles procédures de réparation entraînent une perte de données : B http://dev.mysql.com/doc/refman/5.1/en/repair-table.htmlSi possible, veuillez donc sauvegarder les tables MyISAM concernées. En cas d’impossibilité de passer parun outil tel que mysqldump ou mysqlhotcopy, copiez directement les fichiers .MYD, .MYI, et.frm de la table concernée si le serveur est arrêté. Si ce dernier est en marche, la commande FLUSHTABLES WITH READ LOCK vous permet d’effectuer l’opération mais cela peut être coûteux en ter-mes de performance.

shell> mysql -uuser -ppassword -e "SHOW FULL PROCESSLIST;" > /tmp/sfp.txt



5

Si MySQL vous refuse la connexion en indiquant explicitement Too many connec-tions, c’est tout simplement que le nombre défini par max_connections a été atteint.Il reste une chance cependant : MySQL autorise bien max_connections seulement àse connecter simultanément, mais il existe une connexion supplémentaire, notam-ment en cas d’urgence.

Cette connexion n’est disponible que pour des utilisateurs disposant du droit SUPERou l’utilisateur root. Cet utilisateur avisé pourra alors se connecter à la base même sicelle-ci a atteint son nombre maximal théorique de connexions. Rappelons quandmême qu’il est déconseillé de laisser une application se connecter à la base sur lecompte root.

À SAVOIR Éviter l’empilement des requêtes et décrypter le SHOW PROCESSLIST

Chaque serveur MySQL possède une limite maximale de connexions simultanées. Celle-ci est définie parla variable système max_connections. Certains scripts ou applications ne ferment pas correctementleur connexion à MySQL une fois le résultat de celle-ci exploité ; il en résulte un empilement des con-nexions. Celles-ci arborent alors le statut sleep mais occupent malgré tout un emplacement qui ne serapas utilisable par d’autres clients souhaitant se connecter, si la limite de max_connection estatteinte. Pour éviter cela, il est possible d’ajuster la variable wait_timeout. Sa valeur par défaut estde 8 heures, ce qui est énorme. En réduisant cette valeur vous indiquerez au serveur MySQL une nouvellelimite au-delà de laquelle il coupera cette connexion si celle-ci est inactive.Concernant les statuts des requêtes issues d’un SHOW PROCESSLIST (Sending data, Writing to net,Copying to tmp table, etc.), si certains sont évocateurs, d’autres le sont beaucoup moins. La documenta-tion de MySQL en dresse une liste exhaustive : B http://dev.mysql.com/doc/refman/5.1/en/general-thread-states.htmlCependant nous vous conseillons de consulter également la liste, peut-être plus lisible, de Domas Mitu-zas sur son blog : B http://mituzas.lt/2009/09/27/mysql-processlist-phrase-book/Les statuts y sont expliqués de façon beaucoup plus claire.

ASTUCE Défilement page par page pour SHOW FULL PROCESSLIST

L’utilisation de la commande SHOW FULL PROCESSLIST sur un serveur chargé provoque un défile-ment illisible, car trop rapide, des nombreuses requêtes exécutées à cet instant sur le serveur MySQL. Ilest possible de simuler le comportement du défilement page par page (le | more sous Linux, par exem-ple) grâce à la commande suivante :mysql> pager more;

Ainsi, c’est vous qui ferez défiler à votre guise les requêtes affichées par le SHOW FULLPROCESSLIST. Pour retrouver le comportement par défaut du client MySQL, saisissez :mysql> nopager;



En cas d’échec de ce dernier recours, il ne vous reste plus qu’à redémarrer le serveurMySQL pour récupérer des connexions de libres afin de vous connecter. Si le flux deconnexions à la base est tel que vous craignez que la situation ne se renouvelle aus-sitôt une fois le serveur redémarré, sachez qu’il est possible de restreindre les con-nexions entrantes à celles qui sont émises localement. L’ajout de la commande bind-address=127.0.0.1 dans le fichier de configuration my.cnf, permet ce type de limi-tation. skip-networking désactive l’écoute des connexions TCP/IP et n’autorise queles connexions via socket sous Unix.

Supprimer les requêtes les plus lourdesQue vous soyez l’administrateur des bases de données ou non, difficile de connaîtrepar cœur l’intégralité des utilisateurs MySQL en activité sur les différentes bases.

La dénomination des utilisateurs MySQL rend parfois difficile leur rôle au sein du SI.De plus, certains comptes utilisateurs sont susceptibles d’être utilisés par plusieurs pro-jets qui n’ont pas forcément de liens. Il est du coup difficile de mesurer l’importanced’une requête en la rapportant seulement au nom de l’utilisateur MySQL qui l’exécute.

En cas d’extrême urgence, il est du devoir du DBA de sacrifier certaines requêteshautement pénalisantes pour l’ensemble du serveur MySQL afin que le site Internetreste disponible. Les internautes sont préservés au détriment de scripts internes quidevront alors être rejoués.

Aussi, posséder une liste des utilisateurs dont l’activité est vitale pour l’entreprise et àne couper sous aucun prétexte (facturation, livraison...) vous permettra de trier lemoment venu. Fort de cette liste d’intouchables, les requêtes susceptibles d’être sup-primées pour soulager le serveur seront plus facilement identifiables.

REMARQUE Se référer aux chapitres concernés

Nous détaillons le matériel au chapitre 2 et les logs MySQL au chapitre 5 ; c’est pourquoi nous n’aborde-rons pas à nouveau ici le fonctionnement du RAID ou du log d’erreurs, par exemple. Il en va de mêmepour d’autres thèmes évoqués dans ce chapitre tels que la réplication ou la mise en place et l’exploita-tion d’outils de surveillance pour son système.

DANS LA VRAIE VIE

Dans un monde idéal, ces deux types d’activités ne devraient pas s’exécuter en même temps ou en toutcas pas sur le même serveur, mais la réalité économique l’emporte parfois sur les règles de sécurité.



7

Il suffit parfois de supprimer une requête pour débloquer un empilement de con-nexions préjudiciable pour le serveur MySQL. C’est le cas si cette requête n’est pasoptimisée et génère un trop grand nombre de verrous, créant ainsi une file d’attenteimportante. MyISAM et son verrouillage par table est plus impacté qu’InnoDB maisaucun de ces moteurs de stockage n’est à l’abri de tels phénomènes.

PRATIQUE Supprimer des requêtes rapidement

En cas d’urgence, exploiter l’affichage de la commande SHOW FULL PROCESSLIST en ligne de com-mandes via un terminal de type putty peut s’avérer délicat. Si le serveur est chargé votre terminal serasubmergé de requêtes pour la plupart peu lisibles. Un outil tel que mytop permet notamment d’afficherles requêtes par couleur afin de différencier leur temps d’exécution. Il est également possible, à partir del’interface de cet outil, de supprimer les requêtes de votre choix en indiquant leur identifiant.MySQL Administrator est une alternative à ce type de script. Son interface graphique permet de naviguerfacilement sur l’ensemble des requêtes exécutées sur le serveur. Un tri par utilisateurs MySQL est possi-ble, le nombre d’occurrences du même utilisateur est également indiqué et un bouton permet de suppri-mer simplement la requête de votre choix ou toutes celles appartenant à un utilisateur.Si vous n’utilisez pas MySQL Administrator, une alternative est de générer vous-même le fichier des iden-tifiants à supprimer, en utilisant la base information_schema :mysql> SELECT concat('KILL ', id,';') FROM information_schema.processlist WHERE user='user_cible' INTO OUTFILE '/tmp/req2del.txt';

MySQL génère ainsi un fichier comportant une ligne par requête appartenant à l’utilisateur visé, comme :KILL 272;KILL 284;

[…]

Il ne reste plus qu’à l’exécuter :mysql> source /tmp/req2del.txt;

ou shell> mysql -uuser -p < /tmp/req2del.txt

À noter : même détruite, une requête peut prendre un long moment avant de rendre la main. En effet, unROLLBACK d’une grosse opération sous InnoDB peut être très long, il n’y a pas de solution idéale dansce cas là... Si vous redémarrez le serveur vous vous exposez à une récupération de crash d’InnoDB quipeut également prendre un certain temps.Autre solution extrême à réserver à de gros SELECT bloquants sous MyISAM, par exemple : récupérerl’identifiant du thread correspondant à la connexion qui exécute la requête et effectuer un kill -9. Àvous de mesurer les conséquences d’une telle coupure ; avec MyISAM, il n’y a pas de notions de transac-tions et la cohérence de la base est donc peut-être compromise à ce niveau.Encore une fois, testez ces outils par vous-même avant qu’une situation d’urgence ne se déclare. Nosconseils sur la surveillance de vos serveurs occupent le chapitre 4.



Éviter que l’authentification des utilisateurs repose sur un DNS : l’erreur unauthenticated userDifficile de supprimer toutes les requêtes d’un utilisateur particulier si même MySQLne sait pas l’identifier... Ce type de message « unauthenticated user » est visible en casde serveur MySQL très chargé ou en proie à un problème de DNS. Nous vous recom-mandons de ne pas les utiliser lorsque vous définissez un utilisateur MySQL.

Définition d’un utilisateur MySQL basé sur un DNS

Le même exemple sans l’utilisation de DNS

En cas de problème du serveur DNS, MySQL ne pourrait identifier le premier utili-sateur 'me_dns', le qualifiant de unauthenticated user. Si vous rencontrez ce pro-blème, il est probable que vous en veniez à bout en effectuant ces deux actions :• bannir les DNS de la définition de vos utilisateurs ;• démarrer le serveur avec l’option --skip-name-resolve (nous vous conseillons

d’activer cette option).

Consulter son système de surveillanceUne situation d’urgence ? Voici le bon moment pour capitaliser sur vos efforts précé-dents et consulter vos logs ou graphiques d’activité liés à la base.

Un graphique est souvent bien plus explicite que différentes métriques à analyser. Deplus, selon le degré d’historisation que vous utilisez, il est sûrement possible deremonter (pourquoi pas) à l’heure d’origine du problème. Cette dernière informationest cruciale pour incriminer un script programmé dont les impacts ne sont pas forcé-ment simultanés avec son heure de lancement. Pensez par exemple au résultat d’unejointure complexe qui serait stocké par le langage de script afin de générer une bouclede mises à jour mal optimisée, le tout sur une table très volumineuse... L’effet différéest garanti et potentiellement dramatique.

Afin de déterminer si le problème rencontré sur le serveur provient d’une requêteponctuelle passée directement via un client MySQL en production (gestion desdroits à revoir !) ou est issu d’un script programmé, un ordonnanceur permet d’iden-tifier rapidement quel script tourne à quelle heure. Son utilisation est moins fasti-dieuse que le parcours des crontab mais encore faut-il en posséder un. Une fois déter-

mysql> GRANT SELECT on *.* TO 'me_dns'@'dev.example.org' IDENTIFIED BY 'password';

mysql> GRANT SELECT on *.* TO 'me'@'192.168.10.11' IDENTIFIED BY 'password';



9

minée l’heure probable de l’origine du problème, comparez celle-ci avec cellesprésentées par l’ordonnanceur.

Une augmentation brutale du nombre de requêtes peut provenir d’un problème ducache : soit celui-ci a été brutalement désactivé ou invalidé (query cache) soit votresystème basé sur memcached est défectueux.

Figure 1–1Posséder un historique sur l’activité des bases est d’une grande utilité, exemple avec MySQL Enterprise Manager.

Tranche de vie d’une campagne marketing improvisée

Votre système de surveillance est en alerte, les diodes rouges remplacent frénétique-ment leurs paisibles ancêtres de couleur verte bien plus rassurant. Pourquoi ? Lestâches programmées ne sont pas incriminées : les crontab ont été passées au peignefin. Les développeurs vous jurent qu’ils n’y sont pour rien. Finalement, une fois latempête passée, quelqu’un a déclenché le lancement d’une campagne marketingreposant sur des pop-ups dynamiques aux requêtes non optimisées. Outre le pro-blème de communication entre les départements technique et marketing, l’incidentrévèle qu’un seul et même utilisateur peut à lui seul occuper 100 % des connexionsdisponibles sur votre serveur MySQL.Afin d’empêcher qu’un seul utilisateur consomme toutes les ressources, il est possibled’ajouter certaines restrictions par heure à cet utilisateur. Ainsi, le nombre de requê-tes, de mises à jour ou de connexions, sont des limites qu’on peut fixer. De plus, lenombre maximal de connexions simultanées pour un utilisateur est lui aussi configu-rable.Restriction à 200 connexions simultanées maximum pour un utilisateur existant :mysql> GRANT USAGE ON *.* TO 'user_pub'@'192.168.200.20' with MAX_USER_CONNECTIONS 200;mysql> SHOW GRANTS FOR 'user_pub'@'192.168.200.20';Grants for [email protected]: GRANT SELECT ON *.* TO 'user_pub'@'192.168.200.20' IDENTIFIED BY PASSWORD '*1270C0C06DEE42FD1618BB99005ADCA2EC9D1E19' WITH MAX_USER_CONNECTIONS 200



Temps de résolution : une heureEstimer que l’on a au moins une heure devant soi signifie probablement que le pro-blème ou ses conséquences est en partie identifié. C’est souvent le cas d’une sur-charge soudaine sur le serveur MySQL. Attribuée à un script programmé, il est pos-sible de retrouver une situation normale en coupant le programme concerné. Le butest ici de ne pas couper brutalement le responsable mais plutôt de l’optimiser.

Si nous disposons d’une heure pour résoudre le problème, cela laisse le temps d’opti-miser une requête complexe et coûteuse, de diffuser le correctif aux équipes concer-nées et d’assister peut-être à une mise en production dans l’heure si le problème sur-vient en heures ouvrables.

La chasse aux requêtes lentesDans l’hypothèse où notre problème soit issu d’une ou plusieurs requêtes trop coû-teuses, le but est tout d’abord de les identifier rapidement puis de les analyser afin deles optimiser. Si votre outil de surveillance préféré (MySQL Administrator, mytop,etc.) est suffisant pour repérer les requêtes les plus lourdes s’exécutant en temps réelsur le serveur, ils ne sont d’aucune utilité pour analyser le passé.

En effet, afin de retrouver les requêtes qui ont pu impacter votre serveur et qui sontdésormais peut-être terminées (mais appelées à s’exécuter de nouveau), des logs sontnécessaires. MySQL possède un fichier de logs dédiés aux requêtes lentes : il s’agitdu slow query log. Celui-ci peut par exemple être exploité par mysqldumpslow oumysqlsla.

Ne recherchez pas uniquement les requêtes les plus lentes mais également les plusfréquentes. En effet, votre charge MySQL est susceptible de provenir d’une grandequantité de petites requêtes n’apparaissant pas dans les logs de requêtes lentes selonle critère utilisé le plus souvent : le temps d’exécution. 100 000 requêtes de0,9 seconde chacune n’apparaissent pas si le long_query_time est défini à uneseconde ; pourtant, celles-ci sont peut-être responsables d’une surcharge serveur.

Réécrire les requêtes trop coûteusesUne heure, cela laisse le temps d’agir sur un nombre restreint de requêtes un peu tropgourmandes. Cependant le temps passe vite : certaines requêtes nécessitent à elles

À LIRE Un chapitre consacré à l’étude des journaux

Au sujet des logs, lire ou relire notre chapitre 5 consacré aux logs MySQL. Il est possible d’agir sur lafaçon dont le serveur MySQL génère les journaux des erreurs, de requêtes lentes ou généraux.Il est précieux, tout particulièrement en situation d’urgence, de connaître leur fonctionnement.



11

seules ce laps de temps pour améliorer les choses. Il est parfois difficile d’analyser lebien-fondé fonctionnel d’une requête complexe multipliant les jointures et les sous-requêtes. Aussi, si cela est possible, proposez au développeur de se joindre à vous pourune première analyse de celles-ci. Les critères de jointures sont-ils toujours pertinents ?

Certains développeurs sont capables de créer du code SQL complexe et valide mais c’estégalement à l’administrateur de bases de données de leur signaler le fonctionnementinterne de MySQL et d’évoquer certaines faiblesses propres à la branche 5.x : sous-requêtes imbriquées et/ou corrélées aux requêtes externes. Désormais au courant denouvelles bonnes pratiques, le développeur est susceptible de corriger lui-même cer-taines des requêtes remontées lors de votre recherche de requêtes lentes, vous laissantainsi du temps disponible pour en corriger d’autres. Une fois la correction du déve-loppeur effectuée, comparez les EXPLAIN avant et après et classez l’affaire si tout va bien.

Nous attirons votre attention sur le fait que mettre en production une requête sanspasser par une phase de test conforme à celle que vous effectuez d’habitude est unesource de régression potentielle. Une situation urgente autorise certains raccourcissusceptibles de vous sortir d’affaire, mais il n’est pas pour autant conseillé d’oubliertoute prudence ; ayez au moins à l’esprit le risque lié à cette pratique.

Nos conseils pour optimiser vos requêtes se situent dans le chapitre 6, consacré àl’optimisation de la base de données.

ASTUCE Les tables statiques à la rescousse

Si vous estimez qu’il est impossible en une heure de venir à bout de toutes les requêtes à corriger, pensezaux tables statiques ou summarized tables. Cela ne fonctionne pas dans tous les cas mais cette techni-que est très efficace si elle convient. L’idée est de générer une fois pour toutes les résultats d’une requêtecomplète et de les insérer dans une autre table. Plutôt que d’exécuter n fois une requête complexe etlente, elle est jouée une seule fois et ses résultats archivés. L’inconvénient, bien sûr, est que le contenu dela table statique ne sera pas mis à jour. À vous donc de définir éventuellement la périodicité de cette opé-ration (vidage de la table et nouvelles insertions à partir de la requête complexe), un script programmé(cron) peut s’en charger. Il est également possible d’utiliser les event au sein même de MySQL, vousen trouverez une description sur l’un de nos blogs : B http://dasini.net/blog/2009/06/16/Cette technique a un sens lorsqu’une requête ne peut être mise en cache très longtemps (résultats invali-dés par MySQL si par exemple l’une des tables impliquées par la requête est mise à jour). Il est égale-ment nécessaire que cette fameuse requête complexe ne soit pas contextuelle à la session d’un inter-naute. Dans ce dernier cas, les tables temporaires peuvent constituer une bonne solution à condition queleur taille maximale ne soit pas un problème (il s’agit de la plus petite valeur entre ces deux variablessystème : max_heap_table_size et tmp_table_size). Dans ce cas la mise en cache dans unetable statique n’aurait pas de sens, le contenu doit servir au plus grand nombre. Il peut donc s’agir d’uncontenu dynamique dont on peut se permettre une fréquence de rafraîchissement inférieure au tempsréel. Un exemple : statistiques et calculs autour des points d’un championnat quelconque. Les résultatsne seront pas obsolètes avant la prochaine épreuve.



Les problèmes de réplicationLe chapitre 8, consacré à la réplication, détaille les mécanismes, la configuration etles commandes nécessaires pour gérer la réplication MySQL. Il est important queson fonctionnement soit bien compris.

En conséquence, nous n’expliquerons pas ici à nouveau les arcanes de la réplication.En revanche, le conseil à retenir dans le cadre d’une situation d’urgence concernantune réplication est de ne pas agir à la légère. En effet, en cas d’erreur de votre part,par exemple lors du redémarrage d’une réplication arrêtée, vous pouvez rendrel’esclave inutilisable avec pour seule issue de recharger complètement les donnéesqu’il contient. L’importance d’un tel incident (esclave hors service) est inversementproportionnelle au nombre d’esclaves possédés. C’est une situation dramatique sivous n’en possédez qu’un seul (faire pointer les applications vers le maître si celui-citient la charge...) mais moins grave si vous en possédez un grand nombre. L’incidentpourrait passer inaperçu si votre système est correctement dimensionné avec unebonne répartition de charge.

Les messages d’erreurs liés à la réplication sont assez variés. Ne pas comprendre l’ori-gine du problème vous expose à de graves difficultés. Il serait inconsidéré d’appliquerà la légère le fameux SET GLOBAL sql_slave_skip_counter=1 indiquant à l’esclavede passer outre le problème qui a généré l’erreur et de sauter à l’instruction suivantedu relay-log. Le risque de désynchronisation entre l’esclave et le maître serait alorsimportant et d’autres erreurs analogues ne manqueraient pas de se produire à plus oumoins courte échéance.

Pire encore, ignorer systématiquement un certain type d’erreurs (slave-skip-errors)sans maîtriser réellement les conséquences de ce réglage, est une grosse erreur.

Selon le type de moteur de stockage que vous utilisez (MyISAM ou InnoDB), et letype de réplication (row based ou statement based) une requête stoppée manuelle-ment sur le maître peut avoir des conséquences différentes sur l’esclave. AvecMyISAM et en mode statement based, par exemple, une requête interrompue sur lemaître provoque :

L’esclave détecte que la requête a été interrompue sur le maître (cette information cir-cule dans le log binaire) et décide de stopper lui aussi la réplication. À vous de vérifierque la ou les tables concernées sur le maître et l’esclave sont bien symétriques : il n’y a

Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;



13

pas de ROLLBACK sur MyISAM. Si c’est le cas, vous pouvez alors utiliser le conseil pro-digué par le message d’erreur SET GLOBAL... et redémarrer la réplication.

La réplication MySQL est asynchrone : une information enregistrée sur le maîtren’est pas immédiatement disponible pour l’instruction suivante sur tous les esclaves.En conséquence, certaines applications ou scripts rencontrent des problèmes. C’est lecas typique cité précédemment : une insertion est jouée sur le maître et le scriptrecherche immédiatement son identifiant correspondant sur l’esclave ; s’il ne letrouve pas, son comportement peut s’en trouver perturbé.

Une façon simple de gérer ce souci est d’effectuer les requêtes de ce type (récupéra-tion d’une clé liée à l’insertion d’un enregistrement) sur le maître.

Temps de résolution : une journéeÀ l’échelle de la journée nous sommes pour ainsi dire sortis de l’urgence. La survie de labase n’est plus une question de minutes mais plutôt de jours. Cependant, le scénarioque nous suivons (rappelez-vous du découpage arbitraire en trois parties) implique quela situation est préoccupante et demande des restructurations parfois importantes.

Une journée ne représente que quelques heures durant lesquelles il va falloir trouverdes solutions. À ce stade le problème est en effet détecté et il s’agit probablement desprémisses d’une montée en charge difficile. Peut-être rencontrez-vous de façonrécurrente des ralentissements à horaires réguliers, des requêtes de plus en pluslentes, des tables sur lesquelles il est difficile d’effectuer des opérations de mainte-nance sans bloquer la production.

Bref, il est temps de prendre le problème à bras-le-corps et d’y consacrer du temps àl’avenir puisque c’est finalement cela dont il s’agit : anticiper les problèmes dedemain.

Face à des problématiques d’une telle envergure, les réponses techniques ne sont pasforcément immédiates, tout du moins pas applicables en pleine journée. Certainesphases sont en effet bloquantes : modification de tables (ALTER TABLE), refonte d’unepartie de l’application (phase de mise en production), remaniement des crons... toutcela mérite quelques tests. Cependant si une opération coup de poing est décrétée surun thème précis, comme résoudre les problèmes récurrents de performance du ser-veur xxx, il s’agit d’agir vite et bien. Toutes les difficultés ne seront probablement pas

LIRE Chapitre 8 consacré à la réplication

Les indisponibilités de la base liées aux changements de structures ALTER, DROP, ou de versions peu-vent être résolus en partie grâce à la réplication.



réglées le soir même mais les solutions à appliquer et les premiers correctifs sontapplicables pour le lendemain (les premiers scripts correctifs sont susceptibles des’exécuter pendant la nuit si votre activité s’y prête).

Afin de dessiner une solution face à une montée en charge avérée ou à venir, un pas-sage par le chapitre 4, consacré à la surveillance de votre serveur, est tout indiqué. Enfonction des conclusions de cet audit, il sera possible d’émettre un planning et declasser les actions à effectuer par priorité ou faisabilité.

Voici un échéancier tel que l’administrateur de bases de données pourrait l’écrire àl’issue d’une telle réunion :• lundi :

– mise à jour matérielle nécessaire (+8 Go RAM et 2 quad-cœurs, attente descomposants) ;

– optimisation des requêtes facturation ;– partitionnement de la table « factures » sur l'environnement de

développement ;– benchmarks de la version partitionnée (mysqlslap) ;

• nuit lundi/mardi : – ALTER TABLE factures (partitions) si tests concluants ;– passer les tables factures_client_xx en InnoDB ;

• mardi : – consulter logs des actions ALTER partitions/passage en InnoDB ;– surveiller cron 10h45 et comparer situation de la veille.

PRATIQUE Un problème peut en cacher un autre

Sur une telle opération, il est souhaitable d’impliquer les utilisateurs concernés par les modifications debase. Il est fréquent qu’en discutant d’un problème de performance les utilisateurs fassent part au DBAqu’ils ont par ailleurs des retours de blocage intermittents à différents horaires, des pertes de connexion(MySQL Server has gone away), etc. Plutôt que d’effectuer plusieurs réunions pour différentsproblèmes sur un même serveur, autant tous les évoquer au moins une fois et tenter de les résoudre enmême temps, si possible. Un passage en InnoDB peut résoudre les problèmes de verrous évoqués par lesutilisateurs ; un index contribuera à accélérer certaines requêtes ainsi que le partitionnement d’une tablevolumineuse. De plus, si la réunion n’est pas purement orientée bases de données, un administrateur sys-tème ou réseau sera le bienvenu pour régler certains problèmes de connexion ou de perte de paquets,constatés éventuellement sur certaines machines.



15

Conseils généraux face à l’urgence

Tirer profit du passéDocumenter les commandes ou procédures clés à appliquer en cas de problème autravers d’un wiki, d’un fichier texte, etc., permet le jour J, quelle que soit l’heure,d’être opérationnel. Pensez à votre état de fraîcheur si l’on vous réveille lors d’uneastreinte à 3h du matin... Ne pas perdre de temps à se rappeler comment éteindre ourallumer certains services importants en plus des procédures liées à l’activité MySQLn’est pas négligeable dans pareilles situations.

Si ce n’est pour vous, faites-le pour les personnes susceptibles de prendre le relais envotre absence. Ce document doit être enrichi régulièrement, au fil des problèmesrencontrés, des changements de serveurs, de DNS, etc.

Anticiper les problèmesC’est évident mais tellement vrai : mieux vaut prévenir que guérir. Lorsque les pro-blèmes surviennent il est parfois déjà trop tard. Outre les urgences quotidiennes,l’administrateur de bases de données doit veiller à se ménager du temps, chaque jourdans l’idéal, pour améliorer l’existant, effectuer quelques opérations de maintenance(OPTIMIZE TABLE, ANALYZE TABLE, CHECK TABLE ou sa version client bien pratiquemysqlcheck), repérer les tables volumineuses susceptibles de poser problème (parti-tionnement nécessaire ?), suivre de près les serveurs du moment, ceux dont l’activitéest particulièrement forte ou importante à un instant précis.

ATTENTION Modifications à chaud, en production

Soyez extrêmement vigilant à l’égard des modifications qui sont susceptibles d’être exécutées à chaudsur les machines de production. Certaines variables système sont en effet modifiables sans redémarragedu serveur MySQL. Il est important d’en mesurer tous les impacts possibles en termes de performance etde stabilité du système. Il est possible de mettre un serveur à plat en modifiant une seule ligne dans unfichier de configuration my.cnf ; par exemple, passer sync_binlog de 0 à 1 peut entraîner unechute dramatique des performances de tout le système disque (au sujet de cette variable, lire égalementle chapitre 8, consacré à la réplication, et le 2, dédié au matériel). De manière générale, il faut reporterdans le fichier de configuration de MySQL toute modification effectuée (et validée) à chaud. Sans cela,cette nouvelle valeur serait perdue au prochain redémarrage du serveur.Quelques bonnes pratiques pour terminer :1. archivez dans un document toute modification effectuée ainsi, afin qu’en cas de problème vous puis-

siez remonter le fil de vos actions. Notez les horaires ;2. reportez ces modifications dans le my.cnf ;3. envoyez par e-mail à votre équipe les modifications effectuées. L’équipe d’astreinte ou les administra-

teurs système pourront ainsi éventuellement mettre en relation un problème et votre modification,accélérant la résolution du cas.



L’entraînement à l’urgenceIl ne suffit pas d’installer un maître et deux esclaves pour se croire à l’abri de toutproblème... Que se passe-t-il en cas de perte du master ? Dans un autre registre, lessauvegardes sont-elles fiables ? On lit souvent qu’il faut tester ses sauvegardes, c’est-à-dire les recharger sur un serveur et s’assurer que les données soient bien présenteset correctes ; mais combien d’entre nous l’effectuons réellement ? Si cela devait seproduire en production, en combien de temps seriez-vous capable de tout remonter ?

Ces types de scénarios catastrophes se produiront un jour ou l’autre et il faut y êtrepréparé. Si les machines vous manquent pour tester tout cela, il est possible d’utiliserdes solutions telles que MySQL Sandbox pour se construire une configuration ana-logue à celle de la production à moindre coût. Autre test intéressant à effectuer surdes serveurs de test : débrancher physiquement le courant et rallumer le tout. Où enest la réplication ? Des tables sont-elles corrompues ? En combien de temps le ser-veur MySQL redémarre-t-il ? Difficile de le deviner : il faut tester. L’utilisation demachines virtuelles permet également de se constituer un parc de machines avec les-quelles s’entraîner.

Enregistrer les données de l’incidentQuel que soit le degré d’urgence dans lequel vous vous trouvez, à des fins immédiatesou pour plus tard, tentez de sauvegarder des informations concernant l’état du ser-veur au moment de l’incident. Le chapitre 4, consacré aux solutions de surveillance,est un bon point d’entrée.

En quelques mots, archiver les résultats de commandes systèmes telles que :

et du côté de MySQL (si cela est possible) :

L’état d’esprit à adopter dans l’urgenceTerminons ce chapitre sur quelques règles élémentaires en cas de coup dur.• Ne paniquez pas, restez concentré.

iostat -dx 5vmstat 1 10top -b -n 1cat /proc/meminfo

SHOW FULL PROCESSLIST;SHOW INNODB STATUS\GSHOW GLOBAL STATUS;



17

• Tentez de mesurer rapidement l’impact du problème sur le reste du système/desapplications.

• Attention aux conclusions hâtives.• Soyez méthodique.• Connaître le fonctionnement des applications est un plus. Sans autres ressources

humaines que vous (en pleine nuit par exemple), vous pourrez agir sur certainsscripts ou identifier plus rapidement la source du problème.

• Dans l’urgence, allez au plus simple.• Si possible, effectuez une sauvegarde de ce que vous manipulez, un service

dégradé vaut mieux que pas de service du tout.

Trouver de l’aide

Vous êtes dépassé par le problème ? Cela arrive. Dans l’intérêt de tous, ne restez pas seul à tenter derésoudre l’affaire si vous n’y arrivez pas et n’avez aucune piste. Si aucune aide n’est disponible en interneet que vous tournez en rond, il est temps de solliciter une aide extérieure. Lisez le chapitre 8 consacré àce sujet. Il existe des services de support joignables par Internet ou par téléphone.



Investissement initial ou mise à jour matérielle, le choix des composants d’un serveurMySQL est une étape cruciale. Tout composant doit être choisi avec soin, tant lesystème disques, que la mémoire, ou le processeur.

Regrouper les meilleurs composants du marché dans chaque domaine (disque,mémoire, processeur), en plus d’être une démarche très onéreuse, ne suffit pas às’assurer que l’on atteindra les performances souhaitées. En effet, le serveur MySQLlui-même et les moteurs de stockage dont il dispose, ont leurs points forts mais éga-lement leurs points faibles. Si PBXT rime avec SSD (ce moteur inclut des méca-nismes dédiés à ce type de support), InnoDB est très sensible à la présence d’un con-trôleur RAID BBWC (Battery-Back Write Cache)...

La configuration idéale correspondant à tous les besoins n’existe pas ; il est enrevanche nécessaire de choisir son matériel en fonction du but recherché.• Peut-être avez-vous identifié le dual core comme le goulet d’étranglement princi-

pal de votre application ?• Passer à 8 cœurs, est-ce une bonne idée ?• À l’inverse, vous saturez peut-être en I/O disque et la technologie RAID vous

semble intéressante ? RAID 0, 1, 5 ou 10 ?• Quid de la mémoire ?

2Choisir son serveur MySQL



Ce chapitre vous présente les critères que vous devez connaître lors d’une mise à jourmatérielle ou lorsque le choix d’un nouveau serveur MySQL se pose.

La mise à jour matérielle, une étape nécessaire ?Il peut paraître étonnant de se poser la question au début d’un chapitre consacré aumatériel et pourtant...

Avez-vous clairement identifié la mise à jour matérielle prévue, achats de nouveauxserveurs ou mise à jour des machines existantes, comme la solution à vos problèmeséventuels ? S’agit-il d’absorber un pic de charge ou de répondre à un problème récur-rent, comme une saturation des disques ?

Vous êtes peut-être déjà conscient que la configuration actuelle de votre serveurMySQL n’est pas optimale mais vous n’avez tout simplement pas le temps d’auditervos centaines de tables pour optimiser les choses.

Quelles que soient les raisons à l’origine d’une mise à jour matérielle prochaine ou sim-plement envisagée, nous vous conseillons de parcourir les quelques rappels ci-dessousavant de remplir vos bons de commandes. Obtenir une remise sur le prix catalogue estchose courante mais n’est pas une raison suffisante pour foncer tête baissée...

Les questions à se poserInterrogez-vous sur les raisons qui vous font envisager une mise à jour matérielle.

Commençons par les goulets d’étranglements actuels : sont-ils identifiés ? Ce sonteux qui vous guideront vers le type de composants à améliorer ou renouveler (systèmedisques, RAM, processeur, carte contrôleur RAID...).

Par ailleurs, avez-vous effectué ne serait-ce qu’un rapide audit sur les bases concer-nées par cette mise à jour ? Dans ce cadre, des index efficacement posés sur les tablespeuvent générer, dans certains cas, des gains énormes en temps de traitement.

Gagnez du temps en parcourant le slow queries log et analysez dans la foulée les plansd’exécution de vos requêtes les plus coûteuses. Si cela ne suffit pas, prenez le tempsde revoir vos schémas.

ASTUCE Identifier les goulets d’étranglements

Pour identifier les goulets d’étranglement, vous pouvez consulter le chapitre consacré à la surveillance devotre serveur MySQL ainsi que celui traitant des logs MySQL.


Choisir son serveur MySQLCHAPITRE 2

21

Optimisez vos efforts sur les index en identifiant les tables les plus volumineuses etassurez-vous que les champs qui les composent soient correctement ajustés (gain enmémoire vive, en place disque) ; vous faciliterez ainsi le travail du serveur MySQL.Voici deux requêtes qui peuvent vous y aider.

Obtenir la taille en Mo des tables les plus importantes

La commande PROCEDURE ANALYSE fournit des statistiques sur l’utilisation des champs de vos tables

Les tâches programmées constituent une autre source potentielle d’ennuis à analyser.Si des points bloquants apparaissent quotidiennement à horaires fixes, avez-voustenté de résoudre les verrous potentiels en décalant d’éventuels traitementsautomatiques ? Vérifiez si ces tâches ne sont pas en concurrence avec d’autres traite-ments lourds s’exécutant en même temps (enregistrez par exemple le résultat d’unSHOW FULL PROCESSLIST toutes les minutes). Méfiez-vous des sauvegardes et des ver-rous qu’elles posent.

mysql> SELECT table_name, table_schema, SUM(index_length/1024/1024)+ SUM(data_length/1024/1024) as totsize FROM information_schema.tables WHERE table_schema='test' GROUP BY table_schema, table_name ORDER BY totsize DESC LIMIT 10;*************************** 1. rowtable_name: ttable_schema: testtotsize: 325.70312500*************************** 2. rowtable_name: SAVtable_schema: testtotsize: 93.60937500

mysql> SELECT ref_code FROM clients PROCEDURE ANALYSE(10, 2000)\G*************************** 13. row ***************************Field_name: test.clients.ref_codeMin_value: 6175Max_value: 6664Min_length: 4Max_length: 4Empties_or_zeros: 0Nulls: 30Avg_value_or_avg_length: 6442.5226Std: 6075.9587Optimal_fieldtype: SMALLINT(4) UNSIGNED

ASTUCE Optimiser son serveur

Avez-vous lu le chapitre consacré à l’optimisation de la configuration du serveur MySQL ?



Si les précédents conseils sont déjà appliqués, ne capitulez pas pour autant : exa-minez le partitionnement des plus grosses tables et la réplication.

Enfin, si vous n’avez pas suffisamment de ressources en interne pour effectuer ce tra-vail d’audit ou d’optimisation, songez à confier cette tâche à un consultant externequi évaluera la pertinence de la future mise à jour matérielle. Selon l’étendue de votresystème d’information, cet audit peut s’avérer bien meilleur marché que d’importantsachats matériels. De plus, il est probable que ce point de vue extérieur sur votrearchitecture vous procure des conseils ou pistes supplémentaires que vous n’aviez pasforcément envisagés.

Du 64 bits oui... mais partout !Que ce soit pour l’amélioration d’un serveur existant (scaling up) ou l’achat d’unetoute nouvelle machine, surtout prenez garde à respecter une homogénéité en64 bits. Du processeur au système d’exploitation en passant bien sûr par l’utilisationd’une distribution 64 bits, le serveur MySQL ne profitera pleinement des bienfaitsde la technologie 64 bits que si cette chaîne est respectée.

Les processeurs x86 fonctionnent avec 64 bits depuis plusieurs années : le risque estdonc faible du côté des processeurs. Méfiez-vous cependant des systèmes d’exploita-tion, particulièrement si vous ne les installez pas en personne. Certains hébergeursnon spécialisés en solutions MySQL sont susceptibles d’installer un systèmed’exploitation 32 bits classique afin de faciliter, par exemple, l’installation de biblio-thèques ou scripts posant problème sur 64 bits.

JARGON Scaling up, scaling out et scaling back

Scaling up se dit d’une mise à jour matérielle « verticale » : on remplace certains composants d’un ser-veur pour tirer les performances vers le haut. La machine concernée reçoit un meilleur processeur, davan-tage de mémoire, de meilleurs disques...Le terme scaling out s’emploie lorsqu’on augmente les capacités de son système en ajoutant unemachine. C’est le cas d’une architecture de réplication à laquelle on ajoute un serveur esclave identique àceux déjà existants ; la charge est alors répartie sur davantage de machines sans toucher aux spécifica-tions des précédentes.Enfin, scaling back est un terme que l’on rencontre un peu plus rarement mais que nous devrions touspourtant appliquer plus souvent. Il s’agit d’archiver, d’extraire des tables les données devenues inutilespour les opérations courantes. Il peut s’agir soit de purges, on supprime alors certains enregistrementsdevenus inutiles, soit d’un transfert vers une autre table disposant pourquoi pas d’un autre moteur destockage, comme ARCHIVE.Cette bonne pratique permet de ne conserver que les données utiles pour les travaux en cours et contri-bue à conserver des temps de traitements acceptables (ordres DDL et DML plus rapides, sauvegardesmoins pénalisantes, verrous plus courts...).



23

Limites des systèmes 32 bitsInstaller 16 Go sur une machine sur laquelle est installé un OS 32 bits dans l’espoirde soulager votre serveur MySQL est une démarche vouée à l’échec. Le serveurMySQL repose en effet sur un processus (mysqld) dont la limite d’adressagemémoire théorique sur un OS 32 bits est de 4 Go. En réalité cette limite varie entre1,5 Go et 3 Go environ. Le surplus de mémoire disponible ne pourra être utilisé parle processus mysqld.

Sur un système 32 bits, plus encore qu’en 64 bits, il est important de conserver unevaleur raisonnable pour la variable max_connections afin de ne pas autoriser plus deconnexions simultanées que ne peut en gérer votre serveur. En effet, chaque con-nexion au serveur MySQL se traduit par la création d’un thread auquel est associéeune quantité de mémoire.

En cas de réglages un peu trop ambitieux, MySQL, tout particulièrement sousSolaris, se rappellera peut-être à vous un peu brusquement ; Linux est un peu moinsstrict. Sous Solaris, à quantité de mémoire égale et en utilisant le même fichier deconfiguration my.cnf, le serveur MySQL peut refuser de démarrer s’il estime que lesréglages sont trop optimistes en terme de consommation mémoire. Un messaged’erreur plutôt explicite apparaît dans ce cas (ici, un exemple sous Solaris sur unemachine dotée de 32 Go de mémoire) :

Manque de mémoire au démarrage d’un serveur sous Solaris

ATTENTION Ne soyez pas trop gourmands !

N’attribuez pas non plus de valeurs trop importantes aux variables dont la taille mémoire maximale ne seraconsommée qu’en cas de besoin par chaque thread. Par exemple, la variable sort_buffer_size apour valeur 2 Mo par défaut ; si vous la passez à 8 Mo, cela représente 6 Mo potentiels de plus par con-nexion... Avec une valeur de max_connections à 400, par exemple, l’impact d’une telle modificationinduit 2,4 Go de mémoire consommée supplémentaire ! Il faudrait cependant que les 400 connexionssoient actives et effectuent un tri, ce qui réduit l’éventualité d’un tel événement.

090922 12:41:38 InnoDB: Error: cannot allocate 2039978216 bytes ofInnoDB: memory with malloc! Total allocated memoryInnoDB: by InnoDB 17660053448 bytes. Operating system errno: 12InnoDB: Check if you should increase the swap file orInnoDB: ulimits of your operating system.InnoDB: On FreeBSD check you have compiled the OS withInnoDB: a big enough maximum process size.InnoDB: Note that in most 32-bit computers the processInnoDB: memory space is limited to 2 GB or 4 GB.InnoDB: We keep retrying the allocation for 60 seconds...



Le message d’erreur MySQL propose de calculer la somme maximale de mémoireallouée par les threads si tous étaient connectés en même temps en utilisant à la foisdes tris et des recherches séquentielles. Se rajoute à cela le buffer key_buffer_size(espace alloué aux index pour MyISAM uniquement) qui lui est global, donc indé-pendant du nombre de threads connectés.

Concernant key_buffer_size, la documentation stipule justement la différence d’allo-cation possible entre un système 32 bits et un autre en 64 bits, autre preuve de l’intérêtde posséder un système 64 bits permettant de s’affranchir de certaines limites.

En conclusion, si vous disposez d’un matériel 64 bits, veillez à ce que le systèmed’exploitation soit également une version en 64 bits. Cela vous permettra d’allouerplus de 3 Go au processus mysqld et de limiter l’éventualité d’un arrêt de MySQL encas de problème d’adressage.

Relisez le chapitre concernant les outils de surveillance : il fournit une liste d’utili-taires permettant de visualiser rapidement les caractéristiques d’un système.

090922 12:43:51 InnoDB: We now intentionally generate a seg fault so thatInnoDB: on Linux we get a stack trace.090922 12:43:51 - mysqld got signal 11 ;This could be because you hit a bug. It is also possible that this binaryor one of the libraries it was linked against is corrupt, improperly built,or misconfigured. This error can also be caused by malfunctioning hardware.We will try our best to scrape up some info that will hopefully help diagnosethe problem, but since we have already crashed, something is definitely wrongand this may fail.key_buffer_size=4294967296read_buffer_size=2097152max_used_connections=0max_threads=151%)threads_connected=0It is possible that mysqld could use up tokey_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6979054 Kbytes of memoryHope that's ok; if not, decrease some variables in the equation.

RESSOURCES EN LIGNE Davantage de détails sur l’adressage mémoire

Vous trouverez des informations sur l’adressage mémoire dans la documentation elle-même mais égale-ment dans un excellent billet de Mark Robson :B http://dev.mysql.com/doc/refman/5.0/en/memory-use.htmlB http://marksverbiage.blogspot.com/2008/01/mysql-address-space.html



25

Choisir ses processeurs

État des lieuxChez les fondeurs, la multiplication des cœurs (ou cores) au sein des processeurs a levent en poupe. Sans pour autant négliger l’augmentation de la fréquence de leurspuces, les fabricants vantent de plus en plus les mérites de leurs solutions multicœursen soulignant l’éventail des possibilités offertes par la parallélisation.

En réalité, si le système d’exploitation n’est pas adapté, ou bien si l’application elle-même n’a pas été conçue totalement pour ce type d’architecture, la hausse de perfor-mance n’est hélas pas proportionnelle au nombre de cœurs.

MySQL n’échappe pas à ces problèmes de montée en charge. Par le passé plusieursbenchmarks ont prouvé qu’une perte de performance était possible avec 8 cœursplutôt que 4.

S’ils ne sont pas totalement résolus aujourd’hui, ces problèmes tendent cependant às’estomper grâce à la communauté. Celle-ci s’organise et publie des résultats encou-rageants dans plusieurs domaines.

Les solutions face aux problèmes de montée en chargeLa démocratisation des systèmes basés sur des architectures multicœurs et l’utilisa-tion massive d’InnoDB a mis en évidence des problèmes de montée en charge avec cemoteur. Depuis quelques années, blogs, conférences et benchmarks se sont succédéset ont prouvé, graphiques à l’appui, que le passage de 4 à 8 cœurs n’apportait qu’unefaible valeur ajoutée voire des pertes de performance.

JARGON Architecture SMP vs NUMA

Une architecture SMP (Symmetric multiprocessing) désigne un ensemble de processeurs (ou cœurs) quipartagent le même bus mémoire ; c’est le cas de la plupart des systèmes multicœurs aujourd’hui.Les cœurs se partageant le même espace mémoire, la répartition des tâches est censée être facilitée si lesystème d’exploitation est étudié pour. Vous retrouverez le terme SMP dans les correctifs Google pourMySQL, comme dans Patch to improve SMP performance au sein des google-mysql-tools : B http://code.google.com/p/google-mysql-tools/wiki/Mysql5PatchesOn parle d’architecture NUMA (Non-Uniform Memory Access) lorsque chaque cœur/processeur disposede sa propre mémoire en local. Celle-ci sera exploitée plus rapidement qu’une mémoire distante (cas duSMP) ; cependant la répartition de charge entre les processeurs est plus coûteuse.B Plus de détails sur Wikipedia : http://en.wikipedia.org/wiki/Symmetric_multiprocessing



Les coupables ont depuis été identifiés. De multiples mutex (reportez-vous auchapitre 4 « Surveiller son moteur MySQL » pour une définition), ces verrous logi-ciels, zones de contention nécessaires au sein du code pour empêcher plusieursthreads d’accéder simultanément à des structures internes partagées, posent pro-blème. Ces mutex sont présents sur le adaptive hash index ou encore sur le transactionlog... InnoDB souffre d’un problème qui remonte au temps où les serveurs étaientmono-processeur et dotés d’un seul disque. La situation est évidemment bien diffé-rente aujourd’hui : 4, 8, 16 ou 32 cœurs rattachés à plusieurs dizaines de disques nesont plus des cas isolés, sans parler de la quantité de mémoire disponible de nos jourssur un serveur MySQL : 8 Go, 16 Go, 32 Go, sont des valeurs courantes.

Depuis 2007 environ, la communauté a accéléré la cadence et s’est attaquée à ces pro-blèmes. Google, qui utilise massivement MySQL, a tiré la première avec mysql-tools ;le correctif v1 fut d’ailleurs publié à cette période. Les correctifs de Google ne concer-nent pas uniquement les problèmes de montée en charge sur les systèmes multicœursmais enrichissent également d’autres fonctionnalités de MySQL, telle la réplication.

Aujourd’hui, Google continue à publier des correctifs. Le dernier, le v3, date de mi-2009. D’autres acteurs majeurs de la scène MySQL se sont joints à ces efforts afin derendre MySQL toujours plus rapide. Il est intéressant de noter que malgré la compé-tition sous-jacente entre ces acteurs (Percona, ProvenScaling, MySQL, InnoDB...),les efforts ne sont pas cloisonnés et la communication entre ces groupes existe.

On retrouve ainsi certaines innovations de Percona dans le dernier plug-ind’InnoDB. De son côté, Google s’inspire également des meilleures pratiques dispo-nibles qu’elles soient issues de recherches internes ou externes à partir d’idées de Per-cona ou ProvenScaling, par exemple.

REMARQUE La compétition omniprésente entre les différents acteurs

Les équipes dédiées à la performance chez MySQL ont elles aussi effectué un gros travail. La publicationde la version 5.4 lors de la dernière conférence annuelle MySQL à Santa Clara mi-avril 2009, au momentmême du rachat de Sun par Oracle, en est la preuve. Cette version, toujours en bêta à l’heure où nousécrivons ces lignes, est résolument tournée vers les performances, la montée en charge et une meilleureexploitation des systèmes multicœurs.Dans le même temps Percona publiait XtraDB un moteur dérivé d’InnoDB avec des patches propriétairesdestinés comme toujours à améliorer les performances.Les fruits de ces efforts, disponibles gratuitement pour qui installe ces versions améliorées, contribuent àaugmenter la visibilité de leurs auteurs et ont donc une influence indirecte sur leur chiffre d’affaires. Per-cona renforce ainsi son rayonnement en tant qu’expert et consultant MySQL grâce à leur fameux blog oupar le biais de leurs patches. Mais MySQL n’est pas en reste non plus puisqu’eux-mêmes proposent diffé-rentes formes de consulting.B http://www.mysqlperformanceblog.com



27

Enfin, des sociétés telles que Yahoo!, Craigslist, Facebook, Google... font parlerd’elles et de leur maîtrise des dernières avancées technologiques en publiant amélio-rations et patches ou en permettant à leurs experts internes de donner des confé-rences sur des sujets pointus.

Choisir son processeur : les critères de choix

Quelle est l’utilisation actuelle de vos processeurs ?Le premier réflexe est d’identifier vos goulets d’étranglement (consultez le chapitre 4« Surveiller son serveur MySQL » à ce sujet) afin de déterminer dans quelle mesureune mise à jour de vos processeurs peut vous aider. Si ces derniers sont inactifs la plu-part du temps, rajouter un quadricœur à votre système ne servira pas à grand-chose...

Cependant, si vous avez la chance de disposer de l’intégralité de vos données enmémoire, votre système est alors plus susceptible de connaître un goulet d’étrangle-ment dû au processeur (CPU bond). Il en va de même si ce sont vos disques qui four-nissent au processeur les données dont il a besoin suffisamment rapidement ; cepourrait être le cas d’un parcours séquentiel total (full scan) où chaque enregistrementserait l’objet d’un traitement mathématique ou statistique important.

Utilisez les utilitaires top et htop afin de détecter la façon dont se comportent lescœurs du processeur. Une charge bien répartie entre les différents cœurs est un bonsigne ; si au contraire vous observez constamment une utilisation maximale de 50 %sur un bicœur ou 25 % sur un quadricœur, il est fort probable que vous n’utilisiez

À lire également

Retrouvez davantage d’informations à ce sujet dans le chapitre 8 « Où trouver de l’aide ? »

À SAVOIR MySQL et la gestion des threads

Pour MySQL une requête provient d’un thread et est attribuée à un cœur. Deux cœurs ou plus ne peuventpas mettre en commun leur puissance respective pour résoudre une requête issue d’un seul thread. Enrevanche, sur un quadricœur, par exemple, un traitement qui ne nécessite pas de sérialisation particulièreet dont les actions concernent différentes tables si vous utilisez MyISAM, peut être découpé en quatre, etlancé en autant d’instances différentes. Cette astuce est envisageable pour optimiser l’utilisation de pro-cesseurs multicœurs. Attention aux points de contention potentiels avec MyISAM : verrouillage totald’une table si un UPDATE est effectué, contention sur le key_buffer_size global à toutes lestables (en revanche pas de problème sur un parcours séquentiel total). De manière générale, préférezInnoDB et son design tourné vers la concurrence (verrouillage par ligne notamment) plutôt que MyISAMsi vous traitez des requêtes mixtes de lecture et d’écriture.



qu’un cœur sur les deux ou quatre dont vous disposez ! Si cette sous-exploitation dumatériel pose un problème de performance, plutôt que d’acheter de nouveaux cœurs,tentez plutôt de diviser le traitement en deux ou quatre instances afin de maximiserl’utilisation des processeurs dont vous disposez.

Lorsqu’un tel découpage de votre programme ou script n’est pas possible ou bienqu’il ne porte pas ses fruits du fait des problèmes évoqués ci-dessus, il est probable-ment plus judicieux d’échanger un quadricœur utilisé à 25 % (puisque seul un cœurest utilisé dans cet exemple) contre un bicœur plus rapide même si celui-ci sera éga-lement sous-exploité (50 % d’utilisation).

Fréquence vs nombre de cœursSelon le type d’activité (OLTP, OLAP...) soumise à MySQL, les besoins du serveursont différents.

Les serveurs OLTP reçoivent en général une multitude de petites requêtes qui peu-vent être jouées chacune sur un cœur différent, d’où l’intérêt de posséder de nom-

Figure 2–1L’un des deux cœurs n’a pas d’activité

Figure 2–2Une répartition plutôt homogène sur ces huit cœurs

JARGON OLTP, OLAP : deux catégories de systèmes à gérer différemment

Un système OLTP (Online Transaction Processing) est caractéristique d’un site Internet. Une base de don-nées transactionnelle est soumise à un grand nombre d’utilisateurs concurrents. Les requêtes sont nom-breuses et normalement très courtes. Elles mettent à jour la base continuellement.À l’inverse, un système OLAP (Online Analytic Processing), typique d’un data warehouse par exemple,repose sur un nombre d’utilisateurs beaucoup plus restreint mais dont les requêtes soumises à une basedécisionnelle sont beaucoup plus lourdes. Ce type de base contient en général beaucoup moins de tablesqu’une base transactionnelle mais elles sont volumineuses. Les mises à jour sont moins fréquentes quedans un environnement OLTP.



29

breux cœurs. En revanche, au sein d’un environnement OLAP, les requêtes sontmoins nombreuses mais plus lourdes en termes de coût processeur (davantage de cal-culs mathématiques qu’une requête Internet classique) et le temps d’exécution estdonc fortement corrélé à la fréquence du processeur. La cadence du processeur prendalors plus de poids que son nombre de cœurs.

En conséquence, privilégiez une fréquence élevée pour :• La réplication. Celle-ci est pour le moment toujours monothread.• Les applications OLAP lourdes en calculs mathématiques.

Préférez la technologie multicœur pour :• Les environnements à haute concurrence (OLTP).• Les traitements susceptibles d’être découpés et dont les requêtes ne sont pas en

concurrence les unes avec les autres. InnoDB est donc ici un allié de choix, mêmesi des problèmes de verrous ne sont pas exclus.

Le meilleur des deux mondes serait actuellement :• Deux bicœurs à fréquence élevée sont plus polyvalents qu’un quadricœur à fré-

quence plus modeste.• Dans le cadre de la réplication, le maître peut tourner sur un quadricœur et

l’esclave sur un deux bicœurs. N’oubliez pas que l’esclave, en plus de répliquer(assimiler les mêmes écritures que le master), doit également gérer les requêtes enlecture qui lui sont soumises ; il doit donc au moins être aussi puissant que le mas-ter, le tout avec le handicap de répliquer les écritures à partir d’un seul thread.

Benchmarks, encore et toujoursIl est difficile de prévoir les réactions d’un système lors d’une mise à jour comme lepassage de 4 à 8 cœurs. Des benchmarks sont dans ce cas fortement conseillés. Demême, ne prenez pas pour argent comptant ce que vous lisez sur différents blogs spé-cialisés... à moins d’avoir vraiment mesuré le pour et le contre, fait le tour de la ques-tion et observé un certain consensus parmi les commentaires de l’article en question.

Prenons le cas controversé de la variable innodb_thread_concurrency. Certains arti-cles conseillent de la passer à 0 et d’autres de conserver la valeur par défaut... Qui araison, qui a tort ? Réponse : les deux ou personne, selon le contexte ! Désactiver

À LIRE ÉGALEMENT Mesurer les performances de son système

Les benchmarks sont étudiés dans le chapitre dédié à la surveillance d’un serveur MySQL. Considéréscomme un luxe ils sont assez chronophages. Ils sont cependant inévitables si l’on souhaite vraimentmesurer la réaction d’un système face à une forte charge.



cette limitation peut aussi bien déboucher sur de grandes améliorations tout commeprovoquer l’inverse de l’effet recherché. Tout dépend de votre architecture et du typed’activité soumis à MySQL.

Il existe bien une formule couramment reprise pour le calcul de cette variable :

innodb_thread_concurrency = nombre de cœurs * nombre de disques * 2

Mais celle-ci est à considérer avec précaution. Sa valeur par défaut a d’ailleurs variéentre différentes versions de MySQL, passant de 500 (signifiant pas de limite àl’époque) à 0, puis à 8... Si vous voulez mesurer l’impact de cette variable, com-mencez par exécuter plusieurs benchmarks en conservant votre valeur actuelle, notezles temps de réponse puis passez par exemple à 0 (signifiant pas de limite sur les ver-sions actuelles) et observez les changements.

Il convient donc, quel que soit le conseil reçu, de tester si possible sur ses propres sys-tèmes les améliorations proposées. Sachez à ce titre que les grands constructeurs per-mettent souvent, si vous avez réellement l’intention d’acquérir du matériel, de testerleurs systèmes dans votre centre de traitement. Vous aurez alors tout loisir de faire subirau matériel prêté les benchmarks qui vous correspondent avant de signer le chèque.

Ainsi, si vous venez d’acquérir un système multicœur susceptible de poser des pro-blèmes de concurrence à InnoDB (disons à partir de huit cœurs), commencez si pos-sible par tester différentes versions de MySQL afin de déterminer laquelle est sus-ceptible de lever d’éventuels problèmes de mutex. Par exemple, activez tout d’abordle plug-in InnoDB contenu à partir de la version 5.1.38 de MySQL ou ajoutez-le surune version plus ancienne. Testez éventuellement la version 5.4 (encore en bêta àl’heure actuelle) et le moteur XtraDB de Percona.

Outre les moteurs de stockage (InnoDB/XtraDB) et les versions de MySQL, la ges-tion des threads par le système d’exploitation a également son rôle à jouer, les proces-seurs multicœurs étant plus ou moins bien exploités. Solaris a une très bonne réputa-tion dans ce domaine (kernel threads) tandis que sous Linux l’implémentation NPTL(Native POSIX Thread Library) a supplanté l’ancienne librairie nomméeLinuxThreads et offre désormais de bien meilleures performances dans la création etdestruction des threads que par le passé.

RAPPEL Configurer son serveur MySQL

Pour en savoir plus sur ce type de variables, rendez-vous au chapitre 6 « Optimiser son serveur MySQL ».



31

En conclusion de cette section sur les processeurs, retenez les points suivants :• MySQL apprécie en général les processeurs rapides, plus encore qu’un nombre

élevé de cœurs.• Des points de contention existent au niveau du serveur MySQL lui-même (répli-

cation mono-thread...), du système d’exploitation (gestion des threads), mais éga-lement au sein des moteurs de stockage, tout cela expliquant que les performancesne progressent pas au rythme de l’ajout de nouveaux cœurs.

• La gestion des systèmes multicœurs est en constante amélioration grâce aux avan-cées logicielles du serveur MySQL lui-même et des moteurs de stockage, commeInnoDB (le plus utilisé dans un environnement à haute concurrence) mais égale-ment PBXT, qui semble bien parti.

• Il n’existe pas de processeur idéal pour tous les besoins : un site Internet (OLTP)et un data warehouse (OLAP) ne sont pas soumis aux mêmes charges de travail.

• Il est parfois très difficile de prédire précisément les améliorations potentiellesapportées par l’ajout de plusieurs cœurs à un système existant ; des benchmarkssont nécessaires (ajustements du my.cnf, comparaisons entre moteurs et versionsde MySQL). Modifiez un seul paramètre et testez.

Choisir ses disques et son système RAIDClassiques goulets d’étranglement, les disques sont bien souvent le talon d’Achille deMySQL.

Indispensables actuellement, les disques subissent la concurrence des puces mémoire,que celles-ci soient constituées de cellules volatiles (mémoire vive) ou persistantes(Flash/SSD). Il est en effet primordial de faire son possible pour en réduire l’utilisa-tion. À ce sujet, consultez le chapitre consacré à la configuration du serveur MySQLafin de définir au mieux la taille des caches les plus importants pour MySQL selon lecontexte : key_buffer_size, innodb_buffer_pool_size, cache de requêtes...

ASTUCE Pour aller plus loin

Voici deux liens susceptibles de vous intéresser, l’actualité du moteur de stockage InnoDB et un blog con-sacré à des benchmarks :B http://blogs.innodb.com/B http://dimitrik.free.fr/blog/Retrouvez également d’autres liens d’intérêt dans les ressources disponibles en ligne de cet ouvrage :B http://www.editions-eyrolles.com



Ceci étant dit, et puisqu’il est indispensable de sauvegarder à un moment ou à unautre les mises à jour de la base (logs binaires, logs des transactions, données elles-mêmes...), analysons les problématiques que posent les disques actuels et étudionscomment on peut tenter d’obtenir les meilleures performances possibles grâce à uneconfiguration matérielle adaptée.

Temps d’accès versus taux de transfertTemps d’accès, taux de transfert, rotations par minute... Quels critères retenir enpriorité pour un disque destiné à MySQL ?

Pour bien comprendre les enjeux, résumons le mécanisme d’une lecture sur disquepar cette simple formule :

Le temps d’accès (seek time) est le temps que met la tête de lecture à se placer sur labonne piste de l’un des plateaux du disque. Une fois en place, il faut encore attendreque la donnée recherchée sur cette piste passe sous la tête de lecture. Avec de lachance, la tête peut tomber exactement dessus, sinon il faut patienter un tour com-plet... Ce temps d’attente est également appelé rotational latency. Enfin, une fois latête de lecture positionnée sur le bloc secteur recherché, il faut attendre que les don-nées soient lues au rythme de la rotation du disque puis transférées au système.

En termes de temps, le placement de la tête de lecture au bon endroit sur le disqueinfluence lourdement le temps global nécessaire pour une lecture. En conséquence,n’hésitez pas à dépenser un peu plus pour les disques dont les temps d’accès sont lesplus faibles : le retour sur investissement est garanti. Les meilleurs temps d’accès sesituent actuellement autour de 4 millisecondes. Pour vous en persuader pourquoi nepas suivre les procédures de test étudiées au chapitre 4 « Surveiller son serveurMySQL » et les appliquer à deux catégories de disques aux temps d’accès différents ?

À SAVOIR Temps d’accès mémoire vs temps d’accès disques

Cet article (http://www.dbnewz.com/2008/11/20/), tiré de l’un de nos blogs, relate l’importance de lamise en cache lorsqu’elle concerne un parcours basé sur des lectures aléatoires. Entre un parcoursséquentiel sur disque (full scan table) et le même parcours en mémoire, il existe un facteur 10, à compa-rer avec un facteur 2 500 (!) pour une lecture aléatoire entre son temps de parcours en mémoire et celuicorrespondant sur disque. Ces chiffres sont à mettre au crédit de Percona (MySQL High Performance 2ndEdition). Les lectures aléatoires (random read) sont les plus coûteuses et donc les plus intéressantes àmettre en cache.

lecture sur disque = temps d'accès + taux de transfert



33

Dans le cadre de l’activité d’un site Internet (forte concurrence, traitements « légers »),la base est soumise à une multitude de requêtes différentes, de lectures et de mises àjour. La majorité d’entre elles appartiennent à la catégorie des lectures aléatoires, lestêtes de lecture pointant là où sont stockées les données. Celles-ci pouvant être posi-tionnées n’importe où sur le disque, le terme aléatoire n’est encore une fois pas usurpé.

En conséquence, pour un environnement OLTP, le temps d’accès d’un disque dur estle critère de choix à placer en première position. En regard de l’influence du déplace-ment de la tête de lecture vers la position à lire ou écrire, le taux de transfert passe eneffet en seconde position. Cela est d’autant plus vrai que la quantité de données àrapatrier, dans le cadre d’une requête Internet typique, sera faible.

En revanche, au sein d’un environnement OLAP, où les quantités de données à rapa-trier sont beaucoup plus importantes, les index moins nombreux et les lecturesséquentielles plus présentes, le taux de transfert reprend de l’importance.

Figure 2–3Les principaux éléments constituant un disque dur

À RETENIR Lecture/écriture aléatoire ou séquentielle

On parle de lectures ou écritures aléatoires (mais le terme anglais est bien plus utilisé : random read/write) lorsque celles-ci se succèdent à des endroits différents du disque, d’où le terme aléatoire. A con-trario, on parle de lectures/écritures séquentielles lorsqu’elles sont effectuées les unes à la suite desautres sur le disque.Nous venons d’évoquer le coût en termes de temps nécessaire à une tête de lecture pour se positionnerau bon endroit du disque. Par définition, les lectures ou écritures dites aléatoires sont donc beaucoupplus coûteuses que leurs homologues séquentielles, qui elles ne nécessitent pas de rechercher à nouveaula bonne position où lire/écrire.Les lectures aléatoires sont particulièrement coûteuses pour un disque dur classique du fait des multiplespositionnements successifs de la tête de lecture. Les SSD (Solid-State Drive), puces mémoire persistantes,abordées plus tard dans ce chapitre, offrent en revanche de bien meilleures performances pour ce type delecture du fait de l’absence de déplacement de pièces mécaniques.



Enfin, la vitesse de rotation des disques n’est pas la donnée principale à retenir pourle choix d’un disque. Cela dit, la vitesse de rotation contribue à la fois au tempsd’accès (souvenez-vous du temps de latence liée à la rotation du plateau une fois lapiste déterminée mais pas encore le bloc secteur) et au temps de transfert, puisqu’elleinfluence la vitesse à laquelle seront lues les informations par la tête de lecture.

La technologie RAIDL’acronyme RAID Redundant Array of Inexpensive Disks, se définit également parfoispar Redundant Array of Independent Disks du fait de la notion toute relative du carac-tère Inexpensive, c’est-à-dire bon marché, de ces disques.

Cette technologie recense en fait plusieurs configurations possible et désigne selon leniveau de RAID choisi un système capable d’apporter, par exemple, une meilleuretolérance aux défaillances matérielles, grâce notamment à la redondance des disquesou au contrôle de parité, mais également susceptible de supplanter un disque clas-sique face à une montée en charge constituée de lectures ou d’écritures.

Ainsi, l’une des promesses du RAID est de paralléliser les écritures.

Quelle configuration RAID est susceptible de correspondre à votre activité ? Sansentrer dans le niveau de détails d’un ouvrage dédié à cette technologie, voici les prin-cipaux niveaux de RAID et nos recommandations vis-à-vis de MySQL.

Les principaux niveaux de RAIDLe schéma suivant détaille les niveaux et les architectures RAID les plus souvent ren-contrés dans un environnement lié aux bases de données.

RAID 0 (ou volume agrégé par bande/stripping )

Chaque disque de l’ensemble ne stocke qu’une partie des données. Celles-ci sontdivisées en blocs et dispersées sur l’ensemble des disques. Les requêtes de typerandom read apprécient la parallélisation offerte par le RAID 0 : plusieurs disquespeuvent en effet contribuer simultanément à retrouver les données recherchées.

ATTENTION La réplication et la montée en charge des écritures

Concernant la montée en charge des lectures, une des techniques les plus répandues avec MySQL con-siste à utiliser la réplication afin de décharger le maître des lectures et de reporter cette tâche sur un ouplusieurs esclaves. La tâche est plus difficile dès lors qu’il s’agit d’absorber davantage d’écritures. Dansce cadre, par exemple, la réplication maître-maître est un faux ami puisque chacun des maîtres doitreporter sur lui-même les mises à jour reçues par l’autre.



35

Le gros inconvénient de ce niveau de RAID concerne la fiabilité de l’ensemble. Si un seuldes disques tombe en panne (ce qui statistiquement est plus probable avec plusieurs dis-ques qu’avec un seul), toutes les données sont perdues ; il n’y a pas de redondance.

En conséquence, ce niveau de RAID est à réserver aux environnements de tests oususceptibles d’être remontés rapidement par d’autres moyens.

Le RAID 0 est la moins chère des implémentations de type RAID et la plus efficace,si on rapporte les performances au nombre de disques impliqués, mais également laplus dangereuse.

Figure 2–4Synthèse des niveaux de RAID abordés



RAID 1 (ou mirroring)

Chaque écriture appliquée à un disque particulier est automatiquement reportée surles autres disques de l’ensemble. Toutes les données sont dupliquées sur tous les dis-ques. Cette redondance s’obtient au prix d’une pénalité au niveau des écritures parrapport au RAID 0. Contrairement aux écritures qui sont appliquées sur tous les dis-ques, les lectures sont parallélisables. Cette configuration est particulièrement effi-cace en cas de parcours séquentiel total d’une table (full table scan) puisque toutes lesdonnées se trouveront sur un même disque.

L’inconvénient de ce niveau de RAID est le surcoût en disques.

RAID 5 (ou volume agrégé par bande à parité répartie)

Très répandu, le RAID 5 permet d’accéder à une certaine redondance en conservantde bonnes performances. Ce niveau de RAID est semblable au RAID 0 à premièrevue : les données à écrire sont réparties sur différents disques. La différence réside enfait dans l’apparition sur chaque bande d’un disque dédié à la parité. Ce bloc deparité est stocké circulairement sur les différents disques.

Les écritures s’effectuent au prix d’un léger surcoût : en effet, en plus du bloc à écrire,les blocs des autres disques de la même bande doivent être lus afin de calculer laparité. Dans le cas où plusieurs processus mettent à jour la même bande de données(c’est le pire cas), ils devront attendre que le verrou posé sur le bloc de parité lors deson écriture soit levé.

La technologie RAID 5 est redondante à condition de ne perdre qu’un seul disque àla fois. Lorsqu’un disque de remplacement (spare) est présent, il sera automatique-ment reconstruit à partir des autres blocs. Pendant la durée de reconstruction,comptez deux heures pour 300 Go environ, les performances de l’ensemble seront

REMARQUE Les opposants au RAID 5

Toute technologie a ses détracteurs... le RAID 5 ne fait pas exception. Rassemblés sous le terme BAARF(Battle Against Any Raid Five), ces opposants au RAID 5 publient sur ce site leurs critiques relatives à ceniveau de RAID. Retour d’expérience, comparaisons avec d’autres niveaux de RAID, les débats sont tech-niques et soulignent notamment les performances en écriture jusqu’à 50 % moins élevées que sur duRAID 0 ainsi que les risques de propagation d’erreurs entre différents disques en cas de lecture d’un dis-que défectueux mais pas (encore) détecté comme tel.B http://www.miracleas.com/BAARF/Attention tout de même : ces diverses discussions ne sont pas toutes datées et sont à relativiser auregard des améliorations régulièrement apportées aux drivers des cartes contrôleur notamment. LeRAID 5 étant une des implémentations de RAID les plus répandues, les efforts des constructeurs permet-tent parfois de nuancer certains défauts attribués à ce niveau de RAID. À lire néanmoins.



37

dégradées. Plus la taille des disques à restaurer est grande, plus le risque de perdre unautre disque pendant la reconstruction est fort. Partant du principe que les disquesd’un ensemble RAID sont souvent de la même génération et du même type, ils sontsusceptibles de connaître des défaillances similaires dans des périodes rapprochées.

RAID 10 (1+0)

Comme son nom l’indique, le RAID 10 combine les bienfaits du RAID 0 (réparti-tion des données sur plusieurs disques) tout en annulant sa faiblesse : le manque deredondance. Avec du RAID 10, les blocs de données sont en effet également dupli-qués (mirroring). Le RAID 10 est très performant mais également coûteux puisquela moitié des disques sert de sauvegarde contre un tiers seulement pour du RAID 5.

Les avantages du RAID 10 sont des lectures et écritures performantes, une recons-truction d’un disque moins pénalisante que sur du RAID 5 (ici seule la grappe con-cernée est impactée), et une fiabilité accrue (pas de perte de données tant que tous lesdisques d’une grappe ne sont pas défaillants).

Si votre budget est limité et que votre système opère peu d’écritures, le RAID 5 estsuffisant ; sinon préférez toujours du RAID 10.

En quelques mots, voici les mots-clés à retenir propres à chaque niveau de RAIDque nous avons abordé :

Tableau 2–1 Caractéristiques principales des différents niveaux de RAID

Niveau de RAID

Caractéristiques

0 Avantages : coût, performances en lecture/écriture.Inconvénients : pas de redondance, à réserver aux environnements non critiques ou rempla-çables rapidement.

1 Avantages : simple, fiable, performances en lecture.Inconvénients : pas de gain sur les écritures, coût rapporté à la taille disque disponible.

5 Avantages : meilleur rapport prix/espace disque disponible, performances en lecture.Inconvénients : ne supporte la perte que d’un seul disque, intégrité des disques à surveiller.

10 Avantages : performances en lecture/écriture, fiabilité.Inconvénients : coût.

RESSOURCES EN LIGNE D’autres niveaux de RAID existent

Retrouvez en ligne de la documentation concernant le RAID ; la page de Wikipedia consacrée à cettetechnologie est un bon point de départ. Vous y découvrirez notamment d’autres niveaux de RAID.B http://fr.wikipedia.org/wiki/RAID_(informatique)



Les deux implémentations du RAID : logicielle et matérielleLa technologie RAID existe sous forme matérielle par le biais d’une carte contrôleur,ou sous forme logicielle, le système d’exploitation se chargeant de gérer les disquesselon le niveau de RAID choisi (s’il est disponible).

Les deux méthodes possèdent leurs avantages et inconvénients. Comme souvent il ya de nombreux débats et pas de réponse unique.

Le RAID logiciel est évidemment moins cher. De plus, s’il émane d’un systèmed’exploitation Open Source, on peut compter sur le fait que la communauté puissedétecter puis corriger un bug plus rapidement que sous une solution propriétaire.Désavantage, l’implémentation RAID logicielle ajoute une surcouche logique à votreapplication. À noter que le serveur MySQL lui-même proposait dans sa version 4 unattribut RAID_TYPE à ajouter dans la syntaxe d’un CREATE TABLE pour une tableMyISAM, option abandonnée depuis la version 5.

En ce qui concerne la configuration d’une telle solution RAID logicielle, toutdépend de l’expérience de vos équipes ; les versions matérielles du RAID ont la répu-tation d’être plus simples à gérer... à condition que les drivers des cartes contrôleursRAID ne soient pas récalcitrants, ce qui peut constituer une faiblesse pour ces solu-tions propriétaires, chaque fournisseur (Adaptec, Dell, HP...) disposant en effet deson propre applicatif pour gérer son contrôleur. Cette dépendance semble ne pasplaire à Google, par exemple : ils utilisent principalement du RAID logiciel afin dene pas être dépendants des fabricants de matériel.

Le RAID matériel est plus onéreux mais décharge le système d’exploitation de lagestion des disques. Les cartes contrôleurs RAID les plus intéressantes pour les basessont celles qui proposent une certaine quantité de cache (512 Mo de RAM parexemple) afin d’offrir performance et fiabilité. Ce dernier avantage ne concerne queles modèles dits BBWC, Battery-Back Write Cache. En cas de coupure de courant, le

REMARQUE Carte contrôleur RAID, force et faiblesse à la fois

Les configurations basées sur une implémentation RAID possèdent une carte contrôleur permettant degérer les disques et leur éventuelle redondance. Outre les caractéristiques déjà évoquées pour de tels sys-tèmes, il faut également souligner que cette carte peut également constituer une faiblesse et devenir àson tour, tout comme un disque, un élément critique de défaillance. SPOF (Single Point Of Failure) est lenom donné à ce type d’élément critique dans la langue de Shakespeare. En effet, si la carte elle-mêmen’est pas redondante, en cas de problème matériel, les disques ne sont plus accessibles.Selon les constructeurs et les modèles, il est possible de faire fonctionner deux cartes de concert ou endéfinir une comme le secours de l’autre. N’oublions pas les TBBU (Transportable Battery Backup Unit) :celles-ci permettent d’extraire littéralement le cache et sa batterie d’une carte contrôleur défectueuse(grillée lors d’une surtension électrique, par exemple) et de les réinstaller sur une nouvelle carte.



39

cache (volatil par défaut) est alors conservé grâce à la batterie pendant quelques jours(72 h est une valeur courante). Attention, une application utilisant le cache d’unecarte contrôleur RAID non secondée par une batterie s’expose à des pertes de don-nées en cas de coupure de courant.

Si vous en avez les moyens, nous vous conseillons une implémentation matériellebasée sur une carte contrôleur RAID disposant de cache et de type BBWC.

Intérêt du cache sur une carte contrôleur RAIDPour un serveur basé sur une solution RAID matérielle, la carte contrôleur est unpoint de passage obligé pour les données lors de leur transit entre les disques et lesystème d’exploitation sur lequel repose MySQL.

À chaque étape traversée (MySQL, OS, carte contrôleur, disques) les données sonten effet susceptibles d’être stockées dans un cache.

Il est possible de configurer le cache de la carte contrôleur afin qu’il soit utilisé en lec-ture, en écriture ou bien les deux à la fois. Ce sont surtout les deux modes les plusrépandus.

En mode lecture, on cherche à lire un enregistrement à partir de la base de données.

Configurer le cache de la carte contrôleur en lecture revient à dire qu’on estime que laquantité de cache disponible va permettre d’y retrouver une donnée, ce qui éviteraitd’aller interroger les disques. En regard de la quantité de mémoire disponible sur cetype de carte, c’est en général une mauvaise utilisation du cache. En effet, la quantitéde mémoire disponible par ailleurs est beaucoup plus importante et plus à même decontenir la donnée recherchée que ce petit tampon.

Figure 2–5Les différents trajets du buffer pool vers le disque et inversement



Il en va de même pour les lectures dites read-ahead. Il s’agit ici de données stockéesen avance car elles correspondent, selon l’algorithme du driver de la carte contrôleur,à des enregistrements susceptibles d’être lus prochainement. Là encore, la taille ducache est trop faible pour espérer un taux de succès (hit) suffisant dans cette configu-ration, alors que InnoDB effectue déjà par ailleurs ce type de prédictions.

En mode écriture, on souhaite stocker un enregistrement dans la base de données.

Pour un serveur MySQL, une carte contrôleur RAID a beaucoup plus d’intérêt dansun contexte d’écritures ; nous allons voir pourquoi. Le cache de la carte contrôleurpeut être défini en write-through ou en write-back.

En mode write-through, les données provenant de la base traversent la carte sans yêtre stockées et ont pour destination les disques. Ce sont eux qui renverront unacquittement à la fonction système (fsync() par exemple) qui a initié l’écriture, unefois les données durablement stockées.

Face à la même demande d’écriture sur disque que précédemment (appelée flush), lemode write-back autorise la carte contrôleur à court-circuiter les disques, stocker lesdonnées dans le cache et répondre positivement au système d’exploitation qui peutalors initier une autre demande normalement bloquante (synchronous write) plus rapi-dement. Selon la configuration de la carte contrôleur, le cache sera ensuite plus oumoins rapidement envoyé vers les disques afin d’y être stocké durablement. Cet envoigroupé permet de réduire le nombre d’écritures nécessaires.

Ce type d’optimisation est particulièrement utile pour InnoDB lors de l’écriture surdisque du log_buffer. Rappelons que la fréquence de cette écriture dépend de lavaleur de la variable système innodb_flush_log_at_trx_commit. Lorsque celle-ciprend la valeur 1, la plus sûre, le log_buffer est écrit sur disque à chaque COMMITainsi qu’à chaque checkpoint (environ 1 fois par seconde pour InnoDB).

Ce réglage, conseillé, a néanmoins un fort impact sur les performances. Il en va demême pour la variable sync_binlog lorsqu’elle prend la valeur 1. Dans ce cas, MySQLveille à ce que soit écrit sur disque le log binaire modifié par la dernière transaction.

Ces deux activités bénéficient très largement de la présence d’un cache sur la cartecontrôleur.

RAPPEL Le cache de requêtes en amont de la carte RAID

Souvenez-vous qu’avant même d’interroger éventuellement le cache de la carte contrôleur (si celui-ci est définien cache lecture), le serveur MySQL vérifiera d’abord si la requête et son résultat associé ne sont pas déjà dansle query cache (en général de taille inférieure à celle du cache de la carte contrôleur), dans le buffer_poold’InnoDB (qui se compte en Go), mais également dans le key_buffer_size de MyISAM, si la donnéerecherchée est contenue dans un index (covering index, par exemple). En conclusion, il y a peu dechance que le cache d’une carte contrôleur RAID configuré en lecture soit utile dans ce contexte.



41

Figure 2–6Parcours d’une transaction au sein d’InnoDB, en mémoire puis sur disque

BON À SAVOIR Les outils pour vérifier les réglages de sa carte contrôleur

À chaque fabricant son outil ; voici une liste susceptible de vous aider à gérer la configuration de votrecarte contrôleur :• mptutil - HP - http://docs.hp.com/en/J6373-90030/ch05s07.html• lsiutil - SAS - http://docs.sun.com/source/820-1705-13/appa-lsiutil.html• mpt-status - http://freshmeat.net/projects/mptstatus/• mfiutil - Dell• megacli - Dell• megarc - Dell• hpacucli - HP• cissutil - HP• tw_cli - 3ware• openmanage – Dell



Indispensable batterieSi vous décidez d’utiliser le cache de la carte contrôleur RAID en mode write-back,celui-ci doit absolument être secondé par une batterie. Les modes lecture ou write-through n’en ont pas besoin.

Le problème est bien sûr relatif à l’alimentation électrique. En cas de problème de cetype, toutes les données stockées dans le cache et donc considérées par le systèmed’exploitation et MySQL comme stockées durablement ne le sont pas encore réelle-ment. Une batterie permet donc de différer cette écriture au moment où les disquesseront alimentés de nouveau. Cette écriture se produit soit avant que les disques nesoient à nouveau considérés comme disponibles, soit immédiatement si les disquessont reliés à un onduleur.

Les systèmes RAID dotés d’un cache en écriture secondé par une batterie sont ditBBWC. On dit également qu’ils disposent d’une BBU, Battery Backed Unit.

Le cache interne des disques : une arme à double tranchantNe pas disposer d’une carte contrôleur BBWC est une chose, mais il y a pire encore :subir des pertes de données dues à un cache disque non maîtrisé.

Reprenons l’exemple de la mise à jour d’un enregistrement présent en mémoire, dansle buffer pool d’InnoDB. Une fois la trace de la transaction enregistrée dans lelog_buffer (toujours en mémoire), celui-ci trouve sa place dans un fichier de logdédié aux transactions, sur disque. Le but est ensuite bien sûr de traduire cette tran-saction en impact réel dans les données.

Si le disque contenant les logs de transaction n’est pas dédié à cette activité, plusieurslectures ou écritures s’effectueront entre deux écritures de logs ce qui empêche les écri-tures de se dérouler de façon séquentielle. En effet, la tête de lecture n’aura pas conservéla position de la précédente écriture. À la clé, de coûteux déplacements de la tête de lec-ture lors de chaque COMMIT (avec innodb_flush_trx_commit = 1). Le principe est lemême avec les logs binaires et le réglage sync_binlog = 1.

Le cache au niveau de la carte contrôleur en mode write-back est alors tout indiquépour éviter de transformer chaque COMMIT en coûteuse écritures aléatoires.

EN PRATIQUE Durée de vie de la batterie d’une carte RAID

Certaines batteries ont la capacité de durer 72 h, ce qui permet de survivre à une coupure électrique letemps d’un week-end. Cela peut s’avérer très utile si jamais la machine concernée n’est pas surveillée24 h/24 h par une équipe d’astreinte et peut supporter une telle coupure (cas d’un serveur en interne demoindre importance par exemple).



43

Pourtant, le cache de la carte contrôleur, même configuré en write-back et protégé parune batterie, ne suffit pas à considérer que les mécanismes d’écriture sur disques soientdésormais fiables et optimisés (même si un grand pas a été effectué dans ce sens).

Concernant le volet de l’optimisation, l’analyse de la variable innodb_flush_methodet notamment de la valeur O_DIRECTqu’elle est susceptible de prendre, pourrait encorevous procurer quelques gains.

La fiabilité de vos données, notamment en cas de coupure électrique, est encore pluscruciale que l’optimisation. InnoDB dispose d’un système de récupération perfec-tionné en cas de crash mais il lui est parfois impossible de récupérer ce qui était pour-tant considéré comme durablement stocké.

Il est en effet possible que lors d’un enregistrement, au-delà de l’étape de la cartecontrôleur (dont le cache est comme il se doit protégé par une batterie), lorsquecelle-ci envoie le contenu de son cache vers les disques, ces derniers mentent : ils sonteux aussi capables de renvoyer un acquittement alors que l’écriture n’est pas encoreeffectuée. Ce mécanisme, orienté performance et basé sur un buffer en écritures pré-sent sur les disques, est très dangereux en cas de coupure de courant. Les donnéessont dans ce cas perdues avant d’avoir réellement été écrites sur les disques, rendantinutile la présence d’une batterie sur la carte contrôleur.

Conscient que la commande fsync() ne garantit pas que les données soient réellementécrites sur le périphérique, Mac OS X, par exemple, tient compte de ce problème et

JARGON innodb_flush_method = O_DIRECT

Il s’agit ici d’indiquer au système d’exploitation de ne pas mettre en cache les données candidates à unflush disque, par exemple. On estime en effet que le cache InnoDB est suffisant et qu’il est inutile de per-dre du temps et de l’espace mémoire en remplissant le cache système. Avec O_DIRECT la fonctionnalitéread-ahead potentiellement offerte par l’OS est également désactivée. InnoDB sait également effectuercette opération lui-même grâce aux modes sequential et randomread-ahead. En mode séquentiel,InnoDB est capable de détecter que pour certaines parties du tablespace l’accès est séquentiel ; lemoteur envoie alors une demande de lectures correspondant à la suite logique de ce qui a déjà été lu. Lemode random permet à InnoDB de détecter quelle partie du tablespace sera probablement lue complète-ment à partir du buffer_pool et d’anticiper ces lectures : B http://dev.mysql.com/doc/refman/5.1/en/innodb-disk-io.htmlNotez que l’utilisation de cette variable peut impacter les performances de votre système, souvent dansle bon sens. Nous vous conseillons cependant de la tester sur un environnement de recette avant de latenter en production (cette variable n’est de toute façon pas modifiable à chaud).L’utilisation de cette option fait débat depuis longtemps, le site ci-dessous est un bon exemple de discus-sion sur le sujet. Si Linus Torvald lui-même est un opposant de la méthode O_DIRECT, Peter Zaitsev(Percona) a un avis opposé. À lire.B http://kerneltrap.org/node/7563



permet d’utiliser une autre fonction (F_FULLFSYNC), celle-ci permettant de contrôler lecache du disque et de demander son écriture réelle. Cependant, ce serait trop simple :certains disques FireWire sont connus pour ne pas effectuer l’action demandée...

Résultat des courses, seuls des scénarios de test à base de coupures de courant bru-tales programmées par vos soins pourront vous certifier que les données sont correc-tement écrites, y compris dans un contexte exceptionnel.

Les SSD : futur hit ?Toujours davantage de cœurs au sein des processeurs, encore plus de mémoire vive et ladémocratisation des SSD (Solid State Drive), voilà ce qui nous attend peut-être dans unavenir très proche.

Les SSD sont un des types de matériels qui évoluent le plus. Encore chers comparésà leurs ancêtres dotés de pièces mécaniques, leur prix chute régulièrement malgréquelques hausses passagères dues à des pénuries de composants mémoire. Unerécente étude de iSuppli indique qu’en 2008 1,4 millions d’unités ont trouvé pre-neur... À comparer avec les 5,8 millions d’unités qui s’écouleront pour 2009 et les 65millions d’unités prévues pour 2013 !

Trop chers pour être un marché de masse, ce sont aujourd’hui les centres de donnéesqui se ruent sur les SSD : faible consommation électrique et encombrement réduitsont deux arguments qui font mouche dans le cadre de cette activité.

Plus proches de la RAM que d’un disque dur où s’activent plateaux et têtes de lec-tures, les SSD sont des puces mémoire persistantes (de type Flash), un peu commenos clés USB.

Les inconvénients relatifs à cette technologie sont en ce moment les suivants (maisles SSD évoluent très vite !) :• les performances en random-write : les puces à mémoire Flash utilisées par les SSD

nécessitent d’effacer une grande zone mémoire avant l’écriture, ce qui pénalise lesperformances. Cependant des modèles récents ont affiché de très gros progrès surce sujet. Il semble donc que les jours de cet inconvénient soient comptés ;

• la durée de vie du support : les cellules mémoire s’usent en fonction du nombred’écritures reçues. Différents algorithmes sont déjà à l’œuvre afin d’optimiser cette

À lire également

Un outil de Brad Fitgerald longuement débattu sur Slashdot traite précisément de ce problème lié à lamise en cache de certains disques et permet de les détecter.B http://brad.livejournal.com/2116715.html B http://hardware.slashdot.org/article.pl?sid=05/05/13/0529252



45

durée de vie et de marquer comme défectueuses certaines cellules le cas échéant.Les contrôleurs de ces puces sont en constante amélioration et là aussi cette duréede vie autrefois considérée comme problématique semble en passe d’être résolue ;

• prix rapporté au Go ;• faible capacité (Go) par unité.

Au chapitre des avantages :• temps d’accès extrêmement faibles (quelques centièmes de ms contre 4 ms envi-

ron pour un disque performant : un facteur 10 !) ;• excellentes performances en lectures aléatoires (random read) ;• adaptée aux environnements OLTP (majorité de lectures) ;• consommation énergétique réduite.

Des solutions matérielles se montent autour de cette technologie : Shooner informa-tion Technology, Virident, Fusion-io sont quelques-uns des noms que vous pouvezétudier si le sujet vous intéresse.

Les moteurs de stockage tentent également de se mettre à la page. Tandis que PBXTcontient des mécanismes dédiés à ce type de matériel, un moteur émergent tel queRethinkDB est entièrement tourné sur cette technologie.

Nous vous conseillons de parcourir les liens fournis pour cette section dans le con-tenu en ligne dédié à cet ouvrage afin de profiter de nos liens relatifs aux SSD. SeulInternet peut fournir des informations à jour sur un sujet aussi brûlant...

MySQL et la mémoireLes besoins en mémoire de MySQL sont très variables. Ainsi des valeurs courantestelles que 8 Go, 16 Go ou 32 Go peuvent s’avérer amplement suffisantes ou trop fai-bles selon la quantité de données avec laquelle vous travaillez.

Un manque de mémoire constitue un goulet d’étranglement important pour MySQLpuisque cette déficience en RAM créera une tension par ailleurs, notamment au niveaudes disques, MySQL devant récupérer à partir des disques ce qui n’a pas pu être stockéen RAM. De là peuvent découler très probablement des lenteurs, des verrous et uneaccumulation de requêtes impactant processeurs et disponibilité de votre application.Le manque de ressources mémoire a un potentiel tout à fait destructeur.

Rappelons ici quelques chiffres déjà cités lorsque nous évoquions les disques en débutde chapitre : pour une lecture, un parcours séquentiel en mémoire est environ dix foisplus rapide que sur disque mais deux mille cinq cents fois plus rapide dès lors qu’ils’agit d’un parcours aléatoire.



Comment MySQL utilise-t-il la mémoire ?Le serveur MySQL utilise la mémoire à différentes occasions. Tout d’abord le cached’index pour MyISAM (key_buffer_size) et le buffer pool pour InnoDB(innodb_buffer_pool_size) sont les caches les plus gourmands en mémoire. Cesdeux caches sont les plus importants et se comptent en Go voire en plusieurs dizainesde Go pour le buffer pool.

On compte ensuite différents caches, de tailles plus modestes :• Le cache de requêtes (query cache), dont la taille maximale conseillée varie entre

128 et 256 Mo. Ce type de cache est étudié en détail au chapitre 6.• Chaque connexion au serveur MySQL est un thread à qui le serveur alloue une

quantité de mémoire variable, selon la façon dont sont configurés les buffers pro-pres à chaque session dans le fichier my.cnf. Une fois le thread terminé, lamémoire est soit libérée s’il est détruit complètement, soit conservée si le threadest gardé dans le cache qui lui est dédié. Ce mécanisme permet d’éviter une pertede temps à la création d’un nouveau thread.

• Les tables MEMORY utilisées en interne par MySQL, lors d’opérations de tri parexemple. Leur taille maximale est définie par la plus petite valeur entretmp_table_size et max_heap_table_size.

• Les tables liées aux privilèges de chaque utilisateur MySQL vérifient pour chaquerequête si un utilisateur possède les droits suffisants. Pour des raisons de perfor-mance, ces tables sont chargées en mémoire.

• Le table_cache : cache des handlers de fichiers liés aux tables ouvertes parMySQL.

Une fois vos tests effectués, si vous manquez de mémoire (caches d’index MyISAMtrop faibles, faible efficacité du buffer pool sous InnoDB alors qu’il est impossibled’ajouter à ces différents buffers davantage de RAM sans mettre en péril le reste dusystème), il est temps d’acheter de nouvelles barrettes.

Ajouter de la mémoire vive est un des moyens les plus simples, rapides et bon marchéd’augmenter de façon importante les performances de votre serveur MySQL. L’ajoutde mémoire soulage les disques (les random I/O coûtent très cher), évite à MySQLet au système d’exploitation d’incessants allers-retours entre mémoire vive et disquestrès coûteux. Une quantité de mémoire vive suffisante contribue également à réduirel’utilisation du swap.

La différence peut vraiment être spectaculaire si votre activité est particulièrementorientée lectures. En revanche, si celle-ci est fortement sollicitée au niveau des écri-tures, il est peut-être plus sage d’investir dans un système disque plus performant.Pensez notamment aux cartes contrôleur BBWC étudiées précédemment.



47

Un outil tel que mysqlreport vous aide à visualiser concrètement le pourcentage delectures/écritures en cours sur votre système.

À l’instar des SSD, la mémoire vive permet également à certains constructeurs deproposer du matériel destiné à prendre place au sein de vos centres de données sous laforme de boîtiers 2U ou 3U. Violin ou Texas Memory Systems proposent des boî-tiers (onéreux) capables de contenir jusqu’à 500 Go de RAM environ. Vous trouverezdavantage d’informations sur les sites respectifs de ces constructeurs ou dans notrerubrique liens en ligne concernant ce chapitre.

Figure 2–7Les allers-retours entre disques et mémoire vives sont coûteux.



Le moteur de stockage (storage engine) est le composant qui, au sein de l’architecturedu serveur MySQL, est responsable du stockage des informations sur disque ou enmémoire.

Nous allons présenter les moteurs les plus utilisés sous MySQL, tels que MyISAMet InnoDB, mais également ceux de la nouvelle génération émergeant de la commu-nauté MySQL.

Mécanismes d’un moteur de stockageChaque moteur possède ses spécificités ainsi que ses propres paramètres de configu-ration. Depuis la version 5.1 de MySQL, on dit qu’un moteur de stockage se branche(pluggable). En effet, il est désormais inutile de compiler MySQL pour ajouter unmoteur : il suffit de copier une bibliothèque dans le répertoire prévu à cet effet et dela charger à chaud. Il est néanmoins nécessaire que cette bibliothèque soit disponiblepour votre système.

MySQL supporte plusieurs types de moteur de stockage. Dans la pratique, vouspouvez écrire votre propre moteur. Pour cela, il faudra définir les interfaces néces-saires et disposer de bonnes connaissances en langage C. Avant de vous lancer danspareille aventure, nous vous conseillons de bien étudier l’existant afin de ne pas réin-venter la roue... Peut-être trouverez-vous celui qui convient à votre application.

3Les moteurs de stockage



Comme on le voit sur ce schéma, les étapes sont les suivantes :1 Vérification de la présence du SELECT dans le cache ;2 si oui, on renvoie le résultat de la requête (resultset) ;3 sinon, on parse le SQL, pour en vérifier la validité (dictionary check) ;4 l’optimiseur calcule le query plan ;5 on interroge l’API pour récupérer les blocs ;6 l’API va chercher les blocs dans le moteur de stockage ;7 on assemble le résultat ;8 on le renvoie au client ;9 on le met en cache (selon la configuration).

Avant de commencer l’analyse en détail du schéma et des requêtes dans une optiqued’optimisation, il est intéressant de connaître quels sont les moteurs à notre disposition.

Figure 3–1Les étapes entre un client MySQL et le moteur de stockage

mysql> SELECT engine, support FROM information_schema.engines\G*************************** 1. row ***************************engine: InnoDBsupport: YES


Les moteurs de stockageCHAPITRE 3

51

Dans les versions précédentes de MySQL, il faut examiner les variables (par exemplehave_innodb).

*************************** 2. row ***************************engine: MRG_MYISAMsupport: YES*************************** 3. row ***************************engine: BLACKHOLEsupport: YES*************************** 4. row ***************************engine: CSVsupport: YES*************************** 5. row ***************************engine: MEMORYsupport: YES*************************** 6. row ***************************engine: FEDERATEDsupport: NO*************************** 7. row ***************************engine: ARCHIVEsupport: YES*************************** 8. row ***************************engine: MyISAMsupport: DEFAULT

mysql> SHOW ENGINES\G*************************** 1. row *************************** Engine: InnoDB Support: NO Comment: Supports transactions, row-level locking, and foreign keysTransactions: NULL XA: NULL Savepoints: NULL*************************** 2. row *************************** Engine: MRG_MYISAM Support: YES Comment: Collection of identical MyISAM tablesTransactions: NO XA: NO Savepoints: NO*************************** 3. row *************************** Engine: BLACKHOLE Support: YES Comment: /dev/null storage engine (anything you write to it disappears)Transactions: NO XA: NO Savepoints: NO[...]



L’interface de gestion des plug-ins est le successeur de l’ancienne interface UDF(User Defined Function) qui permettait aux utilisateurs de créer leurs propres fonc-tions pour MySQL. La modification a eu pour but, entre autres, d’augmenter lasécurité, d’améliorer la gestion des versions...

Vous constatez que les moteurs sont bien affichés comme des plug-ins. Le champstatus indique si le moteur est activé, ce qui signifie que la librairie a été chargée enmémoire.

Installation et suppression d’un moteurPrenons XtraDB comme exemple, afin de décrire la manipulation nécessaire pourinstaller un moteur sur un serveur MySQL.

La première étape consiste à récupérer le plug-in sur le site de ses auteurs :

B http://dev.mysql.com/doc/refman/5.1/en/plugin-api.html

mysql> SELECT plugin_name, plugin_type, plugin_status FROM information_schema.plugins;+-------------+----------------+---------------+| plugin_name | plugin_type | plugin_status |+-------------+----------------+---------------+| binlog | STORAGE ENGINE | ACTIVE || partition | STORAGE ENGINE | ACTIVE || ARCHIVE | STORAGE ENGINE | ACTIVE || BLACKHOLE | STORAGE ENGINE | ACTIVE || CSV | STORAGE ENGINE | ACTIVE || MEMORY | STORAGE ENGINE | ACTIVE || InnoDB | STORAGE ENGINE | ACTIVE || MyISAM | STORAGE ENGINE | ACTIVE || MRG_MYISAM | STORAGE ENGINE | ACTIVE |+-------------+----------------+---------------+

Pour avoir plus de détails sur l’API : B http://forge.mysql.com/wiki/MySQL_Internals_Custom_Engine

B http://www.percona.com/mysql/xtradb/5.1.39-8/RPM/rhel4/



53

Pour cette installation, nous choisissons le plug-in pour MySQL 5.1.39 compilé surRHEL 4.

Ce paquetage rpm comprend les différents fichiers dont nous avons besoin : biblio-thèques et scripts d’installation.

Il est nécessaire de vérifier que les bibliothèques sont bien installées au bon endroit :

Dans cet exemple, le répertoire où doivent se trouver les plug-ins est bien identique.Si ce n’est pas le cas, vous devrez soit changer la configuration, soit copier les biblio-thèques au bon endroit. Une fois ceci effectué, il faut démarrer MySQL et chargerles bibliothèques. Le script install_innodb_plugins.sql est conçu à cet effet. Ilexécute les commandes suivantes :

shell> wget http://www.percona.com/mysql/xtradb/5.1.39-8/RPM/rhel4/Percona-XtraDB-1.0.4-8-5.1.39-8.rhel4.x86_64.rpm

shell> rpm -qlp Percona-XtraDB-1.0.3-5-5.1.34-5.rhel4.x86_64.rpm/usr/lib64/mysql/plugin/ha_innodb.so/usr/lib64/mysql/plugin/ha_innodb.so.0/usr/lib64/mysql/plugin/ha_innodb.so.0.0.0/usr/lib64/mysql/plugin/install_innodb_plugins.sql

mysql> SHOW VARIABLES LIKE"%plugin%";+---------------+-----------------------------+| Variable_name | Value |+---------------+-----------------------------+| plugin_dir | /usr/lib64/mysql/plugin/ |+---------------+-----------------------------+

INSTALL PLUGIN innodb SONAME 'ha_innodb.so';INSTALL PLUGIN innodb_trx SONAME 'ha_innodb.so';INSTALL PLUGIN innodb_locks SONAME 'ha_innodb.so';INSTALL PLUGIN innodb_lock_waits SONAME 'ha_innodb.so';INSTALL PLUGIN innodb_cmp SONAME 'ha_innodb.so';INSTALL PLUGIN innodb_cmp_reset SONAME 'ha_innodb.so';INSTALL PLUGIN innodb_cmpmem SONAME 'ha_innodb.so';INSTALL PLUGIN innodb_cmpmem_reset SONAME 'ha_innodb.so';INSTALL PLUGIN XTRADB_ENHANCEMENTS SONAME 'ha_innodb.so';INSTALL PLUGIN INNODB_BUFFER_POOL_PAGES SONAME 'ha_innodb.so';INSTALL PLUGIN INNODB_BUFFER_POOL_PAGES_BLOB SONAME 'ha_innodb.so';INSTALL PLUGIN INNODB_BUFFER_POOL_PAGES_INDEX SONAME 'ha_innodb.so';INSTALL PLUGIN innodb_rseg SONAME 'ha_innodb.so';



Il est possible de supprimer le plug-in de façon analogue :

Les forces en présence : moteurs utilisé par l’applicationNous connaissons maintenant les moteurs disponibles sur le serveur ; il nous restealors à vérifier lesquels sont utilisés par l’application.

Dans une base de données MySQL chaque table possède un seul moteur de stoc-kage. Si vous ne spécifiez pas la valeur ENGINE dans la DDL (Data Definition Lan-guage), MySQL utilisera le moteur de stockage par défaut défini par la variable

UNINSTALL PLUGIN ;

ATTENTION Suppression d’un moteur de stockage utilisé par une table

Si vous supprimez un moteur de stockage utilisé par une ou plusieurs tables, les données seront toujoursprésentes mais vous ne pourrez plus y accéder. L’installation d’un nouveau moteur doit être réalisée parle DBA. Cette opération nécessite en effet des droits spécifiques pour être exécutée correctement. Ils’agit ici notamment du droit d’écriture dans la table mysql.plugin.

mysql> SHOW PLUGINS;*************************** 1. row *************************** Name: binlogStatus: ACTIVE Type: STORAGE ENGINELibrary: NULLLicense: GPL*************************** 2. row *************************** Name: partitionStatus: ACTIVE Type: STORAGE ENGINELibrary: NULLLicense: GPL*************************** 3. row *************************** Name: ARCHIVEStatus: ACTIVE Type: STORAGE ENGINELibrary: NULLLicense: GPL*************************** 4. row *************************** Name: BLACKHOLEStatus: ACTIVE Type: STORAGE ENGINELibrary: NULLLicense: GPL



55

storage_engine. Si celle-ci n’est pas définie, la table prendra pour défaut le typeMyISAM.

Avec une telle configuration, chaque nouvelle table créée sera du type InnoDB siaucune instruction spécifique n’indique un autre moteur. En voici la preuve :

Le type de la table est bien InnoDB.

Il est conseillé d’éviter de mixer plusieurs moteurs au sein d’une même base dedonnées : ce n’est généralement pas une bonne pratique. Il est en effet beaucoup plus

mysql> SHOW VARIABLES LIKE 'storage_engine'\G*************************** 1. row ***************************Variable_name: storage_engine

Value: InnoDB1 row in set (0.00 sec)

mysql> CREATE TABLE i (i int);Query OK, 0 rows affected (0.13 sec)mysql> show create table i\G*************************** 1. row *******************Table: iCreate Table: CREATE TABLE ì` ( ì` int(11) DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1

B.A.-BA Créer ses tables à partir de l’existant

Voici deux commandes similaires aux résultats différents :CREATE TABLE T_cible LIKE T_source

copie la structure de la table T_source (le moteur de stockage...) mais pas les données.CREATE TABLE T_cible SELECT * FROM t_source

copie les données, les colonnes mais pas les index ni le moteur (c’est-à-dire le moteur par défaut, sauf sion le spécifie dans CREATE).mysql> CREATE TABLE test LIKE City;Query OK, 0 rows affected (0.05 sec)

mysql> CREATE TABLE test2 SELECT * FROM City;Query OK, 4076 rows affected (0.14 sec)Records: 4076 Duplicates: 0 Warnings: 0

mysql> CREATE TABLE test3 engine =memory SELECT * FROM City;Query OK, 4076 rows affected (0.07 sec)Records: 4076 Duplicates: 0 Warnings: 0



délicat de configurer correctement un serveur qui héberge des tables de plusieurstypes qu’un serveur dédié à des tables d’un même moteur. Mélanger les moteurs peutentraîner des problèmes de performance ou de cohérence, même si techniquementcela reste réalisable. Il faut noter que des tables créées via des commandes telles queCREATE TABLE t SELECT seront également du type du moteur par défaut. Dans ledoute, il est préférable de laisser la valeur par défaut à MyISAM.

Il existe plusieurs méthodes pour vérifier quels sont les moteurs utilisés :• utiliser les métadonnées ;

• regarder les DDL de chacune des tables ;

• examiner le statut (status) des tables ;

ou

ou

• consulter dans l’arborescence des fichiers les extensions des fichiers de données.

Nous vous conseillons la première méthode, car les autres sont plus contraignantes.S’enquérir du statut de toutes les tables est susceptible d’altérer les performances devotre système selon le moteur utilisé. En effet, alors que la commande SHOW TABLESTATUS pour des tables en MyISAM n’a aucun impact, elle peut être dramatique pourInnoDB. Notez également que ce moteur se base sur des estimations pour ce type decommandes. Ne soyez donc pas surpris que d’une exécution à l’autre le résultat varie ;InnoDB ne parcourt pas toute la table car le coût serait trop important. Contraire-ment à MyISAM, par exemple, le nombre total d’enregistrements n’est pas conservépar InnoDB. À ce titre, un count(*) inconditionnel obligerait InnoDB à parcourirtoute la table alors que la même commande est instantanée avec MyISAM. Si vous

mysql> SELECT table_schema, table_name, table_type, engine FROM tables;

mysql> SHOW CREATE TABLE maTable;

mysql> SHOW TABLE STATUS;

SHOW TABLE STATUS LIKE 'matable'\G

SHOW TABLE STATUS FROM mabase LIKE 'matable' \G

shell> ls -lah /var/mysql/data/monSchema/



57

avez un doute sur le nombre d’enregistrements de vos tables InnoDB et que votresystème n’est pas surchargé, vous pouvez malgré tout pour vous rassurer lancer unSELECT COUNT(*) FROM...

Pour illustrer la suite de notre propos, nommons le schéma monSchema ; il contient latable maTable.

Les critères de choix d’un moteurQuels sont les critères de choix qui s’offrent à vous ? Les paramètres à prendre enconsidération reposent essentiellement sur les caractéristiques de vos applications.Chaque moteur a ses avantages et ses inconvénients.

Un moteur qui supporte les transactions va, par exemple :• être plus résistant aux pannes (matérielles…) ;• avoir une meilleure concurrence ;• offrir davantage de flexibilité (commit, rollback) ;• nécessiter davantage de ressources : le moteur a, par exemple, besoin d’un système

disque plus puissant pour supporter les nombreuses écritures.

Au contraire, un moteur qui ne prend pas en charge les transactions peut être plusrapide. Ce n’est pas une certitude puisque les performances dépendent du type derequêtes, des index et de l’application elle-même.

Dans tous les cas, un moteur non transactionnel :• nécessitera moins d’espace disque ;

CONVENTIONS TERMINOLOGIQUES Base de données, serveur, instance, schéma

Jusqu’à la version 5.0, MySQL évoquait la notion de base de données et non de schéma pour désignerl’endroit où les données sont stockées. Il est nécessaire de préciser ces différentes notions afin d’êtrebien compris par son interlocuteur. Une convention de nommage peut être nécessaire. En effet, plusieurstermes peuvent définir le même concept. Une base de données MySQL est ainsi susceptible de représenter un serveur, une instance ou encore unschéma selon l’interlocuteur auquel on s’adresse. Voici des conventions que nous utilisons :• Serveur : machine physique où sont installés les binaires de MySQL.• Instance : processus de MySQL qui écoute sur un port (par défaut 3306).• Schéma : ensemble d’objets (table, vue, événement, procédures stockées...). Par schéma, on pense au

schéma conceptuel ou schéma relationnel qui est une représentation graphique permettant de décrirele fonctionnement d’une base de données. Il présente les objets de la base, leurs caractéristiques etleurs relations.

Par abus de langage, MySQL appelait « base de données » un schéma. Cela importe peu tant que vousavez les mêmes conventions que vos collègues.



• sera moins gourmand en mémoire ;• mais sera moins résistant aux pannes.

Les principaux critères pour choisir son moteur sont les suivants :• le support des transactions ;• la concurrence : lorsqu’un nombre conséquent de clients accèdent aux mêmes

tables ou données, la façon dont le moteur gère les verrous a une grande influencesur la concurrence du moteur ;

• les contraintes d’intégrité (clés étrangères) : une contrainte d’intégrité renforce l’inté-grité des données en base. Prenons comme exemple un modèle relationnel classique1-N et partons du principe qu’une personne possède une et une seule adresse. La con-trainte d’intégrité va s’assurer que chaque nouvelle adresse est bien associée à une per-sonne présente dans la base. Le développeur choisit où il doit implémenter sacontrainte : soit au niveau de l’applicatif soit au niveau de la base de données ;

• le stockage physique sur le disque dur, la taille des blocs...• les types d’index supportés (B-tree, fulltext, hash...). Retenez pour le moment

qu’une bonne gestion des index est cruciale pour obtenir de bonnes performancesde la part de la base de données. Nous verrons de plus que chaque moteur implé-mente les index à sa façon. Nous étudierons leurs points communs et différences,en examinant, notamment entre MyISAM et InnoDB :– la gestion de la mémoire ;– les performances ;– les propriétés spécifiques.

Moteurs disponibles : InnoDB, MyISAM, Merge, Memory, Archive

Le moteur InnoDBSupport des clés étrangères, transactionnel, fiable, mais aussi complexe, InnoDB estun moteur qui ne se laisse pas dompter en quelques heures. Cependant, avec un peud’entraînement, quelques essais et avec l’aide de cet ouvrage, vous apprendrez à tirerle meilleur parti de ce moteur phare dans l’univers des moteurs de stockage disponi-bles aujourd’hui sous MySQL. Les plus grands comptes Internet ne s’y sontd’ailleurs pas trompés : InnoDB est le moteur le plus utilisé parmi les sites Internet àforte audience motorisés par MySQL.



59

Avant d’entrer davantage dans le détail du fonctionnement d’InnoDB, revenons plusprécisément sur quelques-unes de ses caractéristiques principales qui le distinguentnotamment de MyISAM, le moteur par défaut de MySQL. Une fois les grandeslignes dessinées, vous serez à même de décider si InnoDB est le moteur qu’il vousfaut et mérite donc les efforts que vous consacrerez à sa compréhension !

InnoDB est un des moteurs historiques de MySQL, le premier à supporter les tran-sactions ACID (atomicité, cohérence, isolation ou cloisonnement, durabilité ou con-servation). Depuis 2008, le moteur InnoDB est disponible sous deux formats :• livré avec MySQL ;• sous la forme d’un plug-in.

Il appartient à InnoBase/Oracle. Depuis la version 5.1.38, le plug-in est livré pardéfaut. C’est de nos jours le moteur le plus utilisé. La version plug-in a permis àInnoBase de ne plus être dépendant des versions de MySQL.

Le mode plug-in apporte également beaucoup de nouvelles fonctionnalités :• meilleures performances grâce à l’amélioration du système de verrou et de la

montée en charge pour les plates-formes multicœurs ;• création d’index plus performante ;• compression des données.

Étant donné que le choix éventuel du transactionnel est un paramètre essentiel d’unmoteur de stockage, nous préférons préciser ce qu’est une transaction et le concept detransaction ACID.

Figure 3–2Quelques éléments clés du moteur InnoDB



B.A-BA Les propriétés ACID

Une base de données transactionnelle doit respecter le modèle ACID :• Atomicité : une transaction est soit complètement validée soit complètement annulée.• Cohérence : une transaction ne doit pas laisser la base dans un état incohérent.• Isolation : une transaction ne peut voir aucune autre transaction en cours d’exécution.• Durabilité : lorsque le client est informé du succès de la transaction, les résultats de

celle-ci sont conservés durablement.

BON À SAVOIR Le MVCC

Un des atouts d’InnoDB pour supporter de fortes charges repose sur le système MVCC(Multi Version Concurrency Control). Dans un environnement multiutilisateur, plusieursthreads accèdent aux ressources de façon concurrente. Afin que ces opérationss’effectuent dans les meilleures conditions possibles, un système de contrôle et departage des ressources est nécessaire. Il s’agit du MVCC.Pour une base de données, ce système doit s’assurer que :• Les transactions concurrentes respectent l’intégrité de cette base.• Toutes les opérations peuvent être sérialisées et rejouées.• Si une transaction est perdue le système n’est pas affecté.• Si une transaction est annulée (ROLLBACK), les modifications apportées seront sup-

primées.Il existe plusieurs catégories de systèmes permettant le contrôle de la concurrence.Les principaux sont :• Optimiste : la synchronisation de la transaction est retardée pour éviter un blocage

des lectures/écritures. Les transactions qui violent les règles de synchronisation sontannulées.

• Pessimiste : les transactions susceptibles de poser des problèmes sont bloquées dèsle début.

Plusieurs méthodes existent :• 2PL, blocage en 2 étapes (Two-Phase Locking) ;• classement des transactions dans le temps ;• classement des transactions par commit ;• contrôle de la concurrence des index ;• MVCC, plusieurs versions.La méthode MVCC est utilisée par la plupart des moteurs de stockages transaction-nels tels que InnoDB, Falcon, PBXT... Cette méthode permet à chaque utilisateur devisualiser une version indépendante (un cliché) de la base de données. Les modifica-tions effectuées par une personne (transaction concurrente) ne sont vues par lesautres utilisateurs qu’une fois qu’elles sont validées (COMMIT).MVCC parvient à rendre les transactions sérialisables grâce à la date et à des identi-fiants de transaction. Ainsi, celles-ci n’ont jamais à attendre qu’un objet soit disponi-ble car le moteur (dans ce cas InnoDB) maintient plusieurs versions du même objet.Voici une liste non exhaustive de SGBD implémentant également le MVCC : BerkeleyDB, InterBase, Microsoft SQL Server, Oracle, PostgreSQL, Sybase...



61

Contrairement à MyISAM, InnoDB est un moteur transactionnel. Il permet doncau développeur de grouper d’un point de vue logique plusieurs instructions en uneseule. Le groupe d’instructions sera validé si le COMMIT est effectué ; dans le cas con-traire un ROLLBACK annulera l’ensemble des modifications.

Un autre avantage d’InnoDB est la concurrence, c’est-à-dire la faculté d’un serveurMySQL (par l’intermédiaire de son moteur de stockage) à servir davantage derequêtes dans le même temps. En effet, contrairement à MyISAM qui verrouillel’intégralité d’une table le temps que celle-ci soit mise à jour lors d’un UPDATE ou d’unDELETE (les INSERT sont un cas à part ; voir MyISAM et la variable systèmeconcurrent_insert étudiée dans ce chapitre), InnoDB propose un verrouillage parligne beaucoup moins bloquant pour les accès concurrents. Cependant, à y regarderde plus près, InnoDB utilise lui aussi en interne des systèmes de verrouillage (notam-ment des index). L’ensemble est malgré tout moins pénalisant que le système de ver-rouillage par table employé par MyISAM. En cela, InnoDB est beaucoup plusapproprié à un environnement mixte de lectures/écritures que MyISAM.

Figure 3–3La vie d’une transaction débute en mémoire et se termine sur disque si elle est validée.



Au niveau de sa structure, InnoDB utilise trois types de fichiers particuliers dans lesrépertoires suivants :• ibdata/ibdata1 – tablespace partagé ;• iblog/ib_logfileX – fichiers qui vont stocker toutes les transactions qui sont

commitées ;• data/monSchema/mytable.frm – qui stocke comme pour MyISAM la structure de

la table utilisée par MySQL pour valider les SQL.

Par défaut toutes vos tables sont créées dans le tablespace partagé. Il contient plu-sieurs informations :• le dictionnaire – structure des tables, un peu comme MySQL et les fichiers .frm ;• les données et index ;• les logs d’annulation (undo logs) – qui vont permettre de faire des ROLLBACK des

transactions et de revenir ainsi à l’état original.

Vous avez la possibilité de forcer InnoDB à créer un tablespace par table(innodb_file_per_table). Si vous activez cette option toutes les nouvelles tablesposséderont leur propre tablespace, maTable.idb, contenant données et index. Letablespace partagé ne disparaît pas pour autant puisqu’il demeure indispensable pourle fonctionnement du dictionnaire et pour les undo logs.

Pour des raisons de performance, InnoDB tente de mettre en cache le plus souventpossible ses opérations d’écriture. Lorsqu’un enregistrement est inséré (ou modifié),une page mémoire est allouée dans une mémoire tampon appelée le buffer pool.InnoDB conserve ces pages dans ce buffer tant qu’il le peut afin de ne pas avoir à lesécrire sur le disque. Les informations contenues y sont volatiles et seront donc per-dues si le serveur est redémarré. Dans un tel cas, InnoDB tire parti de son journal des

Figure 3–4Le buffer pool et le tablespace représentés au sein des structures principales d’InnoDB



63

transactions (ib_logfileX) et détecte que des données contenues dans ce journaln’ont pas été répercutées sur le disque. Les transactions manquantes sont alorsrejouées. Ce mécanisme est appelé mode de récupération ou recovery mode. Notezqu’une fois dans ce mode, le serveur est considéré en maintenance et qu’aucune con-nexion n’est possible.

Lorsque le buffer pool est purgé, les données sont écrites sur le disque. Ce flush seproduit quand le buffer pool atteint son seuil maximal de pages modifiées ou bien siun checkpoint est atteint (le journal de transactions ib_logfile1 est plein et les écri-tures s’effectuent désormais sur le second : ib_logfile2). InnoDB spécifie alors dansson journal de transactions que le buffer pool a été vidé.

MyISAMMyISAM (http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html) est le moteur pardéfaut de MySQL depuis la version 3.23. Il n’est pas fourni sous la forme d’unebibliothèque, il est donc impossible de le supprimer. Toutes les tables système l’utili-sent. Il est toujours très employé du fait de sa simplicité. Il s’appuie sur ISAM, undes premiers moteurs, auquel on a ajouté quelques fonctionnalités. Les informations

ASTUCE Sortir une table d’un tablespace partagé

Si vous choisissez d’utiliser innodb_file_per_table, les tables éventuellement déjà présentesdans le tablespace commun ne seront pas transformées : ce paramètre s’applique en effet sur les nouvel-les tables. Cependant, exécuter un ALTER sur une table se trouvant à l’intérieur du tablespace partagéen provoquera la sortie. En effet, la commande ALTER crée une nouvelle table.Dernier détail : cette nouvelle table disposera de son propre tablespace mais l’espace correspondant ne serapas libéré dans le tablespace commun. La seule façon de réduire la taille d’un tablespace commun est :1. d’exporter les données (backup logique), 2. de couper le serveur MySQL, 3. de supprimer le tablespace et les fichiers de log, 4. puis de redémarrer le serveur et recharger les tables exportées avec innodb_file_per_table.

Une opération coûteuse...La taille du tablespace d’InnoDB est à surveiller : elle croît dès que le moteur a besoin de place. Ceci estvalable y compris avec le réglage innodb_file_per_table, mais dans une moindre mesure bien sûr.

POUR ALLER PLUS LOIN

Vous trouverez plus d’informations sur InnoDB dans le chapitre consacré au paramétrage du serveur.Deux adresses pour aller plus loin : B http://dev.mysql.com/doc/refman/5.1/en/innodb.htmlB http://www.innodb.com/.



d’une table MyISAM sont stockées dans trois types de fichiers différents qui sontsitués par défaut dans le répertoire /var/data/mysql/monSchema/ :• maTable.frm qui contient la structure de la table.• maTable.MYD qui contient les données.• maTable.MYI qui contient les index.

Même si vous utilisez un moteur différent de MyISAM, vous trouverez toujours unfichier .frm pour vos tables : MySQL en a besoin pour valider les requêtes SQL.

MyISAM se sert d’un système de verrou basé sur le fichier : pour accéder à un enregis-trement, MySQL dépose un verrou en lecture. En revanche, pour écrire un enregistre-ment, MySQL applique un verrou en écriture. Seul ce dernier est exclusif. Il est doncpossible d’exécuter plusieurs requêtes simultanées en lecture mais une seule en écriture.

Ce mécanisme est à l’origine d’une des faiblesses du moteur MyISAM : une conten-tion au niveau des tables. En effet, si votre application génère une grande quantitéd’écritures en parallèle, elle va devoir attendre que la table MyISAM soit disponible.Les écritures seront donc sérialisées (effectuées les unes après les autres). En généralMyISAM est conseillé pour les applications qui demandent beaucoup plus de lec-tures que d’écritures, jusqu’à un certain point.

Un autre aspect qui ne penche pas en la faveur de ce moteur est celui de la corruptionpotentielle des fichiers. Une table soudainement illisible représente bien souvent lesymptôme d’une corruption de fichier. Pas de panique, vous n’avez encore rien perdu,mais que s’est-il passé ? Les raisons sont variées et MySQL a pour le moment sim-

Figure 3–5Principaux éléments du moteur MyISAM sur disque et en mémoire



65

plement détecté une incohérence. Il est alors nécessaire de réparer la table corrompueavec la commande REPAIR TABLE (ou les programmes myisamchk/mysqlcheck).Effectuez une sauvegarde préalable si possible, avec mysqlhotcopy, par exemple.

Par défaut MyISAM supporte les insertions concurrentes pour réduire au maximumles contentions au niveau des lectures. Si votre fichier n’est pas fragmenté (absence detrous car vous n’avez effacé aucun enregistrement), une insertion peut s’effectuer enfin de fichier pendant qu’une autre requête lit la table. De même, si plusieurs inser-tions surviennent en même temps, elles sont regroupées (mises en buffer, actionparamétrable en ajustant delay_key_write) et exécutées en séquence sans pourautant bloquer les lectures.

À ce sujet, concurrent_insert est une variable système à retenir. Grâce à elle, il estpossible de contrôler plus finement les mécanismes d’insertion.

Les trois valeurs qu’elle peut prendre sont 0, 1 et 2 :• 0 : les INSERT sont considérées comme les autres requêtes d’écritures et sont donc

verrouillées par les SELECT.• 1 : (par défaut) les INSERT ne sont pas bloquées, les SELECT non plus s’il n’y a pas

de trous dans la table (data free = 0, visible lors d'un SHOW TABLE STATUS LIKE'MaTable').

• 2 : les INSERT ne sont jamais verrouillées par les SELECT : tout est donc placé en finde fichier.

Si votre application génère un grand nombre de DELETE, les fichiers de donnéesseront fractionnés ce qui a un impact important sur les performances. Nous vousconseillons de défragmenter régulièrement vos tables MyISAM. La commande sui-vante permet de mener cette opération :

Figure 3–6La fragmentation en image

mysql>OPTIMIZE TABLE MaTable;



MyISAM fournit également des outils comme myisamchk qu’il faut veiller à ne pasutiliser sur une base en activité ! Vous devez soit stopper votre serveur MySQL, soitposer un verrou en lecture pour être certain que personne ne modifiera les données.En effet, si deux programmes accèdent aux données en parallèle vous avez de grandeschances de les corrompre.

OPTIMIZE TABLE fonctionne de la façon suivante :1 Détecte si la table est fragmentée et la compacte.2 Trie les index si nécessaire.3 Met à jour les statistiques (cette action peut également être effectuée indépen-

damment avec la commande ANALYZE TABLE).

Les statistiques sont utilisées par l’optimiseur de MySQL pour calculer la meilleurefaçon d’exécuter une requête SQL.

Pour les tables InnoDB, la commande OPTIMIZE TABLE revient à exécuter un ALTERTABLE qui recrée la table, les index et les statistiques tout en libérant les espaces inutilisés.

Quoi qu’il en soit, si votre table contient beaucoup de données, une commande telleque REPAIR ou OPTIMIZE est susceptible de durer jusqu’à quelques heures pour destables de plusieurs Go. L’accès à la table concernée est alors bloqué en écriture.

Revenons un instant sur la commande ANALYZE TABLE que nous venons d’évoquer :

Cette commande analyse et stocke la distribution des clés, en d’autres mots, calculeles statistiques. Pendant cette action, la table est verrouillée avec un READ LOCK pourMyISAM et un WRITE LOCK en InnoDB. Pour une table MyISAM, cela équivaut àmyisamchk --analyze.

mysql> OPTIMIZE TABLE test;+----------+----------+----------+-------------------------------------------------------------------+| Table | Op | Msg_type | Msg_text |+----------+----------+----------+-------------------------------------------------------------------+| test.test | optimize | note | Table does not support optimize, doing recreate + analyze instead || test.test | optimize | status | OK |

mysql> ANALYZE TABLE MaTable;



67

Contentions, corruptions... N’allez pas croire que le moteur MyISAM n’a que desinconvénients !

Outre sa rapidité, lorsqu’il est correctement employé et configuré, ce moteur apportedes fonctionnalités intéressantes comme :• les index FULLTEXT ;• la possibilité de préfixer les index pour les champs de type texte (CHAR, VARCHAR,TEXT) ou BLOB ;

• la compression ;• les index spatiaux – GIS ;• le déplacement facile des fichiers d’un serveur à un autre.

Mécanismes internes de MyISAM et formats de stockageMyISAM supporte trois formats de stockage :• Statique : c’est le cas d’une table qui ne contient pas de colonne à taille variable

(VARCHAR, VARBINARY, BLOB ou TEXT). Ce format est le plus simple et le plus sécu-risé (vis-à-vis de la corruption) mais également le plus rapide.

• Dynamique : format utilisé par les tables ayant des colonnes à taille variable. Iloccupe moins de place sur le disque.

Tableau 3–1 Contexte pour analyze, repair et optimize sous MyISAM et InnoDB

MyISAM InnoDB

ANALYZE tiède chaud

REPAIR oui n/a

OPTIMIZE tiède tiède – ALTER + ANALYZE

B.A.-BA Chaud, froid ou tiède ?

Voici un petit lexique concernant les différents états d’un serveur MySQL. Celui-ci peut-être défini commefroid (cold), tiède (warm) ou chaud (hot).

Serveur Verrou Commande

cold (froid) éteint n/a aucune

warm (tiède) démarré écriture/lecture possibilité de se connec-ter, requêtes en attente

hot (chaud) démarré aucun possibilité de se connec-ter, requêtes exécutées



• Compressé : ce format transforme la table en lecture seule et comme son noml’indique compresse au maximum les données pour prendre le moins de place pos-sible sur le disque (commande myisampack).

Les limites en termes de nombre de lignes sont définies par votre système (taille surle disque, serveur 32/64 bits...). Le pointeur d’accès aux données est par défaut de6 octets (4 précédemment) ce qui correspond à 256 To de données. Si nécessaire, ilest possible de passer ce pointeur à 8 octets.

Si vous utilisez MySQL depuis les versions 3.23, vous avez certainement déjà ren-contré une erreur sur une table volumineuse, indiquant que vous avez atteint lenombre maximal de lignes. La solution consiste alors à modifier les paramètresMAX_ROWS et AVG_ROW_LENGTH pour changer ainsi la taille du pointeur. Évidemment,cette opération nécessite l’utilisation de la commande ALTER TABLE qui bloquera latable en écriture le temps de l’opération.

Le serveur MySQL lui-même utilise MyISAM et offre deux exemple de tables ayantdes formats statique et dynamique respectivement.

La base mysql, qui contient les informations relatives à MySQL, utilise elle-même lemoteur de stockage MyISAM :

RAPPEL Mécanisme d’une commande ALTER TABLE

Voilà les étapes suivies lors de la modification de la structure d’une table T par la commande ALTERTABLE T :1. validation si besoin de la transaction ouverte sur la table (COMMIT) ;2. récupération d’un verrou en lecture ;3. création d’une table temporaire (TT1) ayant la même structure ;4. copie ligne à ligne de la table origine (TO) vers la table temporaire en changeant la structure en ligne ;5. renommage de la table origine en table temporaire (TT2) ;6. renommage de la table temporaire (TT1) en table origine (TO) ;7. effacement de la table temporaire TT2 ;8. libération du verrou.

mysql> USE mysql;Database changed

mysql> SHOW TABLE STATUS LIKE 'db' \G*************************** 1. row ***************************

Name: db Engine: MyISAM

Version: 10 Row_format: Fixed

Rows: 7



69

Vous constatez que ces deux tables n’ont pas le même format (Row_format).

Notez le champ Data_free susceptible le cas échéant d’indiquer que la table a besoind’être optimisée (ici 0 signifiant qu’il n’est pas besoin d’éxécuter la commandeOPTIMIZE TABLE).

Le moteur MERGE pour agréger plusieurs tables MyISAMIl n’y a pas si longtemps, MySQL ne supportait pas encore le partitionnement. Pourremédier à cela, il était possible (et ça l’est toujours) de simuler celui-ci manuellementavec une table MERGE composée de plusieurs tables MyISAM de structures identiques.

Avg_row_length: 440 Data_length: 3080

Max_data_length: 123848989752688639 Index_length: 5120

Data_free: 0Auto_increment: NULL

Create_time: 2008-08-09 11:36:46 Update_time: 2009-07-17 16:12:21 Check_time: 2008-08-09 11:36:53 Collation: utf8_bin Checksum: NULL

Create_options: Comment: Database privileges

mysql> SHOW TABLE STATUS LIKE 'event' \G*************************** 1. row ***************************

Name: event Engine: MyISAM

Version: 10 Row_format: Dynamic

Rows: 2Avg_row_length: 190

Data_length: 380Max_data_length: 281474976710655

Index_length: 4096 Data_free: 0

Auto_increment: NULL Create_time: 2008-08-09 11:36:53 Update_time: 2008-10-30 20:55:18 Check_time: NULL Collation: utf8_general_ci Checksum: NULL

Create_options: Comment: Events



L’application ne voit alors que la table T, alors que par ailleurs elle pourrait accéderdirectement aux tables T1, T2... composant T. La table T utilise en effet le moteurMERGE alors que physiquement les tables sous-jacentes, par exemple les tables T1,T2 et T3 sont toutes en MyISAM.

Il existe quelques limitations à ce mécanisme. Tout d’abord, toutes les tables doiventposséder une structure identique.

L’insertion dans une table MERGE est soumise à la condition d’avoir préalablementdéfini la table dans laquelle insérer les données. La marge de manœuvre à cet égardest faible puisque seule la première ou la dernière table de l’ensemble peuvent êtrechoisies (INSERT_METHOD=LAST ou INSERT_METHOD=FIRST).

D’un point de vue logique il est possible de se représenter une table MERGE commeune vue dans laquelle nous pourrions écrire. Étant basées sur le moteur MyISAM,les tables MERGE ont les mêmes avantages et inconvénients. Concernant la corrup-tion éventuelle d’un fichier, la corruption d’une table sous-jacente entraîne par défi-nition celle de la table MERGE.

Le moteur MERGE reprend le concept des partitions qui peut être utilisé pourséparer une table volumineuse en plusieurs plus petites, facilitant ainsi l’administra-tion de la base. En effet, considérons par exemple un système de logs remplissant unetable par jour ( T1 à T7 )... Une table MERGE T permettrait ici d’obtenir une vue surla semaine. Il serait alors possible chaque jour d’effacer les données de la semaine

Figure 3–7La table T utilise le moteur MERGE, T1, T2 et T3 sont en MyISAM.



71

précédente beaucoup plus rapidement. La commande DELETE est en effet potentielle-ment très lente sur de très grosses tables, la suppression d’une table complète étantbeaucoup plus rapide.

L’arrivée du partitionnement depuis la version 5.1 de MySQL sonne-t-elle le glasdes tables MERGE ? Nous pensons que non. Si certains systèmes utilisant MERGEvont certainement profiter des avantages du partitionnement (les requêtes utilisant laclé de partitionnement peuvent accéder directement à la partition voulue), le béné-fice n’est pas automatique. Il s’agit d’écrire :

au lieu de :

De grands comptes utilisent toujours le moteur MERGE pour stocker des chiffresd’audience sur 2 jours.

Le moteur MEMORY (anciennement HEAP)Anciennement connu sous le nom de HEAP, toutes les données et les index sontstockés en mémoire vive. L’accès aux données est alors très rapide du fait de l’absenced’accès disques. Attention cependant, l’intégralité des données étant stockée enmémoire, celles-ci seront perdues en cas de redémarrage du serveur. Seule la struc-ture de la table, matérialisée sous la forme du fichier frm, subsistera.

Les verrous posés par le moteur MEMORY s’effectuent, tout comme avecMyISAM, au niveau de la table toute entière.

Un des dangers du moteur MEMORY est qu’il risque de consommer davantage demémoire que le système n’en dispose réellement. Dans un tel cas le serveur est alorsforcé d’utiliser sa mémoire de swap, c’est-à-dire sur disque, entraînant une chute desperformances.

Un autre point important est que ce moteur ne supporte que les types de donnéesdits fixes. Ainsi, un champ VARCHAR(100) sera automatiquement transformé enCHAR(100), ce qui a pour effet de gaspiller de la mémoire si vous ne stockez que 10caractères.

Le moteur MEMORY est parfois utilisé dans le cadre d’optimisations. Prenonsl’exemple d’un site Internet dont la table LOGIN stocke les utilisateurs actuellementprésents sur le site. Utiliser le moteur MEMORY pour cette fonctionnalité est peurisqué (en cas de d’arrêt brutal les utilisateurs devront néanmoins se reconnecter).

mysql>TRUNCATE T1;

mysql> DELETE FROM t WHERE jour = 1;



Pour prendre un raccourci, il est possible d’imaginer une table MEMORY commeune table MyISAM en mémoire.

La plupart des moteurs de stockage ne gèrent que des algorithmes d’index de type B-tree.MEMORY quant à lui supporte également les index de type HASH. Une table dehachage est alors utilisée. Lorsque MySQL doit créer une table temporaire afin derésoudre une requête (en général dans le cas de jointures ou de tris), le serveur utilise destables MEMORY si la taille ne dépasse pas une certaine limite. Dans le cas contraire (ils’agit de la plus faible valeur entre les variables système tmp_table_size etmax_heap_table_size), MySQL se rabat sur une table MyISAM. Un index de typeHASH est le type par défaut pour une table MEMORY. Ce type d’index est très rapidepour des requêtes d’égalité (WHERE champ = X) mais ne fonctionne pas pour unerecherche de type WHERE champ > X.

Si vous avez besoin de ces deux types de requêtes, n’hésitez pas à rajouter un index detype B-tree.

Le moteur ARCHIVE pour un archivage compresséCe moteur stocke les données sous une forme compressée. Les seuls types derequêtes gérées sont SELECT et INSERT et les index ne sont pas acceptés. En contre-partie de ces restrictions, le gain de place sur disque est considérable ce qui faitd’ARCHIVE un moteur idéal pour archiver des données. Les taux de compressionvarient autour de 70 %. Les mécanismes de compression et décompression utiliséspar le moteur ARCHIVE consomment du CPU mais c’est à ce prix que l’espacedisque est préservé. Les performances sont susceptibles d’augmenter en lecturepuisque les nombres de blocs disque à parcourir sont moins nombreux du fait de lacompression des données.

Vous trouverez davantage d’informations sur http://dev.mysql.com/doc/refman/5.1/en/archive-storage-engine.html.

Autres moteurs

XtraDBImpossible d’évoquer les moteurs de stockage InnoDB sans parler d’un des meilleursmoteurs du moment : XtraDB de Percona. C’est un moteur hybride car reposant surune évolution du plug-in InnoDB. Percona est une société de conseil dont l’activitéprincipale repose sur MySQL avec une spécialisation orientée vers la performance.Ses consultants sont principalement confrontés à des problèmes de montées encharge autour de MySQL et d’InnoDB. Ces derniers ont ajouté des fonctionnalités



73

et des correctifs pour leurs clients, les Google patches, qui permettent de contournercertaines contentions au niveau serveur.

FalconIl était possible de tester le moteur Falcon avec la version 6.0 de MySQL (en bêta).Cette version a depuis été retirée mais pourrait réapparaître. Ce moteur a été créé parMySQL AB en vue de supporter les transactions et avec pour objectif de monter encharge linéairement. Depuis le rachat par Oracle, beaucoup d’interrogations subsis-tent quant à son devenir. Que faire en effet de deux moteurs concurrents sachantqu’Oracle investit déjà dans InnoDB ? De plus, même si celui-ci présente des fonc-tionnalités intéressantes, les premiers résultats ne sont pas encore très prometteurs.

FederatedLe moteur Federated permet d’accéder à des données situées sur un serveur distant.Les performances sont assez limitées surtout pour des requêtes traitant beaucoup dedonnées. Il est possible de se connecter à une base PostgreSQL. La maintenance detables distantes peut également poser problème sans parler des éventuels inconvé-nients de connexion entre les différents serveurs MySQL.

ExampleLe moteur Example ne fait rien. Il sert d’exemple aux développeurs pour implé-menter leur propre moteur de stockage.

BlackholeUne table utilisant le moteur Blackhole ou trou noir ne stocke absolument rien. Il y adeux types d’applications pour ce moteur :• validation des requêtes SQL ;

B http://www.percona.com/

B http://dev.mysql.com/doc/falcon/en/index.html

B http://dev.mysql.com/doc/refman/5.1/en/federated-storage-engine.html

B http://dev.mysql.com/doc/refman/5.1/en/example-storage-engine.html



• distribution des données sur différents serveurs grâce à un filtrage opéré au traversde la réplication (nous parlons dans ce cas de binlog proxy).

En effet, puisque la réplication ne contrôle pas le format des tables, il est possible d’ima-giner un master avec deux tables en InnoDB, T1 et T2, et un esclave sur lequel seraientinstallées T1 en MyISAM et T2 en Blackhole. Les requêtes affectant T2 seraient rejouéespar le thread SQL sur l’esclave sans pour autant stocker les données sur disque. Voustrouverez plus de détails à ce sujet au chapitre 8 consacré à la réplication.

CSVLe moteur CSV permet de stocker les informations sous la forme CSV (CommaSeparated Value). Il s’agit d’un fichier texte où les valeurs sont séparées par une virgulequi permet de faciliter les échanges vers d’autres applications.

IBMDB2ILe moteur IBM DB2I permet d’utiliser MySQL et de stocker des données dans unebase de données IBM DB2 tournant sur un serveur IBM i. L’idée est de partager lesdonnées entre des applications MySQL et des applications DB2 pour i. C’est uneutilisation de MySQL assez peu répandue.

NDB (Network Database)Le moteur NDB est utilisé par MySQL Cluster, la solution haute disponibilité deMySQL (MySQL HA) et ne peut donc pas être employé séparément. Il a été acheté àSony Ericsson en 2003. Vous trouverez plus d’informations sur NDB dans le chapitretraitant de la réplication.

B http://dev.mysql.com/doc/refman/5.1/en/blackhole-storage-engine.html

B http://dev.mysql.com/doc/refman/5.1/en/csv-storage-engine.html

B http://dev.mysql.com/doc/refman/5.1/en/se-db2.html

B http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-overview.html



75

Moteurs communautaires et autresL’interface fournie par MySQL permet à chacun de développer son propre moteurde stockage avec comme prérequis une bonne connaissance en C. D’autres moteurssont disponibles sur Internet, qu’ils soient Open Source ou propriétaires, commu-nautaires ou pas. Ces moteurs ne sont pas officiellement gérés par MySQL et sontdonc à utiliser à vos risques et périls. L’organisme développant le moteur s’occupe dusupport, de la documentation et des bogues. La plupart des moteurs sont référencéssur la forge MySQL :

MariaÀ l’origine MARIA devait être une évolution de MyISAM corrigeant les problèmesde corruptions qui apparaissent assez souvent après un arrêt accidentel. Puisque dansle passé ISAM a laissé sa place à MyISAM, nous nous attendions à ce que MARIAremplace MyISAM. Si vous suivez l’actualité de MySQL, vous savez que MARIAest désormais le moteur par défaut du projet MariaDB, une version alternative deMySQL. MARIA gère les transactions en utilisant MVCC et pose des verrous auniveau des lignes. La plupart des moteurs acceptant les transactions dans le mondeMySQL emploient le même algorithme. Sur MariaDB les tables système sont auformat Maria. À noter que derrière Maria et MariaDB se trouvent entre autresMonty (Widenius), un des fondateurs de MySQL.

Maria fonctionne en deux modes :1 amélioration de MyISAM ;2 transactionnel, MVCC.

PBXTUn des moteurs les plus en vue en ce moment est PrimeBase XT. Il a été conçu pourles environnements web à forte concurrence et utilise une architecture basée surl’écriture de fichiers de logs. Il a été écrit à l’origine par Paul McCullagh pour con-tourner des problèmes rencontrés dans le domaine de l’édition avec de gros volumesd’information stockés dans des BLOB. Il contient des algorithmes capables de tirerparti des disques SSD.

B http://forge.mysql.com/

B http://askmonty.org/wiki/index.php/MariaDB



Vous trouverez davantage d’informations sur http://www.primebase.com/xt/download/pbxt-uc-2008.pdf et http://www.linux-mag.com/cache/7462/1.html.

BLOB Streaming Engine (MyBS)MyBS devait être à l’origine une évolution de PBXT. Les deux moteurs étaient déve-loppés en parallèle par Primebase. L’architecture de MyBS a été modifié et transformedésormais MySQL en un serveur de médias capable de diffuser (streaming) images,films, mp3... et autres objets binaires (BLOBS) à partir de la base ou vers la base. Leprincipe consiste à stocker les métadonnées sur votre serveur MySQL et les donnéessur le Cloud. La dernière version utilise Amazon S3. Le client demande au serveur unedonnée et est redirigé sur l’enregistrement stocké sur S3.

MdbtoolsLe moteur Mdbtools permet de lire dans MySQL des données stockées sous MSAccess.

Figure 3–8Architecture générale du moteur PBXT

B http://www.primebase.org

B http://blobstreaming.org/



77

SolidDB pour MySQL est un moteur fourni par Solid, qui a été racheté par IBM, etbasé sur leur propre base de données SoliDB. À l’origine, solidDB fonctionne selondeux modes :1 base de données en mémoire ;2 base de données relationnelle.

Historiquement, il était utilisé comme base de données embarquée dans des équipe-ments de communication. Vous trouverez davantage d’informations sur http://www-01.ibm.com/software/data/soliddb/ et http://sourceforge.net/projects/soliddb/.

KickfireKickfire propose plus qu’un moteur de stockage. En effet, elle fournit également leserveur sur lequel va tourner leur moteur. Il est orienté datawarehouse.

TokuDBTokuDB est un nouveau venu qui incorpore la technologie fractale de Tokutek. Lesperformances affichées sont assez étonnantes. C’est un moteur à suivre.

SpiderSpider est l’un des derniers venus à surveiller de très près. Ce moteur est basé sur lecode de partitionnement des tables. Au lieu de stocker les données sur la machine,Spider permet de référencer les serveurs où se trouvent l’information recherchée. Ilexécute ensuite la requête sur le serveur distant et retourne le résultat. Il reste à testerla stabilité d’une telle solution qui pourrait être utile selon les applications.

B http://sourceforge.net/projects/mdbtools/

B http://www.kickfire.com/

B http://tokutek.com

B http://launchpad.net/spiderformysql



RethinkdbRethinkdb vient tout juste de sortir et se trouve encore en version pré-alpha. Il est censéêtre optimisé pour les disques SSD. Même s’il vaut la peine d’être mentionné, il estencore trop jeune pour en tirer des conclusions pertinentes.

Le monde des moteurs de stockage est assez vaste, même si au final, le modèle MVCCest assez récurrent. Perfectionnez-vous dans le moteur que vous utilisez actuellementpour être certain d’en avoir atteint les limites avant de choisir une alternative.

Les rachats successifs de MySQL par Sun puis de Sun par Oracle ont bouclé laboucle : MySQL et InnoDB se retrouvent désormais dans la même entreprise. Lemonde des moteurs n’a pas fini d’évoluer et l’avenir est plein de promesses à ce sujet !

B http://www.rethinkdb.com/

Tableau 3–2 Récapitulatif des moteurs MySQL

Société Moteur Verrou Transaction Site

Oracle/Innobase InnoDB ligne oui http://www.innodb.com/

MySQL AB MyISAM table non http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html

MySQL AB Merge table non http://dev.mysql.com/doc/refman/5.1/en/merge-storage-engine.html

MySQL AB Memory table non http://dev.mysql.com/doc/refman/5.1/en/memory-storage-engine.html

MySQL AB Archive ligne non http://dev.mysql.com/doc/refman/5.1/en/archive-storage-engine.html

Percona XtraDB ligne oui http://www.percona.com/

MySQL AB Falcon ligne oui http://dev.mysql.com/doc/falcon/en/index.html

MySQL AB Federated x x http://dev.mysql.com/doc/refman/5.1/en/federated-storage-engine.html

MySQL AB Example x x http://dev.mysql.com/doc/refman/5.1/en/example-storage-engine.html

MySQL AB Blackhole x x http://dev.mysql.com/doc/refman/5.1/en/blackhole-storage-engine.html

MySQL AB CSV table non http://dev.mysql.com/doc/refman/5.1/en/csv-storage-engine.html

MySQL AB IBMDB2I x x http://dev.mysql.com/doc/refman/5.1/en/se-db2.html



79

MySQL AB NDB ligne oui http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-overview.html

Monty Program Ab

Maria ligne oui/non, dépend du mode

http://askmonty.org/wiki/index.php/MariaDB

PrimeBase Systems GmbH

PBXT - PrimeBase XT

ligne oui http://www.primebase.org

PrimeBase Systems GmbH

PBMS - Blob Streaming

ligne oui http://www.blobstreaming.org/

Brian Burns (l’auteur)

Mdbtools table non http://sourceforge.net/projects/mdbtools/

IBM/Solid SolidDB ligne oui http://www-01.ibm.com/software/data/soliddb/

Kickfire Kickfire x x http://www.kickfire.com/

Tokutek TokuDB x x http://www.tokutek.com

ST Global Spider x x http://www.spiderformysql.com

Tableau 3–2 Récapitulatif des moteurs MySQL (suite)

Société Moteur Verrou Transaction Site



Un serveur MySQL utilise plusieurs centaines de variables dites système ou destatut. Elles reflètent respectivement la configuration et l’état du serveur. Ce chapitredécrypte les variables de statut et présente les différents outils de surveillance qui lesexploitent.

Qu’il soit dans l’urgence ou non, un administrateur de bases de données doit êtrecapable de prendre rapidement le pouls de la situation sur un serveur donné. Eneffet, lorsqu’un serveur MySQL rencontre un incident (surcharge, arrêt brutal, ralen-tissements, perte de connexion...), le DBA doit comprendre ce qui s’est passé, qu’ilait lui-même vécu le problème en direct ou pas. Cette enquête débute bien souventgrâce aux logs générés par le serveur MySQL et/ou le système d’exploitation.

Ces logs existent sous différentes formes : écrits sur disque en simples fichiers texte,insérés dans une table de la base, ou encore matérialisés en compteurs indiquant lasurvenue de tel ou tel événement.

Ce chapitre permet, d’une part, de comprendre quels types de variables le serveurMySQL utilise et comment il les emploie. Il présente, d’autre part, une sélection desdifférents outils de surveillance, qu’ils soient conçus par MySQL ou pas.

4Surveiller son serveur MySQL



Où trouver les informations pertinentes ?Le comportement d’un serveur MySQL se dessine avant même son démarrage autravers de son fichier de configuration couramment nommé my.cnf. Une fois enmarche, il est possible de contrôler l’état du serveur grâce à la consultation de sesvariables dites de statut.

Cette consultation peut s’effectuer de façon brute en accédant manuellement auxvaleurs de ces variables à l’aide d’un client MySQL ou de façon assistée par le biaisd’outils ou de scripts permettant une lecture plus rapide et ordonnée de ces centainesde valeurs.

Variables système et variables de statut

Les variables de statut sont à l’honneur dans ce chapitre. Elles constituent la sourceprincipale d’information des outils de surveillance que nous allons évoquer, qu’ilssoient fournis par MySQL ou soient le fruit de développements extérieurs.

Néanmoins, impossible d’évoquer ce type de variables sans revenir régulièrement auxvariables système. Ces dernières ont en effet bien souvent une influence sur les premières.

Un exemple : les performances des tables InnoDB sont très influencées par le para-mètre innodb_buffer_pool_size. Sa valeur agit sur une multitude de variables destatut relatives à InnoDB ou au serveur en général.

DÉFINITION Variables système ou de statut

On appelle variables système les valeurs retournées par la commande mysql > SHOW GLOBAL VARIABLES;

Les variables de statut s’obtiennent via mysql > SHOW GLOBAL STATUS;

Les variables système sont en lecture seule, on ne peut pas les modifier.Elles sont plusieurs centaines dans chaque catégorie (entre 200 et 300 occurrences).

ALTERNATIVE Récupérer les variables système ou de statut

Si vous préférez obtenir les informations issues de la commande mysql > SHOW GLOBALVARIABLES; sans lancer le client MySQL vous pouvez arriver à vos fins en une seule ligne en saisissantdirectement dans le shell :mysqladmin -u user -p password variables > /tmp/show_variables.txt

ou encore :mysql -u -p -e "SHOW GLOBAL VARIABLES;" > /tmp/show_variables.txt

Ceci fonctionne également avec la commande SHOW GLOBAL STATUS;.


Surveiller son serveur MySQLCHAPITRE 4

83

Les variables système sont détaillées dans le chapitre 8 consacré à l’optimisation duserveur MySQL. Nous nous concentrons ici sur la façon de contrôler le bon fonc-tionnement d’un serveur.

Quels outils choisir ?Il existe une multitude d’outils permettant de contrôler l’état d’un serveur MySQL.Nous pouvons les diviser en trois grandes catégories.• Les outils ou commandes fournis par MySQL, comme : SHOW INNODB STATUS,mysqladmin... Vous êtes, dans ce cas, certain de pouvoir en disposer sur toutes lesinstallations.

• Les outils système : iostat, vmstat, top... Ces outils non spécifiques à MySQLsont soit inclus dans le système d’exploitation, soit très couramment déployés.Leur comportement est à peu près le même selon les systèmes d’exploitation. Ilspermettent de mesurer l’impact de MySQL sur le serveur : utilisation des disques,des processeurs...

• Les outils externes : mysqlreport, la suite Maatkit, mytop, innotop... Ce sontsouvent des scripts Perl qu’il est nécessaire de télécharger sur les sites de leursauteurs sans oublier les éventuelles librairies (Perl) manquantes. Il n’y a aucunegarantie que ces scripts soient déployés sur vos machines de production : ce pointest donc à vérifier avant de compter dessus le jour J.

Hormis les outils système dont la vocation est plutôt de surveiller différentes métri-ques du système lui-même, les outils de surveillance spécifiques à MySQL reposentsur ses variables de statut. Dès lors, il est important de distinguer parmi les centainesde variables disponibles, quelles sont les grandes familles de ces variables les plus àmême de vous éclairer sur la situation d’un serveur.

À SAVOIR Variables système et my.cnf

Les variables système déterminent le comportement de votre serveur MySQL. Suivez ce lien pour une listeexhaustive (http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html). La portée (sessionseulement ou tout le serveur) et le caractère modifiable à chaud de chaque variable système sont indi-qués. C’est un lien à conserver en bonne place dans vos favoris MySQL. Il existe le même pour les varia-bles de statut...Toutes les variables système possèdent une valeur par défaut chargée au démarrage du serveur MySQL.Ces valeurs prédéfinies seront conservées par les variables sauf si ces valeurs sont redéfinies dans unfichier de configuration tel que le fameux my.cnf lors du démarrage du serveur. Une fois celui-cidémarré, toutes les variables qui ne sont pas en lecture seule peuvent être modifiées soit au niveau glo-bal (pour tout le serveur), soit au niveau de la session initiée par le client MySQL.



Pouvoir lire de façon brute quelques variables clés permet déjà de se faire une idée dece qui se passe sur un serveur. Il est ensuite plus aisé de comprendre le compte-rendugénéré par un script ou programme de surveillance. Cela permet en effet d’affiner lesrésultats, de les relativiser : une valeur peut paraître critique aux yeux d’un script desurveillance alors que c’est peut-être tout simplement le DBA (vous ?) qui avezdésactivé la mise en cache sur certaines requêtes, par exemple.

Intérêt des outils de surveillanceRapidité et automatisation sont les deux avantages des outils de surveillance.

Prenons un exemple très simple. Comment calculer l’efficacité du réglage de lavariable key_buffer_size ?

ATTENTION Une valeur peut en cacher une autre

Il ne suffit pas de lire les valeurs définies dans le fichier my.cnf d’un serveur MySQL pour être certaindu contenu d’une variable système.il y a deux raisons à cela :À condition de détenir le privilège SUPER, certaines variables sont redéfinissables à chaud via la com-mande SET GLOBAL, et peuvent donc avoir été modifiées depuis leur valeur initiale définie dansmy.cnf. Par exemple :SET GLOBAL sort_buffer_size=1000000 modifie à chaud pour l’ensemble du serveur lavariable sort_buffer_size.En ce qui concerne les variables dites read-only, autrement dit non modifiables à chaud, leurs valeurssont définies lors de la lecture initiale de my.cnf. Celui-ci a donc très bien pu évoluer depuis le(re)démarrage du serveur et ne plus refléter la véritable valeur d’une variable (cas d’une valeur modifiéedans my.cnf en prévision d’un redémarrage ultérieur).En conséquence, seule la commande :mysql > SHOW GLOBAL VARIABLES LIKE 'ma_variable';

renverra la valeur qui est actuellement prise en compte par votre serveur MySQL.Enfin, il est possible d’inclure des fichiers externes à my.cnf grâce à la fonction include ; n’oubliezpas de prendre en compte ce paramètre lors de la lecture d’un fichier de configuration :!include /home/mydir/myopt.cnf

À SAVOIR Différence entre un client et un outil MySQL

Ne pas confondre un client MySQL tel que mysql, mysqladmin... et un script/programme comme myisamchkpar exemple. Ce dernier vérifie et répare les tables MyISAM mais sans se connecter au serveur ; ce n’estdonc pas un client. Concernant myisamchk, il est conseillé de sauvegarder les tables concernées avant del’utiliser. De même un verrouillage de celles-ci ou une coupure du serveur MySQL pendant l’opération estfortement recommandé afin de ne pas corrompre les données.



85

La formule est la suivante :

le taux d’échec se mesurant de la sorte : key_reads / key_read_requests.

Autrement dit, on effectue le rapport entre le nombre de lectures disque d’un blocd’index sur le nombre de demandes de lectures du bloc d’index à partir du cache. Sitous les blocs demandés se trouvent déjà dans le cache, on obtient 0 et une efficacitéde 1 (cas idéal théorique).

La liste des variables de statut est longue : http://dev.mysql.com/doc/refman/5.1/en/server-status-variables.html. Pour vous y retrouver, vous pourriez apprendre par cœur les 300 lignes,ou les croiser manuellement entre elles afin de donner du sens à certaines. Tout celaest effectivement possible manuellement mais serait extrêmement fastidieux.

L’utilité de l’outil ou du script de surveillance qui vous convient est d’obtenir rapide-ment une photographie de l’état de votre serveur MySQL. Il est en effet hors dequestion d’effectuer des opérations manuelles que l’on soit en situation d’urgence ounon (un DBA n’a pas de temps à perdre).

Il existe de nombreux outils de diagnostic ou de surveillance dans la galaxie MySQL.Les plus efficaces sont ceux... que l’on connaît le mieux !

N’hésitez pas à en tester plusieurs et retenez ceux avec lesquels vous êtes le plus à l’aise.

Outils et commandes fournis par MySQLDe tous les scripts de surveillance ou outils que nous passerons en revue ultérieure-ment, la commande SHOW GLOBAL STATUS; est une des sources les plus importantesde remontée d’informations d’un serveur MySQL.

Cette commande, tout comme mysql > SHOW GLOBAL VARIABLES; pour les variablessystème, renvoie près de 300 lignes !

B.A.-BA key_buffer_size

key_buffer_size est l’une des variables serveur les plus importantes pour le moteur MyISAM. Ils’agit de la taille du cache des index. Notez qu’il est possible sous ce moteur de créer des caches d’indexdédiés pour une table.

efficacité = 1 - taux d’échec

mysql> SHOW GLOBAL STATUS\G*************************** 1. row Variable_name: Aborted_clients

Value: 5629



L’exemple du paragraphe précédent prend alors tout son sens : si on multiplie lesmêmes mécanismes de calcul pour toutes les autres variables clés à surveiller, le DBAy passerait ses journées !

Néanmoins, les grandes familles de variables listées par la commande SHOW GLOBALSTATUS permettent d’une part de comprendre d’où ces outils de surveillance tirentleurs informations, d’autre part d’être à même d’évaluer le fonctionnement d’un ser-veur en l’absence de ces outils.

*************************** 2. row Variable_name: Aborted_connects

Value: 3004375*************************** 3. row Variable_name: Binlog_cache_disk_use

Value: 3994[...]

ATTENTION Variables globales vs variables de session

mysql> SHOW GLOBAL STATUS affiche les variables de statut pour l’intégralité du serveur MySQL.mysql> SHOW [LOCAL, SESSION] STATUS affiche les variables de statut liées à la connexion.Prenez garde, certaines valeurs dont la portée est uniquement globale seront également présentes(Bytes_received, Bytes_sent, Connections...).Chargées au démarrage du serveur, les variables globales disposent toutes d’une valeur par défaut etsont redéfinies via les options passées en ligne de commandes à mysqld ou lors du chargement du fichierde configuration my.cnfLes variables de session sont propres aux connexions des clients. Le serveur gère donc à la fois des varia-bles globales, mais également des versions propres à chaque connexion d’un client.Le fichier de configuration my.cnf marque également cette distinction : il existe une section nommée[mysql] dédiée aux paramètres que l’on souhaite charger au démarrage du serveur pour les clientsmysql.Par exemple, si votre moteur de stockage par défaut est MyISAM sur le serveur MySQL, sans autre préci-sion de votre part, les tables seront créées sous ce moteur. Vous pouvez cependant définir dans votre ses-sion un autre moteur de stockage :set SESSION storage_engine = InnoDB;Toutes les tables créées lors de votre session seront désormais des tables InnoDB (sauf précision ulté-rieure de type CREATE TABLE... ENGINE=nom_du_moteur.Attention, il est déconseillé de ne pas spécifier explicitement le moteur de stockage lors de la créationdes tables et donc de se fier à la valeur de la variable storage_engine. En cas de changement decette dernière, votre code peut ne plus fonctionner aussi bien comme le montre Mark Callaghan dans cebillet : http://mysqlha.blogspot.com/2009/06/what-could-possibly-go-wrong.html



87

Sans reprendre les centaines de variables issues de la documentation, voici lesgrandes lignes à retenir produites par SHOW GLOBAL STATUS. Ce découpage s’inspirede celui effectué par MySQL dans son outil MySQL Administrator.

Nous vous invitons à télécharger cet outil gratuitement. Même s’il n’est pas exemptde défauts (impossible de trier des requêtes dans la vue « server connections » notam-ment), il est gratuit et peut s’avérer pratique. La partie que nous allons analyser con-tient la définition de chaque variable système ou de statut. Sans détailler les lignes dechaque catégorie, voici les variables de statut les plus importantes.

Catégorie GeneralOn retrouve dans cette catégorie des variables telles que :• uptime : peut confirmer le cas échéant qu’un serveur MySQL a redémarré récem-

ment.• open_tables, opened_tables et open_files : ces variables indiquent respective-

ment le nombre de tables actuellement ouvertes, le nombre de tables ouvertesdepuis le démarrage du serveur et enfin le nombre de fichiers actuellementouverts par MySQL.

opened_tables est à surveiller : plutôt que la valeur elle-même, c’est l’évolution decelle-ci qu’il faut observer. Une augmentation trop rapide est souvent caractéristiqued’un cache de table trop petit. Le premier réflexe est alors d’accroître le cache de

B http://dev.mysql.com/downloads/gui-tools/5.0.html

Figure 4–1L’arborescence des catégories que nous allons étudier est issue de l’outil MySQL Administrator.



table. La variable système correspondante se nomme table_open_cache (elle rem-place table_cache à partir de la version 5.1.3).

Attention néanmoins aux conséquences potentielles d’une telle modification. Modi-fier ce paramètre influence en effet le nombre de descripteurs de fichiers (file descrip-tors) requis par MySQL et en cela il est possible que le serveur MySQL (le processusmysqld) dépasse le nombre de descripteurs autorisé par processus, ce qui seraitpotentiellement désastreux pour le fonctionnement du serveur.

Récupération de la valeur de table_open_cache

Nous ne rentrerons pas dans le détail du fonctionnement du cache de table deMySQL ici mais il est conseillé de lire le lien figurant dans l’encadré « Deux descrip-teurs de fichiers pour une table MyISAM ».

En quelques mots, chaque connexion (threads_connected) nécessite un descripteurde fichier pour ouvrir une table sur le serveur. La variable système max_connectionspermet d’évaluer le nombre de descripteurs nécessaires au bon fonctionnement detoutes les connexions. On peut obtenir rapidement ce nombre en multipliantmax_connections par le nombre maximal de tables impliquées dans une requête pourun client donné.

À ce nombre, MySQL conseille de rajouter encore quelques descripteurs de fichierspour les tables temporaires et autres fichiers.

Une fois encore ces trois valeurs permettent de se rendre compte de la corrélationentre variables système et variables de statut : table_open_cache (variable système)est à rapprocher de max_connections (variable système). Toutes les deux influencentopened_tables (variable de statut).

mysql> SHOW GLOBAL VARIABLES LIKE 'table_open_cache';+------------------+-------+| Variable_name | Value |+------------------+-------+| table_open_cache | 64 | +------------------+-------+

B.A.-BA MySQL vs mysqld

mysql désigne le client MySQL, autrement dit le logiciel qui vous permet d’interroger le serveur MySQL.Il en existe d’autres tels que SQLYog, MySQL Query Browser, MySQL Administrator...mysqld désigne le serveur MySQL lui-même ; c’est le programme auquel sont rattachés bases, tables,moteurs de stockage...



89

La catégorie General contient deux sous-catégories : la première concerne lesthreads, la seconde les fichiers ou tables créés par MySQL.

Retrouver soi-même les variables listées par MySQL Administrator est un jeud’enfant ; par exemple :

Retenons ici que threads_connected correspond au nombre de clients connectés auserveur, à ne pas confondre avec Connections qui affiche le nombre de connexions,réussies ou non, au serveur.

Une valeur de threads_created importante doit être surveillée et doit amener à lavérification de la variable thread_cache_size. On constate une fois encore les liensqui unissent variables système, autrement dit la configuration du serveur et les varia-bles statut reflétant son comportement en production.

LE SAVIEZ-VOUS Deux descripteurs de fichiers pour une table MyISAM

À la première ouverture d’une table MyISAM, celle-ci nécessite deux descripteurs de fichiers : un pour lefichier de data (.MYD), et un autre pour le fichier d’index (.MYI) qui sera par la suite partagé entre lesthreads.La documentation consacre un chapitre aux mécanismes de cache de tables utilisés par MySQL.B http://dev.mysql.com/doc/refman/5.1/en/table-cache.htm

mysql> SHOW GLOBAL STATUS LIKE 'thread%';+-------------------+-------+| Variable_name | Value |+-------------------+-------+| threads_cached | 516 || threads_connected | 40 || threads_created | 556 || threads_running | 7 |+-------------------+-------+

ASTUCE Les jokers dans les commandes MySQL : % et _

Il est possible d’interroger l’ensemble des variables système ou de statut en utilisant des jokers de type% ou _, comme dans SHOW STATUS like 'handler%';.Ajoutons enfin que la casse n’est pas prise en compte.



Un moyen de récupérer les variables globales dont le nom contient 'tmp'

Retenez que le serveur MySQL crée des tables temporaires en mémoire(Created_tmp_tables) et s’en sert comme d’un tampon, notamment lorsqu’il ne peutpas faire autrement pour répondre à un critère de tri d’une requête. C’est le caslorsque MySQL ne trouve pas d’index utiles, ou par exemple lorsqu’une commandeGROUP BY est suivie d’une instruction ORDER BY dans un ordre différent... Dans cesdeux cas, la création d’une table temporaire est systématique. Il est donc possible deles faire disparaître en retravaillant la requête ou les index.

Une autre possibilité, à manier avec précaution, consiste à déporter le tri du côté dulangage de programmation utilisé. Si votre serveur MySQL est sous-dimensionné,cette technique pourrait lui redonner quelques couleurs. Il convient dans ce cas desurveiller le temps d’exécution du côté de l’application ainsi que la consommationmémoire éventuelle du script concerné.

Basée sur le même principe, la variable Created_tmp_disk_tables représente lenombre de tables temporaires créées sur disque, ce qui est plus pénalisant...

Le serveur MySQL bascule sur ce type de tables lorsque la taille de la table enmémoire nécessaire pour stocker les données temporaires est supérieure à la pluspetite des deux variables tmp_table_size et max_heap_table_size.

La présence d’un champ de type TEXT ou BLOB est également une source de tablestemporaires puisque ces deux types ne sont pas gérés par une table en mémoire. Dansla mesure du possible utilisez plutôt VARCHAR que le type TEXT.

Vérification de la valeur actuelle de ces deux variables système

mysql> SHOW GLOBAL STATUS LIKE '%tmp%';+-------------------------+----------+| Variable_name | Value |+-------------------------+----------+| Created_tmp_disk_tables | 261038 || Created_tmp_files | 58436 || Created_tmp_tables | 13628778 |+-------------------------+----------+

mysql> SHOW GLOBAL VARIABLES LIKE '%table_size%';+---------------------+----------+| Variable_name | Value |+---------------------+----------+| max_heap_table_size | 16777216 || tmp_table_size | 67108864 |+---------------------+----------+



91

Catégorie PerformanceParmi les variables disposées sous cette catégorie et hors rubriques, on trouveslow_queries.

Il est important de jeter un œil sur cette valeur qui comptabilise le nombre derequêtes plus lentes que le temps défini dans long_query_time (variable système,10 s par défaut).

La catégorie Performance est celle qui contient le plus de rubriques. Passons en revuequelques variables clés de chacune d’entre elles.

Query Cache

Récupération des variables système liées au Query Cache

La variable long_query_time sera davantage détaillée au chapitre 6 traitant de l’optimisation duserveur MySQL.

mysql> show global status like '%qcache%';+-------------------------+-----------+| Variable_name | Value |+-------------------------+-----------+| Qcache_free_blocks | 2865 || Qcache_free_memory | 9596608 || Qcache_hits | 147068034 || Qcache_inserts | 198631901 || Qcache_lowmem_prunes | 81279868 || Qcache_not_cached | 163335569 || Qcache_queries_in_cache | 18398 || Qcache_total_blocks | 40199 |+-------------------------+-----------+

À SAVOIR Le cache de requête (Query Cache )

Sensible à la casse, ce cache contient la liste des requêtes SELECT déjà envoyées au serveur MySQLqu’il est possible de mettre en cache. Leurs résultats associés sont également stockés, évitant ainsi auserveur des phases de parsing et d’exécution superflues si la requête est déjà connue... et toujoursvalide ! En effet, un résultat est exclu du cache si une des tables associées à ce résultat a été modifiée.Ce cache est particulièrement utile lorsque plusieurs requêtes identiques sont envoyées au serveurMySQL mais peut s’avérer pénalisant si chaque requête est unique.Il est possible de désactiver le cache sur une requête en particulier, par exemple à des fins de tests deperformance, via la commande suivante SELECT SQL_NO_CACHE...Pour plus de détails, consultez le chapitre 7 sur l’optimisation du serveur ou la page dédiée dans ladocumentation : B http://dev.mysql.com/doc/refman/5.1/en/query-cache.html



La variable Qcache_queries_in_cache permet de connaître le nombre de requêtesdans le cache. Ceci permet par exemple de calculer la taille moyenne d’une requêtemise en cache :

La variable Qcache_lowmem_prunes compte le nombre de requêtes retirées du cachepar manque de mémoire. Le résultat est à corréler cependant avecQcache_free_blocks ; s’il reste des blocs disponibles, c’est probablement un cachefragmenté qui empêche les requêtes d’y trouver leur place. La commande FLUSHQUERY CACHE est alors tout indiquée (elle n’efface pas les requêtes déjà présentescomme son nom le laisse croire ; RESET QUERY CACHE, en revanche, les efface).

Keys

Variables de statut liées aux index

Ces valeurs sont relatives au cache d’index des tables MyISAM uniquement. Queretenir de cette sélection ? Encore une fois, il est difficile d’un premier coup d’œild’évaluer rapidement ces variables et notamment l’efficacité du cache d’index.

taille_moyenne = (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache

(Qcache_hits / (Qcache_hits + Com_select) x 100422782474 / (422782474 + 56297674) = 88%

mysql> SHOW GLOBAL STATUS LIKE 'key%';+------------------------+-----------+| Variable_name | Value |+------------------------+-----------+| key_blocks_not_flushed | 0 || key_blocks_unused | 854277 || key_blocks_used | 103003 || key_read_requests | 265624122 || key_reads | 161845 || key_write_requests | 25943325 || key_writes | 872968 |+------------------------+-----------+

Figure 4–2Pourcentage d’utilisation du Query Cache et indication de la consommation actuelle du key_buffer par MyISAM



93

MySQL Administrator dispose d’une interface beaucoup plus visuelle (MemoryHealth) qui indique visuellement l’efficacité du cache d’index pour MyISAM ainsique le pourcentage de mémoire utilisé sur le total alloué pour ce cache.

Ces valeurs sont calculées de la façon suivante :

soit ici : 99,939 %.

À l’inverse, le cache miss rate peut être calculé par la formule key_reads/key_read_requests où key_reads correspond au nombre de lectures disque d’unbloc d’index.

Il est possible de surveiller cette valeur par paliers successifs via quelques mises à jourde l’affichage dans MySQL Administrator ou encore de manière plus automatiséeavec mysqladmin : mysqladmin -u -p ex -i 15 -r > stats.txt

Si la variation de key_reads se rapproche des performances maximales du disques(100 à 200 lectures aléatoires par seconde), il est grand temps de jeter un œil aukey_buffer_size.

Variables système liées aux index

Le pourcentage approximatif de mémoire utilisé se calcule de la sorte :

Ce qui donnerait ici : 18,5 % environ.

efficacité du cache : 100 - ((key_reads x 100) / key_read_request)

mysql> SHOW GLOBAL VARIABLES LIKE 'key%';+--------------------------+------------+| Variable_name | Value |+--------------------------+------------+| key_buffer_size | 1073741824 || key_cache_age_threshold | 300 || key_cache_block_size | 1024 || key_cache_division_limit | 100 |+--------------------------+------------+

(1 - ((key_blocks_unused × key_cache_block_size) / key_buffer_size) x 100)

RAPPEL Le cache MyISAM

Concernant le moteur de stockage MyISAM, MySQL ne gère que le cache d’index ; les données sontmises en cache par le système d’exploitation (consultez le chapitre 3 dédié aux moteurs de stockage). Lesvariables exposées dans cette partie sont relatives au cache d’index dont la taille est définie par la varia-ble système key_buffer_size, une des valeurs les plus importantes concernant la configuration deMyISAM sur un serveur MySQL.



Sort

Récupération des variables liées aux tris similaires à celles affichées par MySQL Administrator

Notez l’utilisation de l’instruction GLOBAL. La raison est simple : ces variables existentà la fois au niveau de la session et du serveur. Sans ce mot-clé, ce sont les variablesdéfinies lors de la session qui seraient affichées par défaut.

Inutile de les connaître par cœur. Encore une fois, toutes ces variables et leurs attri-buts sont définis sur le site de MySQL.

À SAVOIR Ajuster la taille du cache d’index

Outre MySQL Administrator qui permet de visualiser l’utilisation du cache d’index sous MyISAM graphi-quement, voici deux autres méthodes.La première est une commande shell à exécuter lorsque vous vous trouvez dans le datadir mysql> SHOW GLOBAL VARIABLES LIKE 'datadir';shell> du -sch `find . -name "*.MYI"`[...]233M total

La seconde, basée sur une requête SQL :mysql> SELECT SUM(index_length/1024/1024) FROM information_schema.tablesWHERE engine='MyISAM';+-----------------------------+| sum(index_length/1024/1024) |+-----------------------------+| 230.54296875 | +-----------------------------+

Rapprocher 230 Mo donc des 233 Mo obtenus par la commande précédente : les résultats sont assezproches (mais pas identiques : les valeurs stockées en mémoire n’occupent pas exactement la mêmeplace que sur disques) et permettent d’évaluer la taille du key_buffer_size.

mysql> SHOW GLOBAL STATUS LIKE 'sort_%';+-------------------+-----------+| Variable_name | Value |+-------------------+-----------+| sort_merge_passes | 353 || sort_range | 37748001 || sort_rows | 394227305 || sort_scan | 15437066 |+-------------------+-----------+

RAPPEL

En ce qui concerne les variables de statut, vous en trouverez la définition à l’adresse :B http://dev.mysql.com/doc/refman/5.1/en/server-status-variables.html



95

De manière générale, pour être certain de bien afficher ce que l’on souhaite, autantutiliser SHOW GLOBAL STATUS lorsqu’on recherche les variables serveur.

Surveillez la variable sort_merge_passes : si celle-ci est élevée et en forte progres-sion, la variable système correspondante, sort_buffer_size, est à augmenter.

Delayed

La catégorie Delayed, de moindre importance, est relative au nombre d’INSERTDELAYED effectués par le serveur MySQL. Les commandes INSERT DELAYED permet-tent à un client MySQL de ne pas attendre la disponibilité d’une table dans laquelleil souhaite insérer des nouvelles données avant d’effectuer d’autres instructions detype SELECT, par exemple. Les instructions INSERT sont regroupées dans un bufferqui sera écrit sur disque lorsque la table sera de nouveau disponible.

Nous vous conseillons de lire la documentation relative à cette commande. Il est néces-saire de peser avantages et inconvénients puisque des pertes de données sont possiblesen cas d’arrêt brutal du processus mysqld : la mémoire tampon serait alors perdue.

La documentation MySQL concernant les commandes INSERT DELAYED :

Selects

Consultez également le chapitre 6 consacré à l’optimisation de votre serveur MySQL.

mysql> SHOW GLOBAL STATUS LIKE '%Delayed_%';+--------------------------+-------+| Variable_name | Value |+--------------------------+-------+| Delayed_errors | 0 || Delayed_insert_threads | 0 || Delayed_writes | 0 || Not_flushed_delayed_rows | 0 |+--------------------------+-------+

B http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html

mysql> SHOW GLOBAL STATUS LIKE 'select%'; +------------------------+----------+| Variable_name | Value |+------------------------+----------+| Select_full_join | 14473330 | | Select_full_range_join | 41920 | | Select_range | 6869008 |



Encore une fois, veillez à bien distinguer les valeurs du serveur dans sa globalité etcelles liées à votre session. L’intérêt d’opérer cette distinction est par exemple de pou-voir isoler les statistiques provenant de sa session lorsqu’on passe des requêtes, plutôtque de tenter d’isoler ses actions (session) parmi celles effectuées sur le serveur.

La variable de statut select_full_join est à surveiller particulièrement. Il s’agit d’unejointure sans condition entre deux tables, ce qui peut s’avérer très coûteux : un parcourségal au produit cartésien du nombre de lignes des tables concernées sera exécuté.

Afin de calculer le pourcentage de ces commandes SELECT très lourdes par rapport aunombre total d’instructions SELECT effectuées, on peut employer la méthode suivante :

Effectuez ensuite :

Sur ce serveur, on obtient 9,2 % ce qui commence à faire beaucoup. Un petit passagesur les slow queries permettrait sans doute d’améliorer les choses.

MySQL Administrator ne permet pas d’effectuer ce calcul automatiquement ; enrevanche mysqlreport, détaillé plus loin dans ce chapitre, est capable d’afficher desstatistiques telles que celles-ci :

Statistiques d’utilisation sur la commande SELECT et les tris

On retrouve le nombre de select_full_join, leur fréquence et leur pourcentage parrapport au nombre de SELECT global, soit 0.14 %.

| Select_range_check | 256 | | Select_scan | 31011598 | +------------------------+----------+

mysql> SHOW GLOBAL STATUS LIKE 'Com_Select%';+---------------+-----------+| Variable_name | Value |+---------------+-----------+| Com_select | 157412518 |+---------------+-----------+

(Select_full_join / Com_select) * 100

SELECT and Sort _____________________________________________________Scan 6.46M 4.6/s %SELECT: 4.20Range 6.83M 4.9/s 4.44Full join 212.23k 0.2/s 0.14



97

Locks

Nous disposons du nombre de verrous qui ont pu être acquis immédiatement ou quiau contraire ont été posés après une attente.

Si la variable table_locks_waited est importante au regard de ceux qui ont pu êtreposés immédiatement, c’est un bon indice qui doit vous orienter vers les slow queries.Ici le ratio n’est pas alarmant.

InnoDB

Dans la version 1.2.17 de MySQL Administrator, ce ne sont pas ces valeurs qui sontaffichées... lorsqu’elles le sont ! En effet, en fonction de la version de MySQL devotre serveur, MySQL Administrator est susceptible de ne rien afficher du tout ; unbogue est ouvert à ce sujet.

Retenons donc les variables ci-dessus, accessibles via n’importe quel autre client.

Concernant les quelques lignes affichées par la commande ci-dessus, sans entrer dansle détail de chacune d’elles, on peut retenir ici que la totalité de l’espace attribué aubuffer pool d’InnoDB est consommée (Innodb_buffer_pool_pages_free = 0), ce

mysql> SHOW GLOBAL STATUS LIKE 'table_lock%';+-----------------------+-----------+| Variable_name | Value |+-----------------------+-----------+| Table_locks_immediate | 403979893 || Table_locks_waited | 79 |+-----------------------+-----------+

mysql> SHOW GLOBAL STATUS LIKE 'innodb_buffer%';+-----------------------------------+--------------+| Variable_name | Value |+-----------------------------------+--------------+| Innodb_buffer_pool_pages_data | 692405 | | Innodb_buffer_pool_pages_dirty | 63 | | Innodb_buffer_pool_pages_flushed | 17094665 | | Innodb_buffer_pool_pages_free | 0 | | Innodb_buffer_pool_pages_misc | 94027 | | Innodb_buffer_pool_pages_total | 786432 | | Innodb_buffer_pool_read_ahead_rnd | 707828 | | Innodb_buffer_pool_read_ahead_seq | 988583 | | Innodb_buffer_pool_read_requests | 755385349808 | | Innodb_buffer_pool_reads | 18501017 | | Innodb_buffer_pool_wait_free | 0 | | Innodb_buffer_pool_write_requests | 1820141551 | +-----------------------------------+--------------+



qui signifie que l’on possède très probablement plus de données que de mémoirevive. Cela n’est pas forcément un problème en soi, si le jeu de données avec lequel ontravaille est en mémoire.

Il est plus important de connaître la proportion de lectures qui ont besoin d’inter-roger les disques (Innodb_buffer_pool_reads) par rapport au nombre global de lec-tures reçues par InnoDB (Innodb_buffer_pool_read_requests). Ce pourcentage estobtenu par le calcul suivant :

Il est parfois pratique de réaliser ce calcul en ligne de commandes directement sousMySQL.

Utilisation d’un client MySQL pour y effectuer un calcul

Ici, le taux de lectures interrogeant les disques est très faible ! Avec un si faible tauxde lectures s’effectuant sur disque, on peut considérer que la taille du buffer pool estsuffisante pour les applications reposant sur InnoDB et fonctionnant sur ce serveur.Il est même possible de réduire sa taille si besoin, en diminuant progressivement lavaleur de innodb_buffer_pool_size tout en effectuant ce même calcul régulière-ment sur quelques heures ou quelques jours afin de vérifier que l’efficacité du bufferpool ne baisse pas dramatiquement (hit rate).

Rendez-vous au chapitre concernant l’optimisation de votre serveur MySQL pourd’autres détails concernant les réglages d’InnoDB.

Networking

Hors de ses rubriques Traffic et Replication, cette catégorie contient quatre varia-bles.

Récupération des variables affichées par MySQL Administrator pour la catégorie Networking

(Innodb_buffer_pool_reads x 100) / Innodb_buffer_pool_read_requests

mysql> SELECT (18501017*100)/755385349808\G*************************** 1. row (18501017*100)/755385349808: 0.0024

mysql> SHOW GLOBAL STATUS LIKE 'aborted%';+------------------+---------+| Variable_name | Value |+------------------+---------+| Aborted_clients | 5640 | | Aborted_connects | 3081369 |



99

Quelques mots sur les deux premières variables. Aborted_clients/

Aborted_connects : comme son nom l’indique, la première variable comptabilise lenombre de clients qui se sont déconnectés brutalement sans passer par la commandemysql_close(), par exemple. Le second recense les tentatives échouées de connexionau serveur MySQL.

Un nombre important de commandes aborted_connect peut provenir de vos propresoutils de surveillance (ou de ceux de votre hébergeur). Un load balancer testant si vosmachines sont toujours disponibles puis coupant la connexion une fois son testeffectué (parfois chaque seconde), est susceptible d’incrémenter ce compteur.

La documentation MySQL détaille plusieurs scénarios liés à ces erreurs à l’adressesuivante : http://dev.mysql.com/doc/refman/5.1/en/communication-errors.html

mysql> SHOW GLOBAL STATUS LIKE 'Connections';+---------------+----------+| Variable_name | Value |+---------------+----------+| Connections | 49672922 | +---------------+----------+

mysql> SHOW GLOBAL STATUS LIKE 'max_used_connections';+----------------------+-------+| Variable_name | Value |+----------------------+-------+| Max_used_connections | 392 | +----------------------+-------+

ATTENTION Sortir un serveur client de la liste noire d’un serveur MySQL

Par défaut, le serveur MySQL bloque un serveur au bout de 10 connexions infructueuses. En casd’urgence la commande FLUSH HOSTS ou mysqladmin flush-hosts lèvera le blocage. Il estcependant nécessaire d’analyser le problème afin de remonter jusqu’à sa cause. La documentation est unbon point de départ : http://dev.mysql.com/doc/refman/5.1/en/blocked-host.html

À SAVOIR Droits nécessaires aux commandes SHOW STATUS et SHOW VARIABLES

Vous pouvez accéder aux commandes SHOW STATUS et SHOW VARIABLES avec simplement le privi-lège USAGE (simple droit de se connecter). Dès lors que vous avez un compte mysql validé sur le serveurà étudier, vous êtes certain de pouvoir au moins exécuter ces deux commandes.Les droits pour un utilisateur se définissent grâce à la commande GRANT. Pour visualiser l’ensemble devos droits, effectuez : mysql > SHOW GRANTS;Attention : les droits se définissent pour un utilisateur associé à un domaine. Consultez le chapitre 7 surla configuration serveur pour une explication détaillée de la gestion des droits utilisateurs.



Donnons rapidement quelques mots sur les rubriques restantes.

Variables liées à la rubrique traffic

Ces deux valeurs sont explicites : somme des données reçues par l’ensemble desclients et quantité de données envoyées par le serveur MySQL à tous les clients.

Quelques variables liées à la réplication et notamment au statut de l’esclave

Rien de vraiment notable ici. Il est plus utile d’effectuer une commande SHOW SLAVESTATUS\G qu’une vérification sur slave_running pour contrôler l’état d’un esclave.

Récupération des variables affichées dans la rubrique Commands Executed de MySQL Administrator

mysql> SHOW GLOBAL STATUS LIKE 'bytes_%';+----------------+---------------+| Variable_name | Value |+----------------+---------------+| Bytes_received | 732927533019 || Bytes_sent | 1642267367588 |+----------------+---------------+

mysql> SHOW GLOBAL STATUS LIKE 'slave%';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Slave_open_temp_tables | 0 || Slave_retried_transactions | 258 || Slave_running | ON |+----------------------------+-------+

mysql> show global status like 'Com%';+---------------------------+-----------+| Variable_name | Value |+---------------------------+-----------+| Com_admin_commands | 7739 || Com_assign_to_keycache | 0 || Com_alter_db | 5 || Com_alter_db_upgrade | 0 |[...]| Com_alter_table | 4069 |[...]



101

Très nombreuses, ces variables sont des compteurs de chaque commande SQL effec-tuées sur le serveur MySQL. Réparties en différentes sous-rubriques dont DDL(Data Definition Language) et DML (Data Manipulation Language), ces statistiquespermettent de se rendre compte de l’importance de telle ou telle commande. Hélas,pas de calcul de pourcentage (exemple : les commandes SELECT représentent x % dela somme des DML). Cependant, nous verrons que ce type d’information se retrouvedans d’autres outils de surveillance, tel que mysqlreport.

Connaître la répartition des lectures et écritures sur son système est importantlorsque vous souhaitez optimiser les performances. 80 % d’écritures et 20 % de lec-tures, ou au contraire 20 % d’écritures contre 80 % de lectures, correspondent à desimpacts bien différents sur les serveurs concernés. Les solutions à apporter sur de telssystèmes face à une montée en charge sont elles aussi à adapter en fonction de cetterépartition.

La variable Com% détaille le nombre de requêtes reçues par le serveur classées par type(SELECT, ALTER, INSERT). Exemple pour le SELECT :

Attention, dans ce cas, seules les commandes SELECT qui ne sont pas dans le cache etréellement exécutées par le serveur sont prises en compte.

De manière générale, consulter la documentation dès lors qu’une variable est digned’intérêt est une bonne façon de procéder : comprendre leur comportement nécessiteparfois des précisions techniques pas forcément intuitives au premier abord. C’est cequi arrive avec une instruction SELECT dont le résultat se trouve dans le cache. Dans cecas, c’est la variable Qcache_hits qui sera incrémentée au lieu de Com_select.

mysql> SHOW GLOBAL STATUS LIKE 'Com_select';+---------------+----------+| Variable_name | Value |+---------------+----------+| Com_select | 80666609 |+---------------+----------+

mysql> SHOW GLOBAL STATUS LIKE 'Qcache_hits';+---------------+-----------+| Variable_name | Value |+---------------+-----------+| Qcache_hits | 205196094 |+---------------+-----------+



Miscellaneous

Sans entrer dans la définition de chacune de ces variables, handler_read_rnd ethandler_read_rnd_next sont à surveiller. Elles indiquent en effet des lacunes probablesdans l’indexation et trop de scans complets des tables. Une fois encore, pour détecter cestendances les scripts de surveillance sont bien plus adaptés qu’un calcul manuel.

Néanmoins, il est possible d’isoler dans la série des handlers les handler_read. Cesderniers renseignent sur l’utilisation des index par MySQL. Difficiles à lire dans leurensemble via un SHOW GLOBAL, ces valeurs sont beaucoup plus utiles lorsqu’elles sontrelatives à une session. Elles permettent alors d’analyser précisément une requête,suivant une autre approche que la commande EXPLAIN. On entre alors dans ledomaine du profiling de requêtes.

Voici un rapide exemple avec la base sakila (téléchargeable sur http://dev.mysql.com/doc/).On commence par réinitialiser les variables de statut liées à sa session :

Utilisation des variables de statut liées à la session et non globales au serveur à des fins d’analyse

mysql> SHOW GLOBAL STATUS LIKE 'handler_read%%';+-----------------------+--------------+| Variable_name | Value |+-----------------------+--------------+| Handler_read_first | 17557719 || Handler_read_key | 127655210333 || Handler_read_next | 122489059588 || Handler_read_prev | 34039587805 || Handler_read_rnd | 1828016718 || Handler_read_rnd_next | 164134891327 |+-----------------------+--------------+|[...]

mysql> FLUSH STATUS;

mysql> EXPLAIN SELECT SQL_NO_CACHE a.first_name, a.last_name, f.title FROM actor a INNER JOIN film_actor fa USING (actor_id) INNER JOIN film f USING (film_id) ORDER BY f.title LIMIT 10\G*************************** 1. row ***************************

id: 1 select_type: SIMPLE

table: f type: index

possible_keys: PRIMARY key: idx_title

key_len: 767 ref: NULL



103

Ces valeurs sont propres à la session en cours, ce qui permet d’évaluer l’évolution desvariables surveillées selon ses requêtes.

À utiliser également :• SHOW STATUS LIKE 'SELECT%';

• SHOW STATUS LIKE 'SORT%';

• SHOW STATUS LIKE 'created_tmp%';

rows: 5 Extra: Using index

*************************** 2. row *************************** id: 1

select_type: SIMPLE table: fa type: ref

possible_keys: PRIMARY,idx_fk_film_id key: idx_fk_film_id

key_len: 2 ref: sakila.f.film_id

rows: 2 Extra: Using index

*************************** 3. row *************************** id: 1

select_type: SIMPLE table: a type: eq_ref

possible_keys: PRIMARY key: PRIMARY

key_len: 2 ref: sakila.fa.actor_id

rows: 1 Extra:

3 rows in set (0.00 sec)

mysql> SHOW STATUS LIKE 'handler_read%';+-----------------------+-------+| Variable_name | Value |+-----------------------+-------+| Handler_read_first | 1 || Handler_read_key | 15 || Handler_read_next | 9 || Handler_read_prev | 0 || Handler_read_rnd | 0 || Handler_read_rnd_next | 0 |+-----------------------+-------+



Autre utilité de ce type de variables : il est possible, sous certaines conditions,d’estimer le temps d’exécution d’une requête en analysant l’évolution dehandler_read_rnd_next. Un article décrivant cette manipulation se trouve àl’adresse : http://www.mysqlperformanceblog.com/2008/04/22/

La commande SHOW ENGINE INNODB STATUSSHOW ENGINE INNODB STATUS, commande plus couramment utilisée sous le raccourciSHOW INNODB STATUS (obsolète mais toujours fonctionnel), permet d’obtenir rapide-ment une vue globale du moteur de stockage InnoDB sur un serveur MySQL.

Au programme, des informations sur les contentions au sein même du code sourced’InnoDB (rubrique semaphores) mais également des informations plus accessiblesconcernant les DEADLOCKS, les clés étrangères, les transactions, le buffer pool, etc.

Afin de visualiser ces informations, il suffit d’exécuter la commande SHOW ENGINEINNODB STATUS au sein d’un client MySQL. Il est également possible d’indiquer auserveur MySQL que l’on souhaite inscrire le résultat de cette commande vers lasortie standard dédiée aux erreurs (stderr), en pratique le fichier de log d’erreurstoutes les 15 secondes.

Pour désactiver ce processus, il suffit de supprimer la table par l’instruction classiqueDROP TABLE.

À noter qu’il s’agit dans ce cas du Standard Monitor and Lock Monitor, pourreprendre la dénomination précise utilisée par MySQL. Celle-ci est nécessaire car ilexiste par ailleurs un Tablespace Monitor ainsi qu’un Table Monitor. Ces deux der-niers ne seront pas étudiés ici mais leur utilisation est détaillée dans la documentationMySQL : http://dev.mysql.com/doc/refman/5.1/en/innodb-monitors.html

Nous allons analyser l’essentiel d’un SHOW ENGINE INNODB STATUS, dont voici les dif-férentes sections.

ASTUCE Optimiser et analyser une requête avec USE INDEX/IGNORE INDEX

Pour entrer dans le détail du profiling d’une requête, outre l’indispensable EXPLAIN, il est possibled’utiliser la commande FLUSH STATUS/SHOW STATUS LIKE... en parallèle des MySQL hints, àsavoir des commandes spéciales telles que USE INDEX, IGNORE INDEX ou SQL_NO_CACHE, quipermettent d’orienter le comportement de l’optimiseur MySQL. Désactiver un index sur une requête a unimpact sur les variables de statut. Il est donc possible de mener des tests poussés et de comprendre ainsice qu’effectue MySQL.

CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;



105

Information d’en-tête

Cette première section indique simplement l’heure à laquelle cette photographie del’état d’InnoDB a été prise. Une bonne pratique est de vérifier que la durée surlaquelle ont été établies les statistiques présentées est suffisante pour obtenir desrésultats significatifs.

59 secondes, comme dans cet exemple, semblent suffisantes. Essayez d’obtenir desrésultats recueillis sur au moins 20 secondes. Quelques essais successifs sont néanmoinsparfois nécessaires pour arriver à obtenir des moyennes de plus de 10 secondes : eneffet, vous ne maîtrisez pas le moment où ces statistiques sont réinitialisées.

Information sur les sémaphores

Section pointue concernant l’activité des threads, les informations délivrées ici sontdifficiles à interpréter du premier coup d’œil. Il s’agit de statistiques concernant laproportion de threads consommant des cycles processeur (spins) en attendant depouvoir accéder à une ressource. Au-delà d’un nombre de cycles défini par la variableinnodb_sync_spin_loops (20 par défaut), le thread est suspendu et l’attente estdésormais gérée par le système d’exploitation. Celui-ci opère un context switch (chan-gement de contexte et sauvegarde du contexte suspendu) et exécute un autre thread.

Selon l’activité de votre serveur cette rubrique peut également contenir des informationssupplémentaires sur d’éventuels points de blocage, comme dans l’extrait ci-dessous.

mysql> SHOW ENGINE INNODB STATUS\G*************************** 1. row *************************** Type: InnoDB Name:

Status: =====================================091018 14:08:34 INNODB MONITOR OUTPUT=====================================Per second averages calculated from the last 59 seconds

----------SEMAPHORES----------OS WAIT ARRAY INFO: reservation count 1877627232, signal count 1590319303Mutex spin waits 0, rounds 297103334422, OS waits 1220510239RW-shared spins 294569924, OS waits 35432718; RW-excl spins 1711817825, OS waits 32784412



Dans la section sémaphores, InnoDB indique sur quelle partie du code source se trouve la contention.

Une liste de threads est alors affichée avec le mutex responsable de leur présence danscette liste. Le thread ci-dessus attend qu’un verrou du fichier trx0purge.c se libère.Une information plutôt difficile à analyser, à moins d’examiner le code source etd’analyser le problème... Ce qui pourrait là encore prendre un certain temps.

Une approche plus rapide consiste à tenter de comprendre à quelles catégories appar-tiennent les mutex. Soumettre à un moteur de recherche le nom du fichier source danslequel se trouve le mutex permet bien souvent de restreindre la zone du problème.

Il s’agit en l’occurrence d’un problème probablement relatif aux mécanismes de purgemis en œuvre par InnoDB et notamment de la variable innodb_max_purge_lag surlaquelle il serait bon d’effectuer quelques tests. Les noms des mutex sont parfois suffi-samment explicites, comme buf0buf.ic qui concerne une contention du buffer pool.

Une longue liste de threads bloqués par des mutex n’est pas bon signe et est caracté-ristique de goulets d’étranglement soit au niveau des disques, d’InnoDB lui-même (ilest possible d’agir sur la variable innodb_thread_concurrency pour réduire cettecontention), soit encore sur la gestion des threads par le système d’exploitation.

Les clés étrangères

Cette section est une aide précieuse pour qui souhaite rapidement constater si desproblèmes existent autour des contraintes posées sur certaines tables.

--Thread 1170168160 has waited at ../../storage/innobase/include/sync0rw.ic line 360 for 0.00 seconds the semaphore:Mutex at 0x2aab0b09e900 created file trx/trx0purge.c line 212, lock var 0waiters flag 0[...]

À SAVOIR Différence entre mutex et sémaphores

Un mutex est utilisé pour restreindre l’accès à une ressource partagée, par exemple un bout de codesource, par un thread au plus à la fois. Un sémaphore permet de restreindre l’accès à une ressource à uncertain nombre de threads simultanément. Autrement dit un sémaphore qui restreint l’accès à un seulthread est un mutex.La recherche suivante, à effectuer sur votre moteur de recherche préféré, permet de comprendre très...concrètement cette différence « Mutex vs Semaphore, the toilet example » !

------------------------LATEST FOREIGN KEY ERROR------------------------091005 17:48:06 Transaction:



107

Cette partie est plutôt explicite et permet facilement d’identifier des erreurs parfoissilencieuses concernant la gestion des clés étrangères. SHOW INNODB STATUS est alorsun très bon moyen de comprendre, par exemple, pourquoi une insertion n’a pas pus’effectuer. Ce type d’erreur doit être remonté par l’administrateur de bases de don-nées aux équipes de développement s’il s’avère que le souci est applicatif.

Les deadlocks

Exemple de deadlock ou verrou infini résolu par InnoDB en annulant une des deux transactions impliquées

TRANSACTION 0 663601494, ACTIVE 0 sec, process no 14626, OS thread id 1205045600 inserting, thread declared inside InnoDB 500mysql tables in use 1, locked 15 lock struct(s), heap size 1216, 2 row lock(s), undo log entries 1MySQL thread id 64847939, query id 959410328 localhost user updateINSERT INTO ABO_SERV (NUM_ABO,CODE_SERVICE,...) VALUES ('1234','5678',...)Foreign key constraint fails for table `base1`.ÀBO_SERV`:, CONSTRAINT ÀS_ibfk_8` FOREIGN KEY (`CODE_SERVICE`) REFERENCES `DS`

(`CODE_SERVICE`) ON UPDATE CASCADETrying to add in child table, in index ÌNDEX_CODE_SERVICE` tuple:DATA TUPLE: 2 fields;[...]

------------------------LATEST DETECTED DEADLOCK------------------------030709 12:59:58*** (1) TRANSACTION:TRANSACTION 0 290252780, ACTIVE 1 sec, process no 3185, OS thread id 30733insertingLOCK WAIT 3 lock struct(s), heap size 320, undo log entries 146MySQL thread id 21, query id 4553379 localhost heikki updateINSERT INTO alex1 VALUES(86, 86, 794,'aA35818','bb','c79166','d4766t','e187358f','g84586','h794',date_format('2001-04-03 12:54:22','%Y-%m-%d%H:%i'),7*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 indexsymbole trx id 0 290252780 lock mode S waitingRecord lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138;asc aa35818;; 1:*** (2) TRANSACTION:TRANSACTION 0 290251546, ACTIVE 2 sec, process no 3190, OS thread id 32782



Ce paragraphe facultatif (il n’apparaît qu’en cas de deadlock) permet d’identifier lesproblèmes de deadlock : il s’agit de deux transactions qui s’attendent mutuellementet où l’une d’elle sera annulée par InnoDB. Cet exemple provient de la documenta-tion MySQL.

La transaction annulée est souvent celle qui verrouille le plus de lignes. Il peut égale-ment s’agir d’une transaction qui en attend une autre... mais trop longtemps. Pardéfaut cette variable, innodb_lock_wait_timeout, a une valeur de 50 secondes, cequi devrait convenir la plupart du temps.

Plutôt que de penser à doubler cette valeur, il est conseillé d’étudier la transaction quiest attendue, analyser la ou les requêtes la composant, peut-être un SELECT trop lent...Bref d’optimiser la requête à l’aide d’EXPLAIN notamment afin de détecter rapide-

inserting130 lock struct(s), heap size 11584, undo log entries 437MySQL thread id 23, query id 4554396 localhost heikki updateREPLACE INTO alex1 VALUES(NULL, 32, NULL,'aa3572','','c3572','d6012t','',NULL,'h396', NULL, NULL, 7.31,7.31,7.31,200)*** (2) HOLDS THE LOCK(S):RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 indexsymbole trx id 0 290251546 lock_mode X locks rec but not gapRecord lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138;asc aa35818;; 1:*** (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 indexsymbole trx id 0 290251546 lock_mode X locks gap before rec insert intentionwaitingRecord lock, heap no 82 RECORD: info bits 0 0: len 7; hex 61613335373230;asc aa35720;; 1:*** WE ROLL BACK TRANSACTION (1)

ASTUCE Créer un deadlock délibéré

La commande SHOW ENGINE INNODB STATUS exécutée en ligne de commandes (à la différence deson écriture dans le fichier d’erreurs) dispose d’un affichage limité à 64 Ko. Lorsqu’un deadlock importantse produit, il est susceptible de publier via cette commande trop d’informations pour le buffer de 64 Ko ;il est alors impossible de lire les sections suivantes du SHOW ENGINE INNODB STATUS. Pour remé-dier à ce problème et si vous avez identifié le deadlock, il est possible de créer un deadlock délibéré sim-plement pour effacer le précédent (seul le dernier est conservé en mémoire).Baron Schwartz décrit la manipulation sur son blog : http://www.xaprb.com/blog/2006/08/08/Il est également possible d’utiliser InnoTop, un outil du même auteur.



109

ment si le plan d’exécution indique qu’un index serait éventuellement le bienvenu.Une transaction exécutée sur un serveur esclave qui attend trop longtemps peut pro-voquer l’arrêt de la réplication...

Le MVCC

La section des transactions renseigne sur l’état du mécanisme de purge d’InnoDB et indique les verrous éventuels

Les trois premières lignes renseignent sur l’état du mécanisme de purge d’InnoDBconcernant le MVCC. Avec un tel système, chaque transaction ne voit que sa propreversion des données, c’est la lettre I de la norme ACID (atomicité, cohérence, isola-tion, durabilité). La contrepartie de ce système est qu’InnoDB doit conserver l’inté-gralité des enregistrements d’une table tant que toutes les transactions n’en ont pasterminé avec eux.

Autrement dit, même un enregistrement dont la suppression est effectuée (COMMIT)n’est pas forcément réellement effacé de la table. Il se peut en effet que cet enregistre-ment ait des liens avec d’autres transactions dont les résultats seraient impactés, deuxlectures successives de la table en question ne donnant pas les mêmes résultats parexemple (dirty reads, phantom reads...). Ces mécanismes dépendent du niveau d’iso-lation d’InnoDB (par défaut REPEATABLE READ).

------------TRANSACTIONS------------Trx id counter 0 1433572342Purge done for trx's n:o < 0 1433571830 undo n:o < 0 0History list length 6

LIST OF TRANSACTIONS FOR EACH SESSION:---TRANSACTION 0 0, not started, process no 24720, OS thread id 1184811360MySQL thread id 49776520, query id 2483480984 localhost user1show engine INNODB STATUS---TRANSACTION 0 0, not started, process no 24720, OS thread id 1192532320MySQL thread id 49776544, query id 2483462446 localhost user2---TRANSACTION 0 1433571828, not started, process no 24720, OS thread id 1171499360MySQL thread id 2434784, query id 2483477073 Has read all relay log; waiting for the slave I/O thread to update it[...]

À LIRE ÉGALEMENT Le MVCC

La notion de MVCC est détaillée au chapitre 3 consacré aux moteurs de stockage.



La première ligne indique en quelque sorte l’identifiant unique de la dernièretransaction ; on peut comparer cela à la valeur d’une clé primaire en auto-incrément.

La deuxième ligne indique que le mécanisme de purge des anciennes lignes modi-fiées est à jour jusqu’à l’identifiant de transaction 1433571830. On peut donc endéduire en soustrayant les deux valeurs, que 512 identifiants restent à purger. Afin delimiter l’expansion de ce nombre, une bonne pratique consiste à ne pas laisser ouverteinutilement une transaction mais à effectuer l’instruction COMMIT au plus tôt.

Le mécanisme de purge affecte également la valeur de la dernière ligne de l’en-tête :il s’agit du nombre de transactions non purgées dans la zone undo des fichiers dedonnées d’InnoDB.

Suit une liste de transactions en cours. Pour chacune d’entre elles un état (notstarted, active...) est affiché. Dans l’exemple ci-dessus, il est plus clair de se référerà la commande mysql> SHOW FULL PROCESSLIST;.

Cependant certaines entrées de cette liste sont parfois plus bavardes (souvent en casde forte charge), par exemple :

Le MVCC permet à chaque transaction d’obtenir sa propre vue des données (en fonction du degré d’isolation défini dans InnoDB)

La dernière ligne nous apprend que cette transaction, du fait du MVCC évoqué pré-cédemment, ne verra pas les modifications potentielles apportées aux enregistre-ments par les transactions dont l’identifiant est supérieur au sien (ce qui est logique).Information intéressante, il existe plus de 50 000 identifiants de transaction en rela-tion avec cette transaction, ce qui est énorme. Cet exemple provient d’un systèmeconfronté à de gros problèmes de contentions au sein d’InnoDB.

I/O

---TRANSACTION 0 663702920, ACTIVE 23 sec, process no 14626, OS thread id 1239923040MySQL thread id 64957572, query id 960138174 localhost 192.168.10.1 my_userTrx read view will not see trx with id >= 0 663702921, sees < 0 663650722

--------FILE I/O--------I/O thread 0 state: waiting for i/o request (insert buffer thread)I/O thread 1 state: waiting for i/o request (log thread)I/O thread 2 state: waiting for i/o request (read thread)I/O thread 3 state: waiting for i/o request (write thread)Pending normal aio reads: 0, aio writes: 0,ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0



111

Si l’une des quatre premières lignes n’est pas en attente (waiting) c’est qu’il existe ungoulet d’étranglement au niveau du thread concerné (écriture dans le tablespace à partirdu buffer d’insertion, les flushs asynchrones des logs, mécanisme de read-aheadd’InnoDB (consultez le chapitre 2 consacré au matériel) ou pour le dernier thread, leflush des buffers dits dirty, modifiés en mémoire mais pas encore sur disques.

Notez également que la ligne Pending flushes (fsync) log: 0; buffer pool: 0 indiquel’activité du log buffer et du buffer pool. Quelques autres statistiques suivent, calculées parseconde et sur le laps de temps écoulé et figurant au tout début de la commande SHOWENGINE INNODB STATUS; : Per second averages calculated from the last 59 seconds.

INSERT BUFFER AND ADAPTIVE HASH INDEX

Un adaptive hash index est une tentative d’InnoDB d’optimiser une recherche par indexsur une table susceptible de tenir en mémoire. La transformation consiste à passer d’unindex B-TREE à celui d’un hash index plus rapide à parcourir (vous trouverez plus dedétails sur l’un de nos articles en ligne : http://www.dbnewz.com/2008/05/19/).

La quatrième ligne permet de mesurer l’efficacité des hash index ; dans cet exemple,InnoDB les utilise environ 2,5 fois plus souvent que le parcours d’un B-tree.

Ce processus de choix est automatique. Cette section a donc un but informatifuniquement ; ceci est également valable pour le buffer d’insertion.

Les logs de transactions

Pending flushes (fsync) log: 0; buffer pool: 029078727 OS file reads, 270066897 OS file writes, 5161540 OS fsyncs1.12 reads/s, 16384 avg bytes/read, 5.92 writes/s, 1.60 fsyncs/s

-------------------------------------INSERT BUFFER AND ADAPTIVE HASH INDEX-------------------------------------Ibuf: size 1, free list len 5493, seg size 5495,12071862 inserts, 12078750 merged recs, 2386492 mergesHash table size 25499819, node heap has 81971 buffer(s)48717.97 hash searches/s, 18252.11 non-hash searches/s

---LOG---Log sequence number 75 2845856081Log flushed up to 75 2845855633Last checkpoint at 75 28456887450 pending log writes, 0 pending chkp writes405283217 log i/o's done, 6.75 log i/o's/second



Ces cinq lignes concernent la gestion des fichiers de log de transactions.

On peut tirer des deux premières lignes que seuls (2845856081-2845855633)/1024 =0,4375 Ko n’ont pas été placés sur disque.

Le dernier checkpoint (dernier point de sauvegarde exploitable en quelque sorte) sesitue à une distance de (2845855633-2845688745)/1024 = 162,98 Ko.

Le buffer pool et la mémoire

Les informations consacrées au buffer pool

Cette section permet d’un coup d’œil d’obtenir quelques informations intéressantes àpropos du buffer pool, élément crucial pour InnoDB.

Le buffer pool n’a plus de place disponible. Il sera néanmoins capable de contenir auprix de lectures disque d’éventuels nouveaux enregistrements. Ceci étant dit, son tauxd’efficacité est excellent. Nous avions déjà évoqué une autre méthode dans ce cha-pitre pour le calculer grâce aux variables de statut Innodb_buffer_pool_reads etInnodb_buffer_pool_read_requests.

Nous apprenons également que le buffer pool contient 604 pages modifiées enmémoire. Celles-ci sont dites dirty car les modifications apportées n’ont pas encoreété écrites sur disque.

Statistiques sur le moteur InnoDB

----------------------BUFFER POOL AND MEMORY----------------------Total memory allocated 14319368562; in additional pool allocated 1048576Dictionary memory allocated 7955472Buffer pool size 786432Free buffers 0Database pages 686045Modified db pages 604Pending reads 0Pending writes: LRU 0, flush list 0, single page 0Pages read 24671168, created 1866207, written 365006402.55 reads/s, 0.05 creates/s, 11.35 writes/sBuffer pool hit rate 1000 / 1000

--------------ROW OPERATIONS--------------0 queries inside InnoDB, 0 queries in queue1 read views open inside InnoDB



113

La première ligne de cette dernière section indique le nombre de threads actuelle-ment traités par InnoDB (limité par innodb_thread_concurrency) ainsi que lenombre de threads attendant à leur tour d’accéder à l’intérieur du moteur.

Extrait montrant une activité beaucoup plus soutenue de ce point de vue

Issues d’un serveur saturé, ces deux lignes montrent la limite imposée à InnoDB, viaun réglage de la variable innodb_thread_concurrency = 8, et une forte activitépuisque 79 threads sont dans la file d’attente.

De plus, 83 vues ou snapshots en lecture sont en cours au sein d’InnoDB. Cela con-cerne les vues dont dispose chaque transaction sur les données qu’elles gèrent grâceau système de MVCC. Ces vues ont bien sûr un coût et font souffrir le système quidoit garder en mémoire davantage de données.

La dernière ligne de cette section permet d’obtenir la répartition de l’activitéd’InnoDB en termes de lectures ou écritures (insertions, suppressions, mises à jour).

D’autres informations concernant la commande SHOW ENGINE INNODB STATUS setrouvent dans la documentation MySQL : http://dev.mysql.com/doc/refman/5.1/en/innodb-moni-tors.html

INFORMATION_SCHEMAOutre les commandes classiques SHOW GLOBAL VARIABLES; et SHOW GLOBAL STATUS;,il est également possible de profiter de la base information_schema afin d’obtenir lesinformations relatives aux variables de sessions ou globales au serveur.

Main thread process no. 24720, id 1140881760, state: sleepingNumber of rows inserted 105920506, updated 212285505, deleted 15281146, read 5758880028630.56 inserts/s, 0.88 updates/s, 0.00 deletes/s, 83686.01 reads/s----------------------------END OF INNODB MONITOR OUTPUT============================

8 queries inside InnoDB, 79 queries in queue83 read views open inside InnoDB

mysql> SELECT variable_name, variable_value FROM information_schema.GLOBAL_STATUS ORDER BY variable_name;+-----------------------------------+----------------+| variable_name | variable_value |+-----------------------------------+----------------+| ABORTED_CLIENTS | 0 |



Il est également possible d’obtenir les mêmes informations qu’avec la commandeSHOW ENGINES par ce biais :

La base information_schema recèle une large palette d’informations susceptibles devous intéresser : http://dev.mysql.com/doc/refman/5.1/en/information-schema.html

Connaître et savoir exploiter les outils de surveillanceConnaître le fonctionnement des variables système et de statut d’un serveur MySQL estindispensable... mais insuffisant. Une étude plus poussée nécessite une analyse plus com-plète du système (matériel et système d’exploitation). C’est en maîtrisant parfaitementvotre environnement et ses outils que vous pourrez identifier les goulets d’étranglement.

Les goulets pour une base de données sont souvent issus des I/O disques. En effet, lalecture de données sur un disque est une action mécanique et prend donc beaucoupplus de temps qu’une lecture en mémoire.

| ABORTED_CONNECTS | 0 || BINLOG_CACHE_DISK_USE | 0 || BINLOG_CACHE_USE | 0 |

mysql> SELECT * FROM information_schema.ENGINES\G*************************** 1. row ***************************

ENGINE: InnoDB SUPPORT: YES COMMENT: Supports transactions, row-level locking, and foreign keys

TRANSACTIONS: YES XA: YES

SAVEPOINTS: YES*************************** 2. row ***************************

ENGINE: MRG_MYISAM SUPPORT: YES COMMENT: Collection of identical MyISAM tables

TRANSACTIONS: NO XA: NO

SAVEPOINTS: NO*************************** 3. row ***************************

ENGINE: BLACKHOLE SUPPORT: YES COMMENT: /dev/null storage engine (anything you write to it

disappears)TRANSACTIONS: NO

XA: NO SAVEPOINTS: NO

[...]



115

La mémoire vive (RAM) est également une ressource cruciale. Un serveur qui pos-sède davantage de données à exploiter que de mémoire vive risque d’utiliser sonfichier d’échange (swap) et donc d’augmenter les I/O.

Autre zone de ralentissement, la contention au niveau des processeurs (CPU). Plu-sieurs processeurs travaillant de concert signifient également plusieurs threads enparallèle accédant à des ressources partagées. Pour éviter que ces même ressourcessoient utilisées en même temps, MySQL utilise des mutex (Mutal exclusion). Onappelle ce mécanisme une primitive de synchronisation. Différentes implémenta-tions sont possibles. Si tous les threads veulent accéder au même mutex, une conten-tion apparaît au niveau des threads et donc au niveau des processeurs. Dans le mêmeregistre, on évoque parfois les sémaphores, sorte de mutex avec un compteur.

Enfin, les I/O de l’interface réseau sont eux aussi susceptibles d’avoir un impact surles performances du système.

Qu’est-ce que la performance ?La définition de la performance varie selon le type d’activité. Pour une base de don-nées, la performance est mesurée en temps et en nombre de requêtes.

Quelle quantité de données la base va-t-elle être capable de retourner dans unminimum de temps ? La notion de temps étant la base de cette évaluation, il estnécessaire de garder en mémoire certains repères (source : Jeff Dean gave at a Engi-neering All-Hands Meeting at Google) :• poser ou enlever un verrou sur un Mutex : 100 ns ;• envoyer 2 Ko sur un réseau Ethernet à 1 Go : 20 000 ns ;• lire 1 Mo séquentiel en mémoire : 250 000 ns ;• lire 1 Mo séquentiellement sur le réseau : 10 000 000 ns ;• lire 1 Mo séquentiellement sur un dique dur : 30 000 000 ns ;• un déplacement sur le disque dur (disk seek) : 10 000 000 ns ;• envoyer un paquet IP de Californie en Hollande et retour en Californie :

150 000 000 ns.

En gardant ces chiffres en tête, il n’y a pas de doute que MySQL répondra plus rapide-ment à une requête SQL en lisant les informations en mémoire plutôt que sur le disque.

Pourtant, l’étape du disque est encore indispensable aujourd’hui.

Une base de données transactionnelle (comme MySQL + InnoDB) doit à la foisécrire les données, gérer les transactions ainsi que leurs potentielles annulations(ROLLBACK) ; il s’agit dans ce cas des données modifiées par un ordre SQL non validépar une instruction COMMIT. Lire sur le disque entraîne le déplacement de la tête delecture et augmente les temps d’accès.



Afin de faciliter la montée en charge ultérieure de votre système, il est souhaitable d’étu-dier dès le début la façon de gérer les écritures afin d’éviter les contentions à ce niveau.

En effet, lorsqu’un thread écrit une donnée, comme un enregistrement dans une tableavec un système est ACID, les mises à jour sont appliquées sur les éléments suivants :• la page qui stocke la table ;• le log de transactions ;• le log binaire (s’il est activé).

Afin d’accéder à toutes ces ressources, MySQL utilise des mutex. Si tous les threadsaccèdent aux mêmes mutex, les performances se dégradent.

InnoDB souffre lui aussi de ce problème et il est courant de voir les performances sedégrader sur des systèmes multiprocesseurs (à partir de huit cœurs en général).

En conséquence, il faut absolument pouvoir paralléliser les écritures si l’on souhaiteatteindre de meilleures performances. Des solutions ont été implémentées par InnoDBet son plug-in 1.0.4 et par MySQL à partir de la version 5.4 (encore en bêta).

Pour résumer, si le temps d’accès d’un disque (disk seek) est de 10 ms, nous pourronsau maximum effectuer 100 recherches par seconde (1 s/10 ms). Ceci dépend évidem-ment de la taille des données et de la façon dont elles sont écrites sur le disque (con-tinue ou non).

Pendant cette même seconde, il est possible de lire 4 Go en mémoire (1 Mo séquen-tiel en mémoire, 1 s/250 000 ns), ce qui donne pour 1 Mo environ 4 000 fetch/s(4 000 lectures en mémoire).

Voici ce qu’on peut en déduire :• une écriture est 40 fois plus coûteuse qu’une lecture (100 seek vs 4 000 fetch).

100 seek signifie 100 recherches sur le disque ; nous sommes limités par le dépla-cement la tête de lecture ;

• partager des données est coûteux ;• le temps d’accès d’une lecture en mémoire est déjà 120 fois plus rapide que sur un

disque (250 000 ns vs 30 000 000 ns).

À LIRE Technologie du disque

Rendez-vous au chapitre 2 consacré au matériel pour de plus amples détails sur les mécanismes liés àl’utilisation d’un disque.



117

LVM : la gestion des volumes logiquesAvant d’analyser plus en détail une étude de cas reposant sur un serveur MySQL, ilest utile de décrire les mécanismes du LVM. En effet, lors d’une phase d’audit oud’optimisation MySQL, vous êtes susceptible de rencontrer voire de mettre en placevous-même ce type de système.

La gestion par volumes logiques LVM (logical volume management), est une façon degérer son espace de stockage.

Elle offre beaucoup de flexibilité et de confort pour agrandir à chaud les partitions oupour les diminuer. Il est possible de différencier les entités suivantes.• Les volumes physiques (PV) sont au choix des disques durs, des partitions de dis-

ques durs, des volumes RAID ou des unités logiques provenant d’un SAN.• Les groupes de volumes (VG) réunissent les volumes physiques.• Les volumes logiques (LV) sont découpés dans les groupes de volumes, puis for-

matés et montés dans des systèmes de fichiers ou utilisés en tant que raw devices.

Le gros avantage pour les bases de données d’un tel système est la possibilité deprendre des clichés (snapshots), un LV permettant d’effectuer une sauvegarde cohé-rente d’un autre volume logique du même groupe de volumes. La création d’unsnapshot consiste à prendre une photo, un instantané du volume logique cible (ce quiest quasi-immédiat). Il est alors possible de commencer à enregistrer les modifica-tions apportées au volume logique cible.

La légère perte en performance due au rajout d’une couche logique entre système etmatériel est largement acceptable par rapport à la flexibilité apportée.

Figure 4–3Architecture LVM



L’avantage devient évident lorsque nous pensons à certaines méthodes de sauvegarded’une base MySQL. Si nous souhaitons effectuer une sauvegarde physique (nonlogique) de MySQL, il faut arrêter le serveur (sauvegarde à froid) et effectuer unecopie des données (cp, rsync, tar) sur un autre disque. Tant que la copie n’est pasterminée, le serveur n’est pas disponible. Cette méthode est nécessaire lorsqu’on uti-lise InnoDB sans outils particuliers tels que InnoDB Hot Backup ou Xtradb Backup.

Avec MyISAM, en revanche, il est possible d’utiliser mysqlhotcopy qui verrouille enlecture seule la base pendant que la copie des fichiers est effectuée en local sur le ser-veur (pas de copie distante).

Utiliser un snapshot permet de bloquer le serveur MySQL pour un minimum detemps. Une fois la photo prise, il est possible de redémarrer le serveur et de réaliser lacopie en tâche de fond. Il va de soi que l’impact sur le système de stockage est tou-jours présent puisqu’il faut bien effectuer la copie des données. Cependant la base dedonnées n’aura connu qu’un temps d’arrêt très court.

Les snapshots ne sont pas des sauvegardes complètes d’un volume logique. Ils enre-gistrent uniquement les modifications apportées au volume cible et ne contiennentpas les données de celui-ci. De plus, ils ne sont pas persistants, c’est-à-dire qu’ils dis-paraissent en cas de redémarrage de la machine. L’espace libre que vous devez laisserdans le groupe de volumes (VG) pour prendre des snapshots dépend essentiellementde l’activité en écriture sur le volume logique cible pendant la durée de vie de cesnapshot. Encore une fois, le snapshot ne stocke que la différence ; plus la différenceest grande, plus elle prend d’espace. Pour une base MySQL, 15 à 20 % du LV à sau-vegarder est suffisant.

JARGON Transactionnel et cohérence, quelles différences ?

Une transaction est une opération informatique cohérente qui peut être composée d’une ou plusieurstâches. Cette opération est valide si toutes les tâches ont été effectuées (elle est validée par une actiondite de COMMIT). Si elle ne l’est pas vous devez revenir dans l’état original (ROLLBACK). Une transac-tion doit répondre dans la plupart des cas à ces quatre règles :• Atomicité : ensemble de requêtes indivisibles (tout ou rien).• Cohérence : la transaction ne doit pas violer de contraintes d’intégrité pendant son exécution. Elle doit

laisser la base de données dans un état cohérent. Dans le cas contraire elle doit être annulée et signalée.• Isolation : une transaction t1 ne doit pas être perturbée par t2 si t2 n’est pas encore validée. Avec

MySQL la plupart des moteurs de stockage utilise le modèle MVCC pour cela.• Durabilité : une fois la transaction terminée et quel que soit son état (COMMIT / ROLLBACK), il faut

assurer que l’action a bien été prise en compte. Dans le monde des bases de données on parle alors delogs de transactions (transaction log, redo log...).

Dans le cas de la lecture d’un enregistrement, il faut être sûr de lire la bonne valeur (cohérence) maisnous ne modifions aucun élément. Pour un SGBD, nous différencions aussi les verrous en lecture et enécriture.



119

Quelques commandes utiles :• pour les PV : pvcreate, pvscan, pvs, pvdisplay, pvremove, pvmove, pvchange• pour les VG : vgcreate, vgdisplay, vgscan, vgs, vgck, vgremove• pour les LV : lvcreate, lvmdiskscan, lvs, lvdisplay, lvremove, lvextend

Voici la méthode pour effectuer une sauvegarde à froid de MySQL dans un contexteLVM :1 Arrêtez MySQL.2 Avec lvcreate -LxxxM -s snapname /dev/vgname/lvname créez un cliché de

xxx Mo du LV lvname dans le VG vgname.3 Démarrez MySQL.4 Effectuez la sauvegarde des données.5 Avec lvremove /dev/vgname/snapname détruisez le cliché.

Il existe également une possibilité d’effectuer une sauvegarde sans arrêter le serveurMySQL. Il s’agit de verrouiller les tables en lecture, la sauvegarde est alors dite tiède(warm) :• FLUSH TABLES WITH READ LOCK pose un verrou en lecture ; peut prendre du temps

si de lourdes opérations sont déjà en cours.• lvcreate -LxxxM -s snapname /dev/vgname/lvname crée un cliché de xxx MB

du LV lvname dans le VG vgname.• UNLOCK TABLES débloque les tables.

Attention : cette commande bloque l’écriture des tables. Cependant, avec InnodBpar exemple, elle n’influence pas les tâches de fond du moteur. Il est donc possible,une fois votre sauvegarde restaurée, que InnoDB démarre en mode recovery.

B.A.-BA Les différents types de sauvegardes (backups)

• Backup à froid : arrêt du serveur MySQL, aucune connexion à la base n’est possible.• Backup à chaud : le serveur MySQL continue son activité (InnoDB Hot Backup/tradbbackup),

les applications continuent à se connecter, à exécuter des requêtes...• Backup tiède (warm) : toutes les tables sont bloquées, l’application continue à se connecter, en revan-

che aucune requête sur les tables en question ne peut être exécutée.• Backup logique : opéré à l’aide de mysqldump, par exemple. Toutes les commandes SQL permettant de

restaurer la base sont générées. C’est un backup à chaud.• Backup physique : copie des données (tar, LVM...).



En conclusion, voici un petit récapitulatif sur les LVM.

Concernant les avantages des volumes logiques (LV) :• possibilité de répartir des LV sur un ensemble de volumes physiques (similaire au

RAID 0) ;• dupliquer (mirroring) des LV (similaire au RAID 1) ;• faire des clichés (snapshots) ;• changement d’un disque défectueux possible ;• augmentation de la taille d’une partition à chaud ;• réduction la taille d’une partition possible.

Attention : un cliché n’est pas une sauvegarde complète d’un LV. Il enregistre uni-quement les modifications apportées.

Les problèmes :• avec l’implémentation actuelle, des corruptions peuvent arriver même sur des sys-

tèmes journalisés comme ext3 ou xfs ;• si les morceaux physiques de la couche de stockage ne sont pas continus, le serveur

peut souffrir de fragmentation externe affectant directement les performances.

Pour approfondir, voici un point d’entrée intéressant : http://www.tldp.org/HOWTO/LVM-HOWTO/.

Étude de cas : analyse d’un serveur MySQLJusqu’à maintenant, nous obtenions des informations à partir du serveur MySQLlui-même. Il s’agit notamment de la récupération des valeurs de certaines variablessystème ou de statut. Comment aller plus loin et en savoir davantage ?

Voici la marche à suivre, tirée d’un serveur réel nommé ici mysql1.

Quel est le système d’exploitation ?

Le serveur fonctionne donc sous Linux 64 bits.

Obtenir la distribution de sa machine

[borghino@mysql1 ~]$ uname -aLinux mysql1 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

[borghino@mysql1 ~]$ cat /etc/redhat-releaseRed Hat Enterprise Linux AS release 4 (Nahant Update 8)



121

Nombre de processeurs disponibles

Cette commande fournit des informations sur le nombre de cœurs de chacun des pro-cesseurs. Ici, un quatre cœurs Intel® Xeon® CPU L5320 qui tourne à 1,86 GHz. Il estainsi possible de vérifier si le processeur est en 64 bits. Cette information est importante,comme cela est exposé au chapitre 2 consacré au matériel. Il n’est pas impossible decroiser un serveur 64 bits utilisant un système d’exploitation ou une instance MySQL en32 bits. Pour mémoire, un système 32 bits limite la mémoire virtuelle à 4 Go.

Quantité de mémoire vive disponible

Détecter les périphériques

Lorsqu’un système Linux démarre, le noyau (kernel) est chargé en mémoire. Poursimplifier, on peut considérer que le système détecte alors tous les périphériques pré-sents et un message de diagnostic est produit. En utilisant dmesg (display message), ilest possible de vérifier son matériel.

Quelques informations susceptibles d’être affichées suite à cette commande et leurcorrespondance :• SCSI device sda : présence de disques SCSI ;• sda: sda1 sda2 : 2 volumes sont présents ;• EXT3-fs : le système de fichier utilisé est EXT3 ;• scsi0 : LSI Logic SAS based MegaRAID driver : technologie RAID utilisée ;• md: Autodetecting RAID arrays ;• eth0: Broadcom NetXtreme II BCM5708 1000Base-T : la carte réseau est du giga

Ethernet.

Cette recherche d’information est un peu fastidieuse sous cette forme. Heureuse-ment, il existe des utilitaires qui permettent de récupérer directement ces élémentssans avoir à se rappeler tous les noms de fichiers de configuration.

Prenons par exemple lshw. Cet outil affiche la configuration exacte de la mémoire,du firmware, de la carte mère, des processeurs, du cache...

[borghino@mysql1 ~]$ cat /proc/cpuinfo

[borghino@mysql1 ~]$ cat /proc/meminfoMemTotal: 8165320 kB

[borghino@mysql1 ~]$ dmesg



Installation de l’utilitaire lshw

Une fois exécuté, lshw permet d’afficher ce type d’informations :

La lecture de la configuration est ainsi facilitée : nous sommes ici en présence desix disques montés en RAID 10.

Récupérer les informations relatives à l’espace disque

[borghino@mysql1 proc]$ yum install lshw[borghino@mysql1 proc]$ lshw -short[borghino@mysql1 proc]$ lshw -class memory

System: Dell PowerEdge 2950Processors: 1 x Xeon L5320 1.86GHz 1066MHz FSB (4 cores) 64-bitMemory: 8GB (4 x 2) 667MHz DDR2Disk: sda (megaraid_sas0): 438GB (0%) RAID-10/3 == 6 x 146GB 15K SAS/3Disk-Control: megaraid_sas0: PERC 5/i,

[borghino@mysql1 ~]$ mount/dev/mapper/sys-root on / type ext3 (rw,noatime)/dev/mapper/sys-tmp on /tmp type ext3 (rw,noatime)/dev/mapper/sys-var on /var type ext3 (rw,noatime)...[borghino@mysql1 ~]$ df -kh/dev/mapper/sys-root 3.9G 1.4G 2.3G 38% //dev/mapper/sys-tmp 3.9G 40M 3.7G 2% /tmp/dev/mapper/sys-var 279G 1.6G 266G 1% /var...[borghino@mysql1 proc]$ sudo pvsPV VG Fmt Attr PSize PFree/dev/sda2 sys lvm2 a- 408.11G 25.65G1 volume physique sda2 utilisant LVM2 qui fait 400 Go

[borghino@mysql1 proc]$ sudo vgsVG #PV #LV #SN Attr VSize VFreesys 1 6 0 wz--n- 408.11G 25.65G1 groupe de volumes réparti sur 1 volume physique qui comporte 6 volumes logiques

[borghino@mysql1 proc]$ sudo lvsLV VG Attr LSize Origin Snap% Move Log Copy% Convertvar sys -wi-ao 283.00Gmysql sys -wi-ao 80.00Groot sys -wi-ao 3.91Gswap sys -wi-ao 7.75Gtmp sys -wi-ao 3.91Gles 5 volumes logiques.



123

Il est très important de vérifier la configuration RAID de votre machine. En effetchaque contrôleur RAID possède sa propre configuration.

Vu la configuration de la machine, nous allons utiliser l’utilitaire megacli.

La machine est bien configurée pour travailler avec une base de donnéestransactionnelle : pas de cache en lecture, du cache en écriture.

Notez que megacli nous met en garde que si les batteries de la carte RAID ne sontpas en bon état, nous risquons de perdre des données : No Write Cache if Bad BBU.

Nous connaissons maintenant toutes les caractéristiques de la machine. Il reste à voirsi elles sont utilisées à bon escient.

[borghino@mysql1 ~]$ sudo megacli -LDInfo -L0 -a0 -NoLogAdapter 0 -- Virtual Drive Information:Virtual Disk: 0 (target id: 0)Name:RAID Level: Primary-1, Secondary-3, RAID Level Qualifier-0Size:418176MBState: OptimalStripe Size: 64kBNumber Of Drives:2Span Depth:3Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBUCurrent Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBUAccess Policy: Read/WriteDisk Cache Policy: Disk's Default

RAPPEL write-through/write-back

• Cache write-through : toutes les écritures s’effectuent de façon synchrone avec le disque.• Cache write-back (ou write-behind) : toutes les écritures ne s’effectuent pas de façon synchrone ; elles

sont cachées.• ReadAheadNone : pas de lectures prédictives.Relisez le chapitre 2 consacré au matériel pour de plus amples informations sur le fonctionnement de cetype de cache.



Mesurer l’activité du serveurExécutons tout d’abord quelques commandes de base :

Nous en déduisons les informations suivantes :• load average : il s’agit du nombre de processus en attente de ressources

(mémoire, CPU, I/O) ;• SWAP : lorsque le serveur n’a pas assez de mémoire vive, il utilise sa zone d’échange

sur disque, dite zone de swap, augmentant ainsi énormément les I/O sur le dis-que, ce que nous souhaitons absolument éviter.

Les outils systèmeiostat, vmstat et netstat sont les trois outils les plus courants en ce qui concernel’analyse de performances. Ils sont en général livrés avec tous les systèmes Unix etsont faciles à utiliser :• iostat : cet outil est relatif aux statistiques des entrées/sorties (input output statis-

tics). On y trouve également des informations concernant la mémoire, le swap etles disques durs ;

• vmstat : statistiques sur la mémoire virtuelle ;• netstat : statistiques sur le réseau ;• mpstat : statistique sur les processeurs.

Toutes ces commandes donnent des informations sur les performances et les tempsd’attente. Nous cherchons toujours à repérer les points de contention, souvent iden-tifiés par des temps d’attente.

[borghino@mysql1 ~]$ uptime16:44:05 up 12 days, 1:45, 1 user, load average: 0.00, 0.00, 0.00

[borghino@mysql1 ~]$ topTasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombietop - 16:44:57 up 12 days, 1:46, 1 user, load average: 0.00, 0.00, 0.00Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombieCpu(s): 0.0% us, 0.1% sy, 0.0% ni, 99.9% id, 0.0% wa, 0.0% hi, 0.0% siMem: 8165320k total, 1441516k used, 6723804k free, 104700k buffersSwap: 8122360k total, 0k used, 8122360k free, 1149832k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND882 mysql 16 0 428m 66m 6488 S 0.0 0.8 0:00.20 mysqld



125

La commande iostat

Notez que deux colonnes représentent des valeurs moyennes, avgrp-sz et avgqu-sz.Cette dernière est particulierement intéressante :• avgrq-sz : taille moyenne en secteurs des requêtes ;• avgqu-sz : taille moyenne des queues de requêtes.

avgqu-sz est une des informations les plus importantes. Comment sont gérées lesactions sur le disque ? Peu de requêtes qui attendent peut signifier dans un cas que lesystème n’est pas chargé, ou alors que toutes les actions sont sérialisées. Dans l’autre cas,avec une liste de requêtes en attente, tous les disques sont occupés. Par exemple, dans lecas d’un système avec des problèmes de performance mais pas de contention au niveaudes queues, nous pourrions envisager d’utiliser davantage de lectures en avance de phasepour répondre aux besoins. L’objectif est d’optimiser les ressources disponibles.• Await : temps moyen pour traiter nos I/O (queue + requête). Plus cette valeur est

haute, moins le système est performant.• Svctm : temps moyen pour servir les requêtes. Plus le système est chargé, moins

cette valeur est importante car des ressources vont être utilisées par ailleurs.• %util : temps pendant lequel les processeurs ont été utilisés pour gérer les dis-

ques. Plus on approche de 100 %, plus la ressource est proche de la saturation.

[borghino@mysql1 ~]$ iostat -dx 5 5Linux 2.6.9-89.ELsmp (mysql1) 09/11/2009

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %utilsda 7.09 8.27 0.30 0.63 62.30 71.65 31.15 35.82 144.00 0.01 15.20 0.82 0.08sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10.81 0.00 1.29 1.29 0.00sda2 7.09 8.27 0.30 0.63 62.30 71.65 31.15 35.82 144.01 0.01 15.20 0.82 0.08dm-0 0.00 0.00 0.02 0.04 0.58 0.28 0.29 0.14 16.14 0.00 21.93 0.42 0.00dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 1.89 0.77 0.00

Tableau 4–1 Légendes de la commande iostat

Lectures Écritures Signification

rrqm/s wrqm/s Les lectures/écritures fusionnées au niveau des blocs I/O. Il est plus simple et plus courant de voir des fusions au niveau des lectures qu’au niveau des écritures.

r/s w/s Les lectures/écritures après la fusion.

rsec/s wsec/s Les secteurs sont des éléments du disque sur qui stockent des informations. En divisant le nombre de secteurs par 2048, nous obtenons des Mo/s.

rkB/s wkB/s Les kilo-octets lus/écrits.



La commande vmstat

La légende de cette commande est la suivante.

Processus :• r : processus en attente ;• b : processus dormant.

Mémoire :• swpd : virtuelle ;• free : en attente ;• buff : utilisée comme buffer ;• cache : utilisée comme cache ;• inact : inactive ;• active : active.

Swap :• si : swap en entrée ;• so : swap en sortie.

Entrées/sorties :• bi : blocs reçus ;• bo : blocs envoyés.

Système :• in : interruptions (nombre des interruptions) ;• cs : changement de contexte (context switches).

CPU : en pourcentage du temps processeur total.• us : % code non kernel ;• sy : % kernel ;• id : % libre ;• wa : % attente.

[borghino@mysql1 ~]$ vmstat 5 5procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----r b swpd free buff cache si so bi bo in cs us sy id wa0 0 0 6036692 112004 1790568 0 0 8 9 5 8 0 0 100 00 0 0 6036692 112004 1790568 0 0 0 0 1013 18 0 0 100 0



127

Les commandes netstat et mpstatnetstat (network statistics) affiche les statistiques sur les connexions réseau entrantes etsortantes, mais aussi sur les tables de routage ainsi que sur les interfaces. Grâce à elle, ilest possible d’évaluer le trafic réseau et d’identifier une éventuelle contention, parexemple repérer certaines connexions en trop grand nombre émanant d'un même port.

Quant à mpstat, elle renseigne sur l’activité du processeur : est-il pleinement utiliséou en attente ? Quels sont les processus qui l’utilisent ? Etc.

Voici un exemple d’utilisation de ces deux commandes avec leurs résultats.

En plus des outils système, voici une liste d’outils Open Source qui ont été créés autourde MySQL par des membres de la communauté. Vous trouverez plusieurs catégories,que ce soit des outils dédiés à l’audit ou à l’analyse temps réel différée (enregistrementde métriques).

Outils d’audit : MySQLTuner et mysqlreportMySQLTuner a été créé par Major Hayden en 2006. Il permet d’obtenir une analysedétaillée de la base de données. Les messages présentés sont clairs et beaucoup plusfaciles à comprendre que ceux issus de la commande SHOW STATUS. Le groupe de

[borghino@mysql1 ~]$ netstat -rnKernel IP routing tableDestination Gateway Genmask Flags MSS Window irtt Iface68.152.212.0 0.0.0.0 255.255.254.0 U 0 0 0 eth00.0.0.0 68.152.212.1 0.0.0.0 UG 0 0 0 eth0[borghino@mysql1 ~]$ mpstat 5 5Linux 2.6.9-89.ELsmp (mysql1) 09/11/200908:00:07 AM CPU %user %nice %system %iowait %irq %soft %idle intr/s08:00:12 AM all 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1039.4308:00:17 AM all 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1040.25

ALTERNATIVE oprofile, dtrace, fincore et filefrag

Il existe d’autres outils système intéressants :• oprofile (http://oprofile.sourceforge.net/news/) est un profiler qui permet, lors d’un problème de per-

formance CPU, de connaître exactement les lignes de code à l’origine de cette perte de temps.• dtrace est un excellent outil, hélas pour l’instant limité à Solaris.• fincore (http://net.doit.wisc.edu/~plonka/fincore/fincore) permet de vérifier comment le système

d’exploitation cache les fichiers. Cet outil est particulièrement utile pour MyISAM vu que nous ne con-trôlons pas le cache des donnés (seuls les index sont mis en cache).

• filefrag calcule la fragmentation d’un fichier. On peut donc l’utiliser pour mesurer la fragmentation destables ou d’un tablespace.



DBA Pythian (http://www.pythian.com) est en train de créer une nouvelle version pluscomplète de ce script.

Dans l’exemple suivant (voir ci-contre), MySQLTuner constate de nombreux problèmes :� La version de MySQL est à mettre à jour.� Le système doit être passé en 64 bits.� InnoDB n’est pas utilisé.� Il y a des tables fragmentées.� Le nombre de connexions maximal a été atteint.� Le cache de requêtes est souvent invalidé.� Près de la moitié des tables temporaires créées le sont sur disque et non en

mémoire. Le nombre maximal de fichiers ouverts simultanément est presque atteint/ Le cache de table est trop faible.

Les actions adéquates sont recommandées : • Mettre à jour si besoin la version de MySQL• Passer le système en 64 bits (système et matériel) si la quantité de RAM présente

sur le serveur est supérieure à 4 Go.• Appliquer un OPTIMIZE TABLE sur les tables qui sont les plus régulièrement mises

à jour (nombreux ajouts/suppressions).• Désactiver le cache de requêtes sur celles dont les tables impliquées sont mises à

jour régulièrement.• Augmenter la valeur de max_connections en fonction de vos besoins (se reporter

à nos conseils concernant cette variable).• Afin de faire diminuer le nombre de tables temporaires créées sur disque il est

possible soit d’optimiser les requêtes SQL qui provoquent ces créations de tablestemporaires (orientez-vous vers celles qui effectuent des tris de type GROUP BY parexemple) soit d’augmenter simultanément les valeurs de max_heap_table_size ettmp_table_size.

• Augmenter la limite du nombre de fichiers ouverts simultanément via la variable--open-files-limit, celle-ci étant bornée par la valeur retournée par la com-mande système ulimit.

Concernant les variables à ajuster relevées par l’outil, celui-ci attribue le signe >quand il recommande d’augmenter une valeur et au contraire le signe < lorsqu’il

B http://mysqltuner.com



129

estime souhaitable de la diminuer. Par exemple pour max_connections, la limite des250 définie dans le serveur MySQL est atteinte (251) d’où sa recommandation del’augmenter. Ceci est bien sûr à effectuer dans la mesure des possibilités physiques dela machine. À l’inverse, le wait_timeout à 3600s peut être réduit afin que le serveurcoupe plus rapidement une connexion considérée inactive.

Rappelons encore que MySQL Tuner n’est qu’un outil, dont il ne faut jamais suivreaveuglément les recommandations. Il faut s’attacher à y lire d’abord des suggestions,ou des indices.

Types d’informations retournées par MySQLTuner

[borghino@mysql1 ~]$ sudo ./mysqltuner.pl>> MySQLTuner 1.0.0 - Major Hayden <[email protected]>>> Bug reports, feature requests, and downloads at http://mysqltuner.com/>> Run with '--help' for additional options and output filteringPlease enter your MySQL administrative login: rootPlease enter your MySQL administrative password:

-------- General Statistics --------------------------------------------------[--] Skipped version check for MySQLTuner script[!!] Your MySQL version 4.1.23 is EOL software! Upgrade soon! �[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM �

-------- Storage Engine Statistics -------------------------------------------[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster[--] Data in MyISAM tables: 34G (Tables: 16042)[!!] InnoDB is enabled but isn't being used �[!!] Total fragmented tables: 77 �

-------- Performance Metrics -------------------------------------------------[--] Up for: 43d 23h 8m 25s (44M q [11.686 qps], 5M conn, TX: 898M, RX: 2B)[--] Reads / Writes: 78% / 22%[--] Total buffers: 896.0M global + 18.6M per thread (250 max threads)[!!] Allocating > 2GB RAM on 32-bit systems can cause system instability[!!] Maximum possible memory usage: 5.4G (136% of installed RAM)[OK] Slow queries: 0% (52K/44M)[!!] Highest connection usage: 100% (251/250) �[OK] Key buffer size / total MyISAM indexes: 768.0M/1.1G[OK] Key buffer hit rate: 99.9% (6B cached / 8M reads)[OK] Query cache efficiency: 46.1% (11M cached / 25M selects)[!!] Query cache prunes per day: 227047 �[OK] Sorts requiring temporary tables: 0% (77 temp sorts / 682K sorts)[!!] Temporary tables created on disk: 49% (319K on disk / 642K total) �[OK] Thread cache hit rate: 99% (4K created / 5M connections)[!!] Table cache hit rate: 0% (3K open / 901K opened) [!!] Open file limit used: 96% (7K/8K)



mysqlreport fournit à peu près les mêmes informations. À vous de le tester et d’utiliserl’outil qui vous intéresse le plus. S’il vous manque une information cruciale, pourquoine pas participer à la vie du projet et apporter votre contribution ? Les outils MySQLet le serveur MySQL lui-même se sont développés grâce à la communauté.

[OK] Table locks acquired immediately: 99% (18M immediate / 18M locks)[!!] Connections aborted: 24%

-------- Recommendations -----------------------------------------------------General recommendations:Add skip-innodb to MySQL configuration to disable InnoDBRun OPTIMIZE TABLE to defragment tables for better performanceReduce or eliminate persistent connections to reduce connection usageWhen making adjustments, make tmp_table_size/max_heap_table_size equalReduce your SELECT DISTINCT queries without LIMIT clausesIncrease table_cache gradually to avoid file descriptor limitsYour applications are not closing MySQL connections properlyVariables to adjust:*** MySQL's maximum memory usage is dangerously high ****** Add RAM before increasing MySQL buffer variables ***max_connections (> 250)wait_timeout (< 3600)interactive_timeout (< 3600)query_cache_size (> 32M)tmp_table_size (> 64M)max_heap_table_size (> 63M)table_cache (> 3966)open_files_limit (> 8192)

ASTUCE Surveiller son serveur à distance

Surveiller son serveur MySQL à distance permet d’éviter la multiplication des installations des outils desurveillance. En effet la plupart d’entre eux possèdent la fameuse option -h permettant de pointer versla machine cible.En plus de limiter l’installation proprement dite des programmes/scripts de surveillance, procéder à unesurveillance à distance permet de n’installer que le strict nécessaire sur les machines de production (pasde librairies externes ou de langages de script superflus).Attention, ce mode de surveillance présente un inconvénient : si vous perdez, pour une raison quelcon-que, la machine sur laquelle est installée l’intégralité de vos outils, vous voilà aveugle.

B http://hackmysql.com/mysqlreport



131

Outils d’analyse temsp réel : mytop, mtop, innotop et maatkitUne fois que nous possédons une vue de l’ensemble, il est temps d’analyser la base entemps réel. • mytop (http://jeremy.zawodny.com/mysql/mytop/) possède, comme la commande top qui

permet d’observer les processus lancés sur un serveur, la même logique. Il proposede visualiser facilement les requêtes, les threads et les performances du système. Cetoutil a été écrit par Jeremy Zawodny dans les années 2000. La dernière version datede 2007, mais le développement n’est plus très actif depuis quelques années.

• innotop est apparu en 2006. Les outils comme mytop (2003) et mtop (2004)n’étaient plus maintenus et manquaient surtout d’une capacité essentielle : l’ana-lyse du moteur InnoDB. En effet, pour suivre en temps réel ce qui se passe dansce moteur, nous ne disposions que de la commande SHOW INNODB STATUS, plutôtdifficile à lire. Nous y trouvons des informations sur les verrous, les sémaphores...Innotop rend ces informations lisibles et les complète de renseignements perti-nents. Ce script a été écrit par Baron Schwartz (http://code.google.com/p/innotop/).

• Impossible d’évoquer Baron sans parler de Maatkit (http://www.maatkit.org/). Si Maatkitne permet pas de surveiller votre serveur, c’est en revanche un ensemble de scriptstrès pratiques. Parmi ces scripts, on trouve mk-table-checksum qui permet de véri-fier que les tables du maître et de l’esclave sont bien identiques. mk-parallel-dumppermet quant à lui d’utiliser plusieurs instances de mysqldump en parallèle.

Les outils que nous venons d’évoquer fournissent des informations sur l’état actueldu système, permettant ainsi de détecter plus facilement les goulets d’étranglement.La prochaine étape consiste à tenter d’anticiper ces ralentissements.

Combien d’I/O le système est-il capable de supporter ? Comment cela se traduit-ilsur la base et sur l’application ?

Ceci nous amène aux deux prochains thèmes : évaluer les performances d’un systèmeet le capacity planning.

Évaluer les performances d’un systèmeAnalyser et comprendre son système (système d’exploitation, matériel...) sont deuxpoints essentiels concernant l’audit et la performance d’un serveur. L’étape suivante estd’en connaître les limites. Pour cela, il n’y a qu’une seule option possible : le bench-mark. Il s’agit d’un banc d’essai permettant de mesurer les performances d’un systèmepour le comparer à d’autres.



Il existe des centaines de possibilités et il est très difficile de modéliser par les tests lefutur fonctionnement d’une application. Parmi les principaux types de tests on peutidentifier les suivants :• tests de charges ;• tests de performances ;• tests de stress ;• tests de robustesse ;• tests de capacité.

Tester un système est une tâche qui prend beaucoup de temps et constitue un luxeque peu d’entre nous peuvent s’offrir. Nous allons donc nous concentrer surl’essentiel : le disque, traditionnel goulet d’étranglement pour une base de données.

Afin de tester les capacités des disques, nous vous conseillons l’utilisation deBonnie++.

Bonnie++ s’appuie sur Bonnie, un outil de type benchmark spécialisé dans les disquesdurs. Une des améliorations importantes de cet outil est le support pour des fichiersde plus de 2 Go et des répertoires comportant des milliers de fichiers. Grâce à cetoutil, il est par exemple possible de distinguer les différences de performance enfonction des différentes options d’une configuration RAID. Les informations analy-sées sont la vitesse de lecture, la vitesse d’écriture et le nombre d’opérations surdisque (seek) qui peuvent être traitées par seconde.

Un test bonnie++ prend environ 10 minutes. Nous allons utiliser la commandesuivante : bonnie++ -f -n 256• -n 256 pour forcer Bonnie à afficher tous les résultats.• -f pour forcer l’utilisation de la fonction fsync(). Ce paramètre est important

selon que l’on souhaite effectuer des tests pour une base de données ou un serveurde messagerie.

Lancement du test bonnie++

JARGON Le smoke test, un test aux limites

Ce type de test est également appelé smoke test, autrement dit un test qui pousse le système dans sesretranchements, quitte à ce qu’il dégage de la fumée si d’aventure un composant défectueux décide degriller.

Tests run: Sequential output (block, rewrite), Sequential Input (block), Random (seeks)[borghino@mysql1 bonnie++-1.03e]$ bonnie++ -f -n 256



133

Dans cet exemple, nous obtenons en moyenne :• écriture : 50 Mo/s 90 % CPU ;• lecture : 385 Mo/s 99 % CPU ;• seek : 805.4/s 1 % CPU.

Une fois les performances des disques mesurées, examinons les performances deMySQL. Pour cela, nous allons utiliser l’outil sysbench.

Il est possible d’obtenir les performances en écriture et lecture avant de tester le ser-veur MySQL lui-même :

Lancements de sysbench sans connexion au serveur MySQL

Writing intelligently...doneRewriting...doneReading intelligently...donestart 'em...done...done...done...Create files in sequential order...done.Stat files in sequential order...done.Delete files in sequential order...done.Create files in random order...done.Stat files in random order...done.Delete files in random order...done.Version 1.03e ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CPmysql1 16G 132920 32 62411 11 234892 19 805.4 1 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 256 49654 90 384386 99 22295 44 50144 89 +++++ +++ 14646 33

Operating System A:

Version 1.02 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CPtr 512M 26157 94 36552 39 15361 19 19900 94 37817 21 899.6 4 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 97 1 +++++ +++ 119 0 95 1 +++++ +++ 263 1

[borghino@mysql1 sysbench]$ sysbench --test=fileio --max-time=60 --max-requests=1000000 --file-num=1 --file-extra-flags=direct --file-fsync-freq=0 --file-total-size=128M --num-threads=64 --file-test-mode=rndwr run



En conclusion de ces tests, avec 64 threads en parallèle sur un fichier on obtient :• écriture : 3k × 16k à 50 Mo/s ;• lecture : 22k × 16k à 355 Mo/s.

Les résultats correspondent avec ceux de Bonnie++.

Ajoutons maintenant MySQL dans le test sysbench :

Exécution de sysbench corrélée au serveur MySQL

Operations performed: 0 Read, 187852 Write, 0 Other = 187852 TotalRead 0b Written 2.8664Gb Total transferred 2.8664Gb (48.903Mb/sec)3129.80 Requests/sec executed

[borghino@mysql1 sysbench]$ sysbench --test=fileio --max-time=60 --max-requests=1000000 --file-num=1 --file-extra-flags=direct --file-fsync-freq=0 --file-total-size=128M --file-test-mode=rndrd --num-threads=64 runOperations performed: 1000073 Read, 0 Write, 0 Other = 1000073 Total Read 15.26Gb Written 0b Total transferred 15.26Gb (346.96Mb/sec)22205.34 Requests/sec executed

sysbench --test=oltp --mysql-host=localhost --db-driver=mysql --oltp-table-name=big --oltp-table-size=30000000 --num-threads=$1 --max-requests=10000000 --mysql-engine-trx=auto --mysql-table-engine=innodb --max-time=900 --myisam-max-rows=120000000 cleanup

Une table InnoDB avec 30 millions d'enregistrements est créée. Les tests seront limités à 15min.

sysbench -mysql-host=localhost --db-driver=mysql --oltp-table-name=big --oltp-table-size=30000000 --num-threads=64 --max-requests=10000000 --mysql-engine-trx=auto --mysql-table-engine=innodb --max-time=900 --myisam-max-rows=120000000 --oltp-test-mode=complex --oltp-dist-type=special --oltp-dist-pct=10 --oltp-dist-res=75 --oltp-simple-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --oltp-distinct-ranges=0 run

Doing OLTP test.Running mixed OLTP testUsing Special distribution (12 iterations, 10 pct of values are returned in 75 pct cases)Maximum number of requests for OLTP test is limited to 10000000

OLTP test statistics: queries performed: read: 16924270 write: 8462135 other: 3384854 total: 28771259



135

Conclusion : environ 30 000 requêtes par seconde sont traitées sur ce système.

Ces tests nous ont permis d’obtenir un complément d’informations qui permet de des-siner les limites du système. Il est alors plus aisé d’anticiper les points de contention.

Anticiper et prévenir nous amène dans un autre aparté, celui de la planification descapacités du système (capacity planning).

Que faire des résultats précédemment obtenus : sont-ils bons ou mauvais ? Finalementla question n’est pas là. Nous savons désormais quelles sont les performances sur de telssystèmes. À vous de déterminer si celles-ci sont suffisantes en fonction de vos besoins.

Dans le cas présent, si votre système en pleine charge doit être capable de supporter30 000 requêtes, d’écrire plus de 50 Mo/s ou de lire plus de 355 Mo/s, alors tout vabien. Dans le cas contraire, il est temps de trouver un moyen d’augmenter la capacitéde l’ensemble, soit au niveau du serveur, de l’architecture ou de l’application.

transactions: 1692427 (1880.39 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 25386405 (28205.87 per sec.) other operations: 3384854 (3760.78 per sec.)

Test execution summary: total time: 900.0399s total number of events: 1692427 total time taken by event execution: 57578.4815 per-request statistics: min: 1.12ms avg: 34.02ms max: 8214.12ms approx. 95 percentile: 85.87ms

Threads fairness: events (avg/stddev): 26444.1719/140.83 execution time (avg/stddev): 899.6638/0.01

MÉTHODE Dimensionnement : les bons tests

Un bon test est celui qui vous permet d’en apprendre davantage sur votre environnement et ses limites.Prenons par exemple le cas d’une voiture. Savoir que celle-ci peut rouler à 200 km/h ne sert à rien si vousne dépassez pas les 130 km/h. En revanche, connaître la différence de consommation de carburant entre120 km/h et 130 km/h est pertinent.Imaginons maintenant que nous analysions un site web présentant des informations sportives. Il fautabsolument connaître la correspondance entre le nombre de pages vues et le nombre de requêtes géné-rées en base de données. Ces requêtes vont elles-mêmes se traduire en nombre d’accès disque. Uneseule solution : tester toute la chaîne.



D’autres outils existent sur le marché que nous ne pouvons pas tous présenter ; envoici quelques exemples que vous pouvez examiner.

Pour tester votre système :• LMBench : http://www.bitmover.com/lmbench/

• unixbench : http://www.tux.org/pub/tux/niemi/unixbench/

Pour tester votre réseau :• dbench : http://samba.org/ftp/tridge/dbench/

Pour tester vos CPU/mémoire :• LLCbench : http://icl.cs.utk.edu/projects/llcbench/

• ubench : http://www.phystech.com/download/ubench.html

• nbench : http://www.tux.org/~mayer/linux/bmark.html

• stream : http://www.streambench.org/

Pour tester votre disque :• Bonnie++ : http://www.coker.com.au/bonnie++/

Pour tester votre application :• http_load : http://www.acme.com/software/http_load/

• sysbench : http://sysbench.sourceforge.net/

Pour tester vos requêtes :• mysqlslap : http://dev.mysql.com/doc/refman/5.1/en/mysqlslap.html

• supersmack : http://vegan.net/tony/supersmack/

Bien dimensionner un système (capacity planning)Le capacity planning (ou gestion de la capacité d’un système) est aussi appelé rightsizing. Cette méthode a pour but de développer un modèle, une hypothèse, sur lacharge future des serveurs et la façon de gérer cette charge.

Dans cette optique il faut définir :• des niveaux de services adéquats ;• un surplus de machine raisonnable ;• une tolérance aux erreurs ;• une gestion des mises à jours (logicielles ou matérielles) ;• un cycle de vie approprié.

Le capacity planning a pour but de déterminer quels vont être les besoins en fonctiondes changements des produits. Par exemple, l’architecture d’un site web comprendprobablement un serveur de base de données et un serveur web Apache/PHP.



137

Jusque-là, du classique. Nouvelle hypothèse, ce système doit faire face à un événe-ment très médiatique augmentant du même coup de façon très significative le traficInternet du système... Que faut-il faire pour supporter la charge ? C’est en imaginantce type de scénarios que vous devez définir une architecture. S’il est bien souventimpossible de définir son système en se basant sur un pic de charge, avoir en têtequ’un tel pic puisse survenir est une bonne pratique.

Dans cet exemple, la capacité correspond au trafic maximal sur le site web sans qu’il yait de dégradations (performances de l’application, temps de réponse...).

Une bonne gestion consiste à supprimer les anomalies entre la capacité du système etles besoins des clients. Un système sous-utilisé est plus souhaitable qu’un systèmesuremployé. Il faut trouver le juste milieu en sachant prévoir :• les pics occasionnels ;• la montée en charge ;• les augmentations de trafic.

Il existe plusieurs modèles mathématiques pour calculer la capacité d’un système,comme :

Par efficacité, nous entendons les critères suivants : • Les objectifs sont-ils atteints?• Les systèmes sont-ils correctement utilisés ?• Les utilisateurs sont-ils satisfaits ?• L’étude du coût vs le revenu est-elle satisfaisante ?

Nous pouvons également appliquer différentes stratégies :• anticipation (lead) : ajouter de la capacité en anticipant la demande. C’est une

stratégie offensive qui a un coût assez important et est souvent source de gas-pillage.

• retard (lag) : ajouter de la capacité une fois que le besoin s’est fait sentir. Nousgaspillons moins de ressources, mais, pour un site Internet, un mauvais temps deréponse ou une interruption de services engendre souvent une perte de revenus oud’utilisateurs.

• modérée (match) : ajouter de la capacité petit à petit en fonction des besoins.

Nous allons adapter ces stratégies. La première question à se poser lorsqu’un pro-blème apparaît est tout d’abord de s’assurer qu’il s’agit bien d’un problème de capa-cité. En effet, un bogue, de mauvaises pratiques, un problème de sécurité... peuventêtre la cause d’ennuis sans pour autant que soient atteintes les limites du système.

nombre de machines × (% d’utilisation) x (% d’efficacité)



Dans tous les cas, lorsqu’on évoque la notion de capacité, il faut dans un premiertemps oublier les performances. Nous ne sommes plus là pour optimiser mais pourconnaître les limites actuelles du système.

À partir de cet instant, il faut être certain que tous les systèmes de surveillance sontactivés. C’est en effet en visualisant comment la plate-forme se comporte que nousallons collecter suffisamment d’informations pour gérer la capacité. Voici ce qu’il fautmesurer :• les métriques entrée/sortie ;• les métriques applicatifs (comme le nombre de pages vues).

Il est très important de faire le lien entre les deux afin de pouvoir comparer les infor-mations. En effet, 300 Mo/s en lecture sur la base de données n’est pas très parlant apriori... En revanche, savoir que 300 Mo correspondent à 200 000 pages vues, tra-duit l’apparition d’une tendance et il devient possible de quantifier le nombre derequêtes auquel le système sera soumis.

Dans cette équation, l’inconnue est le temps. Au bout de combien de temps, si le traficaugmente régulièrement, allons-nous atteindre ces 80 %. Une fois cette inconnue éli-minée, nous pourrons quantifier sous quel délai il faudra ajouter des machines.

Fityk est un outil qui permet de calculer ce type d’informations (http://www.unipress.waw.pl/fityk/).

Connaître la capacité, c’est connaître le système avec les pics haut et bas... En effet, si letrafic augmente trop rapidement, cela signifie qu’un événement spécial a lieu. Inverse-ment, le trafic peut chuter d’un coup. Dans les deux cas une alerte doit être lancée.

Augmenter la capacité peut à la fois signifier être capable d’augmenter le nombre deserveurs mais également de conserver le même nombre de machines en augmentantleur puissance : davantage de cœurs, de RAM, de disques (scaling-up).

À SAVOIR La notion de seuil

Une notion très importante est celle des plafonds ou seuils. Par exemple, si un serveur web a une utilisa-tion de CPU à 50 %, jusqu’à quel pourcentage d’utilisation du processeur pouvons-nous monter sansconnaître de problèmes de stabilité ? Ce pourcentage déterminera le plafond. Dans le cas d’un plafonddéfini à 80 %, avec une consommation processeur de 50 % comme ici, nous disposons de 30 % margede manœuvre.

À LIRE La montée en charge matérielle

Le chapitre 2 consacré au matériel revient plus précisément sur les notions de scaling-up/scaling-out.



139

Enfin, gardez à l’esprit qu’un point de contention en cache toujours un autre. Siajouter des serveurs web va potentiellement résoudre une contention en entrée d’uneplate-forme, cela va sûrement augmenter la charge sur la base de données qui seraalors le prochain point à surveiller de près.

À LIRE Pour aller plus loin dans le domaine

Pour en savoir plus sur le sujet, nous vous conseillons :B http://www.kitchensoap.com/B http://www.eyrolles.com/Informatique/Livre/the-art-of-capacity-planning-9780596518578R J. Gabès, N. Makarévitch, Nagios 3 pour la supervision et la métrologie, Eyrolles 2009



À l’instar des boîtes noires qui enregistrent les données de vol d’un avion, les fichiersde journalisation ou logs gardent la trace des événements survenus sur un serveurMySQL. Dans ce chapitre, nous allons vous présenter les principaux logs serveur deMySQL, leurs rôles respectifs et expliquer comment bien les utiliser.

Ces fichiers, très utiles à l’administrateur, ont la particularité de permettre d’effectuerdes tâches aussi variées que la restauration de la base de données, l’identification desrequêtes problématiques, l’aide à la prévention des incidents ou tout simplementd’offrir à l’administrateur les moyens de comprendre pourquoi le serveur est en panne.

Sur un serveur en production, d’importants volumes de données peuvent être journa-lisés. Il est donc fortement conseillé de mettre en place des procédures pour surveillerles espaces de stockage. En effet, certains fichiers de logs peuvent, en fonction de lavolumétrie et/ou de la charge du serveur, grossir rapidement.

L’impact de ces fichiers sur les performances du serveur est un autre point importantà garder à l’esprit. Par exemple, le journal général, s’il stocke ces informations dans latable qui lui est dédiée (mysql.general_log), peut diminuer les performances devotre serveur de moitié. Le bon réglage est bien souvent le résultat d’un compromis...

MySQL possède 4 types de journaux serveur :• le journal des erreurs (error log) ;• le journal général (general query log) ;• le journal des requêtes lentes (slow query log) ;• le journal binaire (binary log).

5Exploiter les journaux de MySQL



Le journal des erreursActivé par défaut, ce fichier se reconnaît grâce à son extension .err. On le retrouvegénéralement sous la forme nom_machine.err. Il est situé, là encore par défaut, dansle répertoire de données (que vous pouvez identifier avec la commande SHOW GLOBALVARIABLES LIKE 'datadir'). Il est possible de changer son nom, à l’exception dusuffixe, et de le placer à un autre endroit, à l’aide de l’option log-error, au démar-rage du serveur en ligne de commandes :

ou alors dans le fichier de configuration, dans la section serveur (mysqld) :

Notez que si vous démarrez le serveur en ligne de commande avec l’option --console,les informations du journal des erreurs ne s’afficheront que dans stderr (a priori dansla console).

Pour localiser le journal des erreurs, vous pouvez utiliser la commande SHOW GLOBALVARIABLES dans un client MySQL :

Localiser le journal des erreurs

Le journal des erreurs est un fichier qui grossit au fil du temps. Sa gestion est en faitassez basique : vous avez la possibilité de fermer (flush) le journal courant et d’enouvrir un autre avec la commande FLUSH LOGS. Le serveur renommera le fichier en lecomplétant par la chaîne de caractères -old et un nouveau fichier vide sera créé avecl’ancien nom :

mysqld --log-error = /appli/log/mysql-error.err

[mysqld]log-error = /appli/log/mysql-error.err

mysql> SHOW GLOBAL VARIABLES LIKE 'log_error' \G***************** 1. row ******************Variable_name: log_errorValue: /appli/log/mysql-error.err

shell> ls -l mysql-error.err*-rw-rw---- 1 daz daz 8232 2009-08-08 15:43 mysql-error.err

mysql> FLUSH LOGS;Query OK, 0 rows affected (0.14 sec)

shell> ls -l mysql-error.err*-rw-rw---- 1 daz daz 0 2009-08-10 19:22 mysql-error.err-rw-rw---- 1 daz daz 8232 2009-08-08 15:43 mysql-error.err-old


Exploiter les journaux de MySQLCHAPITRE 5

143

Identifier et résoudre les problèmesLes informations consignées dans le fichier de journalisation des erreurs peuvent êtreà l’origine de la résolution d’un certain nombre de problèmes. Il est par exemple pos-sible d’y déceler un redémarrage non prévu. Dans le cas suivant, le processus mysqld aété arrêté à 17h55, puis redémarré par le processus mysqld_safe.

Arrêt et redémarrage du serveur

Modifier le tablespace ou les journaux d’InnoDBUne erreur courante est de penser que changer la taille du tablespace(innodb_data_file_path) ou celle des journaux d’InnoDB (innodb_log_file_size)s’effectue simplement en modifiant ces paramètres dans le fichier de configuration.En fonction de votre version de MySQL, au mieux le serveur ne démarrera pas, aupire, il démarrera mais sans lancer le plug-in InnoDB. En d’autres termes, les tablesInnoDB ne seront plus accessibles.

ASTUCE Rotation des journaux avec logrotate

Pour faciliter la gestion du journal des erreurs, vous pouvez utiliser l’outil de maintenance logrotate etplanifier des tâches (cron) pour éventuellement compresser et déplacer l’historique trop ancien. Un desauteurs de ce livre en est devenu un adepte après avoir rencontré des problèmes avec MySQL 4.0 enenvironnement FreeBSD 4.

shell> cat mysql-error.err

090812 17:20:44 mysqld_safe Starting mysqld daemon with databases from /home/daz/sandboxes/msb_5_1_35/data090812 17:20:44 InnoDB: Started; log sequence number 0 6973121090812 17:20:44 [Note] /usr/local/mysql/5.1.35/bin/mysqld: ready for connections.Version: '5.1.35-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)Killed090812 17:55:07 mysqld_safe Number of processes running now: 0090812 17:55:07 mysqld_safe mysqld restarted090812 17:55:08 InnoDB: Started; log sequence number 0 6973121090812 17:55:08 [Note] Recovering after a crash using /appli/log/mysql-bin090812 17:55:08 [Note] Starting crash recovery...090812 17:55:08 [Note] Crash recovery finished.090812 17:55:08 [Note] /usr/local/mysql/5.1.35/bin/mysqld: ready for connections.Version: '5.1.35-log' socket: '/tmp/mysql_sandbox5135.sock' port: 5135 MySQL Community Server (GPL)



Pour modifier ces paramètres, il faut opérer une sauvegarde logique des tables InnoDB,arrêter le serveur MySQL en vérifiant qu’il n’y a pas d’erreurs, déplacer le tablespace etles journaux d’InnoDB (vous pourrez les supprimer une fois l’opération terminée avecsuccès). Redémarrez ensuite le serveur MySQL avec la nouvelle configuration etrejouez votre sauvegarde. Vérifiez dans le journal des erreurs que tout s’est bien passé.

Paramètre incorrect dans le fichier de configurationUne simple erreur de frappe, sur le nom d’un paramètre et le serveur refuse dedémarrer. Dans l’exemple qui suit, on identifie donc la cause du problème et implicite-ment sa solution. Le véritable nom de la variable n’est pas log-binaire mais log-bin.

Paramètre inconnu dans le fichier de configuration


InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytesInnoDB: than specified in the .cnf file 0 10485760 bytes!090928 19:13:46 [ERROR] Plugin 'InnoDB' init function returned error.090928 19:13:46 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.090928 19:13:46 [Note] Event Scheduler: Loaded 1 event090928 19:13:46 [Note] /usr/local/mysql/5.1.35/bin/mysqld: ready for connections....


InnoDB: Error: data file ./ibdata1 is of a different sizeInnoDB: 1152 pages (rounded down to MB)InnoDB: than specified in the .cnf file 640 pages!InnoDB: Could not open or create data files....


090812 18:19:50 mysqld_safe mysqld from pid file /appli/log/mysql_sandbox5135.pid ended090812 18:19:53 mysqld_safe Starting mysqld daemon with databases from /home/daz/sandboxes/msb_5_1_35/data090812 18:19:53 InnoDB: Started; log sequence number 0 6973121090812 18:19:53 [ERROR] /usr/local/mysql/5.1.35/bin/mysqld: unknown variable 'log-binaire=/appli/log/mysql-bin'090812 18:19:53 [ERROR] Aborting



145

Si le nom d’un paramètre doit être correctement orthographié, sa valeur doit bienentendu être adaptée aux besoins de l’application dans un souci d’optimisation. Elledoit également être ajustée aux caractéristiques de la machine.

Par exemple, il n’est pas permis d’allouer un buffer d’une taille supérieure à la possibilitéd’allocation du serveur. Si tel est le cas, MySQL va alors essayer de procéder au mieux.Par exemple, si le paramètre innodb_buffer_size est trop grand, la sanction estimmédiate : le serveur ne démarre pas. Si la valeur du paramètre key_buffer_size estsurdimensionnée, elle est ramenée à la taille maximale supportée.

090812 18:19:53 InnoDB: Starting shutdown...090812 18:19:54 InnoDB: Shutdown completed; log sequence number 0 6973121090812 18:19:54 [Warning] Forcing shutdown of 1 plugins090812 18:19:54 [Note] /usr/local/mysql/5.1.35/bin/mysqld: Shutdown complete

090812 18:15:58 mysqld_safe mysqld from pid file /appli/log/mysql_sandbox5135.pid ended090812 18:16:00 mysqld_safe Starting mysqld daemon with databases from /home/daz/sandboxes/msb_5_1_35/data090812 18:16:01 InnoDB: Error: cannot allocate 2147500032 bytes ofInnoDB: memory with malloc! Total allocated memoryInnoDB: by InnoDB 25166072 bytes. Operating system errno: 12InnoDB: Check if you should increase the swap file orInnoDB: ulimits of your operating system.InnoDB: On FreeBSD check you have compiled the OS withInnoDB: a big enough maximum process size.InnoDB: Note that in most 32-bit computers the processInnoDB: memory space is limited to 2 GB or 4 GB.InnoDB: We keep retrying the allocation for 60 seconds...

090812 18:11:25 [ERROR] innobase_buffer_pool_size can't be over 4GB on 32-bit systems090812 18:11:25 [ERROR] Plugin 'InnoDB' init function returned error.090812 18:11:25 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

090812 18:29:42 mysqld_safe Starting mysqld daemon with databases from /home/daz/sandboxes/msb_5_1_35/data090812 18:29:42 [Warning] option 'key_buffer_size': unsigned value 8589934592 adjusted to 4294963200090812 18:29:42 InnoDB: Started; log sequence number 0 6973121090812 18:29:42 [Note] Event Scheduler: Loaded 0 events090812 18:29:42 [Note] /usr/local/mysql/5.1.35/bin/mysqld: ready for connections.Version: '5.1.35-log' socket: '/tmp/mysql_sandbox5135.sock' port: 5135 MySQL Community Server (GPL)



Erreurs liées à la réplicationComme nous l’avons évoqué plus tôt, le journal des erreurs permet de surveiller cer-taines fonctionnalités de MySQL, dont la réplication (la réplication est exposée endétail au chapitre 8, La réplication MySQL). Dans cet usage, le journal des erreursn’indique pas que des mauvaises nouvelles. Sur une machine esclave, les informationsrelatives au démarrage de la réplication, notamment le thread I/O et le thread SQL,y sont notées :

Sur l’exemple suivant, notez un arrêt puis un redémarrage du thread SQL :

Une réplication en échec peut avoir plusieurs origines (le serveur maître n’est plusaccessible, une erreur de requête sur le serveur esclave...). Là encore, des informationssont journalisées dans le journal des erreurs de la machine esclave et permettent sou-vent d’éliminer de mauvaises pistes. Dans le premier extrait de log qui suit, on s’aper-çoit que la machine esclave a perdu la connexion avec la machine maître. Dans lesecond, des écritures sur le serveur esclave sont à l’origine de la violation de la con-trainte d’unicité de la clé primaire (Duplicate entry). Dans les deux cas, la réplicationest cassée.

Connexion perdue entre serveurs maître et esclave

090813 14:12:14 [Note] Slave I/O thread: connected to master '[email protected]:23150',replication started in log 'mysql-bin.000001' at position 4357768090813 14:12:14 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000001' at position 4357768, relay log './mysql_esclave1-relay-bin.000004' position: 251

090813 16:45:56 [Note] Error reading relay log event: slave SQL thread was killed090813 16:46:22 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000002' at position 106, relay log './mysql_esclave1-relay-bin.000012' position: 208

090813 14:25:41 [ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013)090813 14:25:41 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000001' at postion 4357768090813 14:25:41 [ERROR] Slave I/O: error reconnecting to master '[email protected]:23150' - retry-time: 60 retries: 86400, Error_code: 2013



147

Violation de la contrainte d’intégrité sur l’esclave

Erreurs diversesLe programmateur d’événements ou event scheduler est apparu avec MySQL 5.1.6. Iloffre la possibilité à l’administrateur de bases de données de déclencher l’exécutionde requêtes programmées directement dans le serveur MySQL. Il permet donc,comme avec les commandes cron ou tâches planifiées, d’automatiser très simplementdes tâches à des intervalles réguliers, ou à heure fixe, sans avoir besoin de configurerle système sur lequel la base de données fonctionne. Le journal des erreurs permetd’être averti si l’une des tâches ne s’est pas déroulée correctement.

La cohérence des données est un point très important, que votre base de donnéesdoit assurer. Après un arrêt brutal, si vous utilisez des tables InnoDB, un mécanismeappelé crash recovery est enclenché automatiquement au redémarrage de l’instance. Ila pour but de mettre la base dans un état propre :

En revanche, MyISAM n’offre pas de mécanismes automatiques pour assurer lacohérence des données. Cependant, avec l’option myisam_recover, vous avez la pos-sibilité de vérifier toutes les tables MyISAM à chaque démarrage du serveur.

090813 17:02:55 [ERROR] Slave SQL: Error 'Duplicate entry '1' for key 'PRIMARY'' on query. Default database: 'test'. Query: 'INSERT INTO client (client_id, nom, email, actif) VALUES (NULL, 'freshdaz', '[email protected]', 1)', Error_code: 1062090813 17:02:55 [Warning] Slave: Duplicate entry '1' for key 'PRIMARY' Error_code: 1062090813 17:02:55 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000002' position 724442

090813 17:40:05 [Note] Event Scheduler: scheduler thread started with id 3090813 17:53:14 [ERROR] Event Scheduler: [daz@localhost][_event.vue_materialisee] Table '_event.City_fra' doesn't exist090813 17:53:14 [Note] Event Scheduler: [daz@localhost].[_event.vue_materialisee] event execution failed.

090806 18:03:19 InnoDB: Started; log sequence number 0 6973081 090806 18:03:19 [Note] Recovering after a crash using /appli/log/mysql-bin 090806 18:03:19 [Note] Starting crash recovery... 090806 18:03:19 [Note] Crash recovery finished. 090806 18:03:19 [Note] /usr/local/mysql/5.1.35/bin/mysqld: ready for connections.



Si des tables corrompues sont détectées, l’information se retrouvera encore une foisdans le journal des erreurs :

Une requête sur une table MyISAM identifiée comme corrompue (marked ascrashed), va renvoyer une erreur au client ; de plus cette information sera inscrite dansle journal des erreurs :

Le journal des requêtes lentesLa durée d’exécution d’une requête est un paramètre qui sert souvent de métriquedans l’évaluation des performances d’une base de données. Dans l’imaginaire col-lectif, plus les requêtes sont rapides, plus la base de données est performante. Bienque la réalité soit un peu moins triviale, une requête dont la durée d’exécution esttrop longue est parfois la conséquence d’un mauvais schéma, d’un serveur mal régléou tout simplement d’index mal ou pas utilisé du tout.

MySQL vous offre la possibilité d’identifier ce type de requêtes grâce à son journaldes requêtes lentes.

Principe de fonctionnementPour activer le journal des requêtes lentes (car il ne l’est pas par défaut), il suffit deplacer dans le fichier de configuration, dans la section [mysqld] l’optionslow_query_log. Il est de plus conseillé, même si cela n’est pas obligatoire, de spéci-fier son nom (et éventuellement son chemin) à l’aide de l’option general_log_file.

090814 11:28:29 [ERROR] /usr/local/mysql/5.1.35/bin/mysqld: Table './test/City' is marked as crashed and should be repaired090814 11:28:29 [Warning] Checking table: './test/City'090814 11:28:29 [Warning] Recovering table: './test/City'

090814 11:05:09 [ERROR] /usr/local/mysql/5.1.35/bin/mysqld: Table './test/City' is marked as crashed and should be repaired090814 11:05:09 [ERROR] /usr/local/mysql/5.1.35/bin/mysqld: Incorrect key file for table './test/City'; try to repair it090814 11:05:09 [ERROR] Couldn't repair table: test.City

ATTENTION Effets de bord de l’option myisam_recover

Avec l’option myisam_recover, le serveur MySQL risque de mettre beaucoup plus de temps pourdémarrer.



149

Au redémarrage du serveur, toutes les requêtes plus lentes que le paramètrelong_query_time y seront insérées. La valeur de long_query_time est de 10 secondespar défaut ; il est évidemment possible de lui donner une autre valeur, avec une préci-sion de l’ordre de la microseconde.

Une autre option, bien pratique, permet de journaliser les requêtes qui n’utilisent pasd’index ; il s’agit de log_queries_not_using_indexes. Ces requêtes seront inscritesdans le journal des requêtes lentes, même si leur durée d’exécution n’est pas pluslongue que long_query_time :

Activer le journal des requêtes lentes

Deux autres filtres peuvent vous intéresser. Tout d’abord, min_examined_row_limitpermet de définir le nombre d’enregistrements minimal que doit examiner la requêtepour qu’elle puisse être stockée dans le journal. Ce paramètre peut vous permettred’obtenir une journalisation moins verbeuse, donc un fichier qui grossit moins vite.Ensuite, log-slow-admin-statements server vous donne la possibilité d’enregistrerles longues commandes d’administration, telles que OPTIMIZE TABLE, ALTER TABLE...

Vous venez de le voir : activer le journal implique de modifier le fichier de configurationet par conséquence un redémarrage du serveur MySQL. Cette manipulation peut doncêtre assez gênante dans un environnement de production. À partir de MySQL 5.1, lejournal peut être activé dynamiquement (à chaud) avec la commande SET GLOBAL.

Comme pour tous les changements à chaud cette modification n’est pas persistante,c’est-à-dire qu’en cas de redémarrage du serveur, la nouvelle valeur est perdue. Pourrendre ce changement permanent, une astuce consiste à changer le paramètre dyna-miquement et à le placer dans le fichier de configuration, comme exposé ci-dessus.

[mysqld]# Activer la journalisation des requêtes lentesslow_query_logslow_query_log_file = /appli/log/mysql-slow.loglong-query-time = 2log_queries_not_using_indexes

ATTENTION Effets de bord de l’option log_queries_not_using_indexes

Votre journal peut devenir très verbeux. Parfois, il est moins coûteux à l’optimiseur de choisir d’analyserentièrement la table (full table scan) que d’utiliser un index. Par conséquent, les requêtes journaliséesavec l’option log_queries_not_using_indexes, ne seront pas forcément toutes des requêtesproblématiques. Aucun des auteurs de ce livre ne l’active habituellement.



Attention cependant à ne pas vous tromper dans la syntaxe du paramètre, parce qu’àla moindre erreur, le serveur ne redémarerra pas !

Voici un exemple de journal des requêtes lentes :

Comme vous pouvez le constater, la requête n’est pas la seule information contenue.On y retrouve d’autres informations utiles telles que :� le moment et l’heure de l’insertion de la requête dans le fichier ;� l’utilisateur qui a exécuté la requête ;� le temps d’exécution de la requête ;� la durée pendant laquelle la ressource (la table), est verrouillée. À noter que ce

temps d’attente n’est pas comptabilisé dans la durée de la requête ;� le nombre d’enregistrements renvoyés par la requête ;� le nombre d’enregistrements traités ;� le timestamp où la requête a été enregistrée dans le fichier ; la requête lente proprement dite. L’ordre des requêtes dans le journal des requêtes

lentes ne correspond pas forcément à leur ordre d’exécution.

La structure du fichier est finalement assez simple. En revanche, dans l’environne-ment de production, il peut devenir assez volumineux et y rechercher une informa-tion peut s’avérer fastidieux.

MySQL fournit un script Perl, nommé mysqldumpslow. Cet outil facilite l’analysedu journal des requêtes lentes en regroupant les requêtes par type et en donnant quel-ques informations, comme le temps d’exécution ou encore le nombre de fois que cetype de requêtes apparaît dans le journal. Cette dernière façon de classer les com-mandes est intéressante car il faut garder à l’esprit qu’une requête longue n’est pasforcement un problème (tâche de maintenance, table bien indexée mais particulière-ment volumineuse) si elle s’exécute rarement. Cela dit, une requête plus rapide maisqui s’exécute très souvent peut être une excellente candidate à l’optimisation.

mysql> SET GLOBAL slow_query_log=ON;

� # Time: 090819 17:39:03� # User@Host: daz[daz] @ localhost []� # Query_time: 0.182724 � Lock_time: 0.000176 � Rows_sent: 2 � Rows_examined: 39034� SET timestamp=1250696343; SELECT c.Name,Language FROM City as c JOIN CountryLanguage USING(CountryCode) WHERE IsOfficial='T' ORDER BY c.name,rand() DESC LIMIT 2;



151

Par défaut, mysqldumpslow va classer les informations du journal par types derequêtes. C’est-à-dire qu’il va remplacer les valeurs numériques par la lettre N (number)et les valeurs chaînes de caractères par la lettre S (string). Il donne également :• le nombre d’occurrences ;• les durées moyennes et totales d’exécution ;• les durées moyennes et totales des verrous ;• la moyenne et le total du nombre d’enregistrements traités ;• le compte utilisateur.

Quel que soit l’outil utilisé, les instructions SELECT identifiées peuvent être optimi-sées avec la commande EXPLAIN afin de vérifier que les index sont correctement uti-lisés et pertinents.

shell> mysqldumpslow mysql-slow.log Reading mysql slow query log from mysql-slow.log Count: 10 Time=15.30s (153s) Lock=0.00s (0s) Rows=0.0 (0), daz[daz]@daz_server.fr UPDATE 3_msg SET etat='S', notif='S', id_int='S' WHERE id_msg=N

Count: 2 Time=12.00s (24s) Lock=0.00s (0s) Rows=0.0 (0), daz[daz]@daz_server.fr SELECT * FROM 1_msg WHERE etat not in ('S', 'S') LIMIT N

Count: 1 Time=5.00s (5s) Lock=0.00s (0s) Rows=0.0 (0), daz[daz]@daz_server.fr TRUNCATE 3_msg

Count: 30653 Time=4.01s (122902s) Lock=0.00s (1s) Rows=0.0 (0), daz[daz]@daz_server.fr SELECT * FROM 5_msg WHERE unix_timestamp(last_notif) < (N -N) and last_notif!='S' and id_canal='S' and (etat!='S' and etat!='S')

Vous trouverez plus de précisions sur mysqldumpslow et notamment l’impact des différentes optionsdans la documentation de MySQL :B http://dev.mysql.com/doc/refman/5.1/en/mysqldumpslow.html

ALTERNATIVE Autres outils d’analyse

D’autres outils permettent d’analyser les journaux des requêtes lentes : mysqlsla, mysql_slow_log_filteret mysql_slow_log_parser :B http://hackmysql.com/mysqlslaB http://www.mysqlperformanceblog.com/files/utils/mysql_slow_log_filterB http://www.mysqlperformanceblog.com/files/utils/mysql_slow_log_parser



Cependant, il faut noter qu’améliorer la vitesse des commandes SELECT en ajoutantdes index sur une table peut avoir comme effet collatéral un ralentissement des per-formances d’écriture de cette table. En ce qui concerne les requêtes UPDATE et DELETE,une astuce consiste à prendre leur clause WHERE et à la placer à la suite d’un SELECT *.

Journaliser dans une tableActiver ou désactiver la journalisation requiert une intervention dans le fichier deconfiguration et un redémarrage du serveur. En d’autres termes, ces changementss’effectuent à froid. À partir de MySQL 5.1.6, toutes ces manipulations peuvents’opérer à chaud. De plus, MySQL vous donne la possibilité de journaliser lesrequêtes lentes dans la table système mysql.slow_log. Le paramètre log_outputpermet de choisir entre stocker les données dans une table ('TABLE'), dans un fichier('FILE') dans les deux ('FILE,TABLE') ou dans aucun des deux ('NONE').

La structure de la table mysql.slow_log est très proche de celle du fichier journal desrequêtes lentes. Cependant la précision du temps est moins fine dans la table quedans le fichier (par exemple, 1,053634 seconde dans le fichier sera représenté par00:00:01 dans la table). Notez que cette table n’est accessible qu’en lecture. Pour lavider, utilisez la seule commande possible ici : TRUNCATE TABLE.

mysql> UPDATE client SET client_name = 'karen' WHERE id = 4 /* requête à optimiser */mysql> EXPLAIN SELECT * FROM client WHERE id = 4 /* astuce d'optimisation */

mysql> SET GLOBAL slow_query_log = 'ON'; -- active le journal des requêtes lentes

mysql> SET GLOBAL log_output = 'TABLE'; -- sauvegarde les informations du journal des requêtes lentes dans la table mysql.slow_log

mysql> SET GLOBAL log_queries_not_using_indexes = 'OFF'; -- désactive la journalisation des requêtes n'utilisant pas d'index

mysql> SELECT * FROM mysql.slow_log;

*************************** 1. row *************************** start_time: 2009-08-28 17:16:35 user_host: daz[daz] @ localhost [] query_time: 00:00:01lock_time: 00:00:00 rows_sent: 1 rows_examined: 211479



153

Le journal général des connexions et requêtesLe journal général (general log) permet d’enregistrer toute l’activité du serveur. Ilstocke les informations relatives à la connexion et à la déconnexion des clients ainsique toutes les requêtes et toutes les commandes qui arrivent au processus mysqld,qu’elles soient valides ou non.

L’intérêt d’un tel journal se situe particulièrement dans les phases d’optimisation, pen-dant l’audit du serveur ou encore lorsqu’on souhaite identifier un problème venant del’application. Ce fichier peut grossir très rapidement sur une machine qui subit uneforte charge. Par conséquent, il peut, de par sa lourdeur, rapidement devenir inexploi-table. En effet, rares sont les éditeurs de texte qui permettent de manipuler avec aisancedes fichiers de plusieurs dizaines ou centaines de mégaoctets.

Un autre inconvénient, et non des moindres, vient du fait que l’activation du journalgénéral représente une charge de travail supplémentaire pour la machine, essentielle-ment au niveau des E/S. Cette surcharge dépend bien évidemment de l’application etdes caractéristiques de la machine. Néanmoins celle-ci peut être estimée, lorsque la jour-nalisation s’effectue dans un fichier, à environ 30 %. Il est donc fortement conseillé de nel’activer que de façon ponctuelle, dans les phases d’audit, d’optimisation, de débogage...

Une utilisation assez originale consiste à placer des commentaires dans des requêtes.Les développeurs connaissent les bienfaits des ces commentaires qui permettent dedocumenter leur code. Un autre intérêt est de s’en servir pour tracer les requêtes quideviennent ainsi plus faciles à repérer dans la jungle de votre journal :

db: sakila last_insert_id: 0 insert_id: 0 server_id: 1 sql_text: SELECT * FROM actor a, actor_info ai, film_actor f WHERE a.actor_id = ai.actor_id AND f.actor_id=a.actor_id ORDER BY RAND () LIMIT 1

mysql> TRUNCATE TABLE mysql.slow_log; -- vide entièrement la table

mysql> SELECT /*!99999 liste des villes de France */ name FROM City WHERE countrycode ='fra';

shell> cat mysql.logTime Id Command Argument090908 21:18:31 1 Connect daz@localhost on world1 Query show databases



À l’instar du journal des requêtes lentes, il est possible de stocker ces informations dansune table système (mysql.general_log) et le journal peut être activé ou désactivé àchaud respectivement grâce aux commandes SET GLOBAL general_log = 'ON' et SETGLOBAL general_log = 'OFF'. Le chemin et le nom du journal sont indiqués par lavariable general_log_file, sinon le nom par défaut du fichier estnom_de_la_machine.log et il est situé dans le répertoire de données data. Il est égale-ment possible, pour une session, de l’activer ou le désactiver avec le paramètresql_log_off.

C’est le même paramètre, utilisé avec le journal des requêtes lentes, log_output, quiva permettre de choisir la destination du contenu du journal dans une table, unfichier, dans une table et dans un fichier ou pas de journalisation (respectivement'TABLE', 'FILE', 'FILE,TABLE' et 'NONE'). Le stockage de ces données dans la tablemysql.general_log, entraîne une surcharge d’environ 50 % pour le serveur.

Exemples d’utilisations de la journalisation générale ?Ce journal peut vous aider à analyser plus finement le fonctionnement (ou les dys-fonctionnements) de votre application. Certains l’utilisent par exemple pour définirla fréquence des différents types de requêtes de leur application, calculer des ratiosdes requêtes SELECT simples par rapport aux SELECT complexes (qui pourraient êtresimplifiées), mais également pour repérer les requêtes les plus fréquentes qui nécessi-tent donc un temps d’exécution le plus court possible, ou enfin pour reconstituerl’historique d’un serveur quelques instants avant un arrêt brutal, etc.

Un autre intérêt de la journalisation générale consiste à récupérer des requêtes en vue degénérer un jeu de tests réaliste ou pour juger de leur niveau d’optimisation avec la com-mande EXPLAIN. Certains clients sensibles à la sécurité des données s’en servent pourtracer les utilisateurs, en d’autres termes savoir qui a fait quoi et quand (cependant seull’identifiant id de la connexion se trouve dans le journal). De façon plus générale, vouspourrez y suivre toutes les requêtes et commandes non stockées dans les autres journaux.

Il existe un outil d’analyse pour le journal général : mysqlsla (documentation et télé-chargement à l’adresse : http://hackmysql.com/mysqlsla).

1 Query show tables1 Field List City 1 Field List Country 1 Field List CountryLanguage 1 Query SELECT /*!99999 liste des villes de France */ name FROM City WHERE countrycode ='fra'



155

Voici une petite astuce pour changer le journal (tirée de la documentation de MySQL) :

La journalisation binaireLes trois types de journaux étudiés précédemment ont comme point commun d’êtreau format texte. Ce n’est pas le cas du journal binaire qui, comme son nom l’indique,est au format binaire. Il a principalement deux buts : permettre le fonctionnement dela réplication (cette partie est détaillée au chapitre 8) et remettre la base en état aprèsun incident avec un niveau de restauration très fin.

Il remplit ses différents rôles en enregistrant toutes les requêtes d’écritures validéesqui arrivent sur le serveur MySQL. Notez que, contrairement au journal général, larequête y est certes inscrite à la fin de son exécution, mais avant que les verrous nesoient relâchés. Ceci assure que l’ordre des requêtes dans le journal binaire est bienl’ordre dans lequel elles ont été validées. Les requêtes de lectures comme SELECT,SHOW… n’étant pas pertinentes pour une restauration des données ne sont donc passtockées. Une exception cependant : les requêtes du genre CREATE TABLE … SELECT …ou encore INSERT… SELECT… *, elles, sont stockées (sauf si le paramètrebinlog_format est fixé à ROW).

À l’instar des autres journaux, activer la journalisation binaire implique un surcoûtpour le serveur. Autant être clair, ce surcoût d’environ 1 % est négligeable par rapportaux avantages qu’apporte son activation. Il est possible d’agir avec le paramètresync_binlog sur le nombre d’accès disques causés par la journalisation binaire.Lorsque ce paramètre vaut 0 (sa valeur par défaut), MySQL ne synchronise pas lecache du journal binaire avec son fichier. En d’autres termes, il y a un gain de perfor-mance, car les accès disque sont minimisés ; en revanche, il y a plus de risques depertes de données en cas d’arrêt brutal, puisque les dernières transactions validéesn’auront sans doute pas eu le temps d’être écrites sur le disque, et donc de devenirpersistantes. Sauf contraintes de performances particulières, nous vous conseillons dechoisir sync_binlog = 1.

shell> mv ma_machine.log ma_machine-old.logshell> mysqladmin flush-logsshell> cp ma_machine.log /sauvegarde/shell> rm ma_machine-old.log

REMARQUE L’option sync_binlog peut avoir un impact sur les performances

Si vous fixez sync_binlog =1, testez et surveillez le serveur après avoir réglé sa valeur. Il peut neplus être en mesure de tenir de fortes charges.



L’activation du journal s’effectue dans le fichier de configuration avec l’option log-bin. Il n’est cependant pas possible de l’activer à chaud. En revanche, une fois quevous l’avez activé, vous avez la possibilité, mais seulement pour la session courante,de le désactiver sans redémarrer le serveur grâce à la variable sql_log_bin. Cela peutêtre utile, par exemple, pour exécuter une requête de maintenance sur un serveur etne pas vouloir la journaliser.

Le journal binaire se reconnaît facilement grâce à son extension qui est composée de6 chiffres. Le tout premier journal créé se termine par .000001, le suivant par.000002, puis .000003, et ainsi de suite. C’est un fichier dit incrémental : le serveurferme le fichier courant pour en ouvrir un autre. Ce changement de numéros a lieulorsqu’une des 3 conditions suivantes survient :1 si la commande FLUSH LOGS est executée ;2 si la taille du fichier atteint la valeur de la variable max_binlog_size (taille maxi-

male de 1 Go) ;3 si le serveur MySQL redémarre.

La commande SHOW BINARY LOGS permet d’obtenir la liste de tous les journauxbinaires du serveur. SHOW MASTER STATUS affiche un tableau avec le nom du journalbinaire courant ainsi que d’autres informations utiles, notamment pour la réplication(consultez le chapitre 8 traitant de la réplication). Il n’y a pas de processus automa-tique, tel un garbage collector, pour supprimer les anciens fichiers. Vous disposezcependant de deux méthodes pour y parvenir. Utilisez la commande PURGE BINARYLOGS qui permet de purger des journaux binaires soit en se basant sur leurs numérossoit sur leur date de création. L’autre méthode consiste à employer le paramètre ser-veur expire_logs_days en lui fournissant un nombre de jours. Ce dernier peut êtredéfini dynamiquement.

La commande RESET MASTER est une autre commande utile, beaucoup plus radicale,car elle permet de réinitialiser la journalisation binaire, c’est-à-dire de supprimer tousles fichiers et de repartir avec un journal en .000001.

mysql> SET SESSION sql_log_bin = 'OFF';mysql> OPTIMIZE TABLE client;mysql> SET SESSION sql_log_bin = 'ON';

mysql> SET GLOBAL expire_logs_days = 7; /* efface automatiquement les journaux binaires vieux de plus de 7 jours*/mysql> PURGE BINARY LOGS BEFORE now() - INTERVAL 1 WEEK; /* efface tous les journaux binaires vieux de plus de 7 jours*/mysql> PURGE BINARY LOGS TO 'mysql-bin.000010';/* efface tous les journaux binaires de .000001 à .000009 */



157

Visualiser le journal peut être effectué avec la commande SHOW BINLOG EVENTS IN.L’autre méthode est d’utiliser mysqlbinlog. C’est également l’outil employé pour res-taurer une base à partir des journaux binaires ou pour effectuer du Point In TimeRecovery (PITR).

Les données du journal sont stockées de 3 façons différentes :• sous la forme de requêtes (STATEMENT) ;• sous la forme de données générées par les enregistrements (ROW) ;• sous un format qui mélange les deux formes précédentes en fonction du contexte

et du type de requêtes (MIXED).

Le choix est effectué à l’aide du paramètre binlog_format et peut être modifié dyna-miquement pour la session comme pour tout le serveur. Le mode de journalisationhistorique est STATEMENT. Il est éprouvé depuis les versions 3.23 de MySQL et estdonc naturellement le mode préféré des administrateurs de base de données. Cepen-dant, il présente l’inconvénient de ne pas permettre la journalisation des requêtescontenant des instructions non déterministes. Par exemple, exécuter une requêtecontenant la fonction uuid() génère un avertissement (warning) de la part du ser-veur, car en cas de réplication ou de restauration en mode STATEMENT, MySQLrejouera la requête et le résultat sera fatalement différent. En revanche, cela n’auraitpas posé de problème en mode ROW. Notez qu’en mode MIXED, MySQL passe auto-matiquement en ROW pour ce type de requêtes.

TRANCHE DE VIE La technique de Point In Time Recovery en pratique

Imaginez qu’un développeur imprudent supprime, par mégarde, sur le serveur deproduction, la table contenant les clients de votre application à 12 heures. La der-nière sauvegarde a été effectuée à 3 heures du matin et l’information de l’incidentremonte aux oreilles de l’administrateur des bases de données à 13 heures. La procé-dure classique, après avoir remonté les bretelles du développeur, est de restaurer ladernière sauvegarde (en espérant qu’elle soit valide). Résultat : plus de 10 heures detransactions de perdues !Grâce aux journaux binaires, après avoir restauré la sauvegarde, vous pourrez remon-ter jusqu’à la requête précédent l’incident (la commande DROP TABLE de 12 heures),en rejouant tout simplement les requêtes du journal. Plus intéressant encore, il esttout autant possible de rejouer les requêtes survenues après l’incident, c’est-à-dire de12 à 13 heures. Il faut juste prendre soin de ne pas rejouer l’instruction DROP TABLE.Bien entendu, les requêtes concernant la table des clients ayant échoué après12 heures ne sont pas dans le journal et ne sont donc pas restituables.



Pour être complet, le format STATEMENT a pour avantage d’être en général plus petit etmoins gourmand en espace disque et en transfert réseau que le format ROW. Commenous l’avons vu, il est également plus mature ; c’est donc ce format de journalisationque nous vous conseillons. Cependant, toutes les requêtes ne peuvent pas être répli-quées et la structure des tables doit être la même.

Du format de journalisation choisi dépendent la lisibilité des événements dans lejournal binaire et donc la facilité avec laquelle le PITR ou toute autre manipulationdu contenu du journal va pouvoir s’effectuer. Examinez comment MySQL journalisela requête d’écriture suivante :

mysql> SHOW VARIABLES LIKE 'binlog_format' \G*************************** 1. row *************************** Variable_name: binlog_format Value: STATEMENT

mysql> INSERT INTO client (client_id, nom) VALUES (uuid(),'Orianne'); Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> SHOW WARNINGS \G*************************** 1. row *************************** Level: Note Code: 1592 Message: Statement is not safe to log in statement format.

mysql> SET SESSION binlog_format='ROW';

mysql> SHOW VARIABLES LIKE 'binlog_format' \G*************************** 1. row *************************** Variable_name: binlog_format Value: ROW

mysql> INSERT INTO client (client_id, nom) VALUES (uuid(),'Orianne');Query OK, 1 row affected (0.00 sec)

INSERT INTO `Ville` VALUES (2974,'Paris','FRA',2125246);

REMARQUE Taille du journal binaire en fonction du mode de journalisation

La taille des journaux binaires dépend également du type de requêtes et non simplement du format dejournalisation. Si l’application mène beaucoup de requêtes qui modifient peu de données, les fichiers enmode ROW seront alors plus petits.



159

Avec binlog_format='STATEMENT' :

Avec binlog_format='ROW' :

Cependant, avec l’option verbose de mysqlbinlog, la sortie, malgré le format ROW, estun peu plus lisible :

shell> mysqlbinlog msandbox-bin.000037 ...# at 431 #090907 21:43:29 server id 1 end_log_pos 549 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1252352609/*!*/; INSERT INTO `Ville` VALUES (2974,'Paris','FRA',2125246)...

shell> mysqlbinlog msandbox-bin.000038 ...# at 174 # at 225 #090907 21:45:57 server id 1 end_log_pos 225 Table_map: `test`.`Ville` mapped to number 33 #090907 21:45:57 server id 1 end_log_pos 273 Write_rows: table id 33 flags: STMT_END_F

BINLOG ' 9WKlShMBAAAAMwAAAOEAAAAAACEAAAAAAAAABHRlc3QABVZpbGxlAAQD/v4DBP4j/gMA 9WKlShcBAAAAMAAAABEBAAAQACEAAAAAAAEABP/wngsAAAVQYXJpcwNGUkG+bSAA '/*!*/; # at 273 …

shell> mysqlbinlog --verbose msandbox-bin.000038...# at 174 # at 225 #090907 21:45:57 server id 1 end_log_pos 225 Table_map: `test`.`Ville` mapped to number 33 #090907 21:45:57 server id 1 end_log_pos 273 Write_rows: table id 33 flags: STMT_END_F

BINLOG ' 9WKlShMBAAAAMwAAAOEAAAAAACEAAAAAAAAABHRlc3QABVZpbGxlAAQD/v4DBP4j/gMA 9WKlShcBAAAAMAAAABEBAAAQACEAAAAAAAEABP/wngsAAAVQYXJpcwNGUkG+bSAA '/*!*/; ### INSERT INTO test.Ville ### SET



Bonnes pratiquesCe chapitre a présenté les principaux journaux serveur ainsi que leurs différentes uti-lisations. Cependant les activer n’est pas anodin car ils peuvent avoir un impact nonnégligeable sur les performances du serveur MySQL. Une bonne façon de voir leschoses est de se demander, pour chacun d’entre eux, si vous en avez l’utilité. Pourvous aider à choisir, voici la configuration que nous vous recommandons :• Activer le journal binaire : il servira pour la restauration des données, PITR et

autres sauvegardes incrémentales ainsi que pour la réplication.• Activer le journal des requêtes lentes, utile pour démasquer les requêtes candida-

tes à l’optimisation. Prenez garde à ne pas fixer une valeur long_query_time troppetite sous peine d’augmenter la charge de travail du serveur.

• Ne pas activer le journal général, sauf dans les phases d’audit ou d’optimisation.C’est le journal le plus coûteux pour le serveur.

Un autre point très important est de penser à protéger l’accès à vos fichiers. Ces der-niers étant capables de stocker les requêtes telles quelles, des informations sensiblescomme les mots de passe peuvent être récupérées par des personnes mal intentionnées.

### @1=2974 ### @2='Paris' ### @3='FRA' ### @4=2125246 # at 273 ...

Tableau 5–1 Récapitulatifs des modes de journalisation

MODE STATEMENT MODE ROW

Ancienneté À partir de MySQL 4.1.3 À partir de MySQL 5.1.5

Taille (relative) des journaux Moins importante Plus importante

Limitations de la réplication Les requêtes non déterministes ne sont pas répliquées

Aucune

Efficacité (relative) Update ... SET col=x (plus efficace) qu'au format ROW

Insert... Select... (plus efficace) qu'au format STATEMENT

PITR Oui Possible mais plus complexe

Compatibilité liée à la réplication

Les versions à partir de 4.1.3 Seulement les versions à partir de 5.1.5



161

Les journaux peuvent contenir des informations sensibles en clair

mysql> CREATE USER freshdaz@localhost identified by 'S3cr37';

shell> tail mysql.log 090908 20:40:38 1 Query CREATE USER freshdaz@localhost identified by 'S3cr37'

shell> mysqlbinlog mysql-bin.log.000042# at 106 #090908 20:40:38 server id 1 end_log_pos 212 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1252435238/*!*/; ...CREATE USER freshdaz@localhost identified by 'S3cr37'



Les performances de votre application auront un impact fort sur la qualité de serviceet sur la satisfaction des utilisateurs. Être plus rapide, offrir de meilleurs services outout simplement être moins cher sont des critères qui peuvent vous permettre degarder une longueur d’avance sur vos concurrents. Dans beaucoup de secteurs d’acti-vités, c’est le client qui décide in fine de la pérennité du service. Par conséquent, vousvous devez de le choyer car un client mécontent est difficile à reconquérir. Vousdevez alors être en mesure d’anticiper, d’identifier et de régler tout problème sur labase de données. Vous devez également être capable de la paramétrer finement afind’optimiser ses performances parce qu’elle est un élément crucial, qu’il faut com-prendre et dompter dès sa conception. Enfin, il vous faut l’accompagner pour l’aiderà grandir à travers l’évolution de votre application.

Conception de la base de donnéesUn immeuble avec de piteuses fondations sera plus vulnérable aux intempéries ou àl’épreuve du temps. Ce principe évident peut être transposé à la base de données. Eneffet une conception bâclée, souvent réalisée dans un souci de gain de temps, ou toutsimplement pour cause d’incompétences risque de vous emmener dans des cheminssinueux qui débouchent très souvent vers une impasse technique ou financière. Uneconception mal pensée peut engendrer une multitude de problèmes allant de requêtes

6Optimiser sa base de données :

du schéma aux requêtes



difficilement optimisables au manque d’évolutivité du schéma en passant par les pro-blématiques de cohérence des données.

Il n’y a pas de schémas idéaux ; en revanche, il est très facile d’en créer un mauvais.Les causes peuvent alors être multiples.• Les tables sont créées au fur et à mesure des besoins, sans vision d’ensemble.• L’utilisation d’un framework, bien qu’utile au développement pour économiser du

temps et de l’argent, peut créer un schéma générique peu ou pas adapté auxbesoins de performances du système.

• Le cahier des charges a évolué et l’application est utilisée d’une façon différentede celle prévue lors de l’expression des besoins.

• Les prévisions de charges et de volumétries ont été mésestimées et il y a plus detrafic ou de données que prévu...

Normalisation/dénormalisationLe salut est dans la modélisation et la normalisation. Ces deux points pourraient fairel’objet d’un ouvrage à part entière mais nous ne les aborderons que dans les grandeslignes.

Modéliser est un processus qui permet de structurer et d’organiser les données. Sesobjectifs sont de maintenir l’intégrité référentielle, de s’assurer que les données res-tent faciles à maintenir et ne sont pas redondantes. Pour modéliser, il faut com-mencer par créer un modèle conceptuel de données (MCD) en dessinant les entitéset leurs relations. Ce diagramme est une carte qui représente le métier et s’avère trèsutile pour échanger avec les autres acteurs du projet. Le MCD conduit ensuite àcréer le modèle logique de données (MLD). Ce modèle représente le plan, la carto-graphie des données. Enfin, la construction du modèle physique de données (MPD)consiste à transformer le modèle logique pour l’adapter au SGBDR cible.

BON À SAVOIR La normalisation

La normalisation a été créée par Edgar Frank Codd, dans les années 1970. Elle est basée sur le principemathématique de la théorie des ensembles. Son but est notamment d’éliminer tout doublon au niveaudes données et d’assurer leur intégrité. Il y a huit degrés de normalisation, appelés formes normales,mais respecter les trois premières formes suffit pour être normalisé (3FN ou 3NF en anglais). Cette étapeest très importante pour garantir la robustesse de la base de données. Être normalisé permet d’optimiserles jointures qui comptent parmi les opérations les plus coûteuses, en minimisant le nombre de donnéestraitées. Avec un schéma normalisé, la sélection du plan d’exécution optimal, par l’optimiseur, estfacilitée : il y a moins de données à analyser et les requêtes de mises à jour n’ont qu’une occurrence àtraiter au lieu de plusieurs.


Optimiser sa base de données : du schéma aux requêtesCHAPITRE 6

165

Il n’y a cependant pas que des avantages : un schéma normalisé contient souventbeaucoup de tables et une information est souvent répartie sur plusieurs d’entre elles,ce qui peut avoir un impact non négligeable sur les performances. C’est la raison pourlaquelle, une fois la phase de normalisation terminée, il est parfois nécessaire dedénormaliser une partie du schéma pour espérer de meilleures performances. Unvieux maître DBA a dit un jour : « Normalisez jusqu’à ce que cela fasse mal, dénor-malisez jusqu’à ce que cela marche ! ».

En dénormalisant, le but recherché est donc la performance. Une des techniques lesplus utilisées est d’ajouter de la redondance. Pour cela, il existe plusieurs méthodes,exposées ci-après.

Ajouter des colonnes dans une table• Ajouter une clé primaire fonctionnelle (client_id) avec une taille d’un coût

moindre que celle de la clé primaire candidate (code). Cela peut permettre deminimiser les I/O (vous trouverez davantage de détails dans quelques paragra-phes). Notez, dans l’exemple qui suit, l’ajout de la contrainte d’unicité sur lechamp code pour assurer l’intégrité des données.

Table originale

Table dénormalisée

OUTILS Logiciels de modélisation

Un bon nombre d’outils existe pour vous aider à concevoir les différents modèles :• DBDesigner : http://www.fabforce.net/dbdesigner4/• MySQL workbench : http://www.mysql.fr/products/workbench/• CA ERWin : http://www.ca.com/us/data-modeling.aspx• Embarcadero : http://www.embarcadero.com/

mysql> CREATE TABLE client ( code char(255) NOT NULL, nom char(50) NOT NULL, PRIMARY KEY (code));

mysql> CREATE TABLE client ( client_id mediumint unsigned NOT NULL, code char(255) NOT NULL, nom char(50) NOT NULL, PRIMARY KEY (client_id), UNIQUE KEY (code));



• Ajouter une colonne calculée TTC, en plus de la colonne HT, qui contient lerésultat de HT + TVA.

Table originale


• Ajouter une colonne de type ENUM en remplacement d’une colonne clé étrangère.

Table originale


Création de tables d’agrégationLa création de tables d’agrégation (data snapshot ou resume tables), c’est-à-direde tables qui contiennent les résultats d’une (ou plusieurs) requête sur d’autres tables,permet d’économiser le temps de calcul du résultat.

mysql> CREATE TABLE article ( article_id mediumint unsigned NOT NULL, prix_article_ht decimal(5,2) DEFAULT NULL, tva_id tinyint unsigned DEFAULT NULL, PRIMARY KEY (article_id));

mysql> CREATE TABLE article ( article_id mediumint unsigned NOT NULL, prix_article_ht decimal(5,2) NOT NULL, tva_id tinyint unsigned NOT NULL, prix_article_ttc decimal(5,2) NOT NULL, PRIMARY KEY (article_id));

mysql> CREATE TABLE pays ( code char(3) NOT NULL, nom char(60) NOT NULL, continent_id tinyint unsigned NOT NULL, PRIMARY KEY (code));

mysql> CREATE TABLE pays ( code char(3) NOT NULL, nom char(60) NOT NULL, continent enum('Asie','Europe','Ameriques','Afrique') NOT NULL, PRIMARY KEY (code));



167

Création de schémas orientésIl s’agit de créer des schémas orientés OLAP (Online Analytical Processing), entrepôtsde données comme le schéma en étoile ou le flocon de neige.

Le rapport normalisation/dénormalisation va également dépendre du type d’applica-tion, orientée OLTP ou OLAP (entrepôts de données).

Des types de données ajustésUn autre point à prendre en compte est le type des données. MySQL propose unelarge panoplie de types pour stocker les nombres (tinyint, integer, bigint...),chaînes de caractères (char, varchar, text), nombres réels (float, double), etc.L’intérêt de ce large choix est de pouvoir optimiser le stockage des données. Les cri-tères sont fonction de la plage de valeurs des données à stocker et de l’espace occupépar chaque type.

Voici nos recommandations particulières.• Placez systématiquement NOT NULL pour toutes les colonnes qui ne stockent pas

de valeurs NULL.Ces dernières induisent des traitements supplémentaires et compliquent la tâchede l’optimiseur. En indiquant que la colonne ne contiendra pas de valeurs NULL,vous affranchissez le serveur de ce surcoût. NULL doit donc être un choix !

• Utilisez le type adéquat.Ne stockez pas vos entiers en tant que chaînes de caractères ('1' à la place de 1),la conversion a un coût.

• Utilisez la bonne taille de type.Pour stocker l’âge d’une personne, TINYINT UNSIGNED suffit et est quatre foismoins coûteux que INT (http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html).N’utilisez pas CHAR(255) si CHAR(50) suffit. Au-delà du gain de place évident, desdonnées plus petites prendront moins de place en mémoire (buffers, caches, tables

Tableau 6–1 OLTP vs OLAP

OLTP OLAP

Normalisé Oui, avec une structure complexe (3NF) Peu ou pas, avec une structure multi-dimension

Index Peu Beaucoup

Jointures Beaucoup Quelques unes

Doublons Non (ou peu) Oui

Tables d’agrégation Rare Commun



temporaires) et le serveur pourra en stocker davantage, ce qui a pour conséquencede minimiser les I/O.

• Les types de données des clés étrangères doivent être identiques à ceux des clésprimaires.Cette règle doit être étendue aux champs des critères de jointures. La jointurefonctionnera mais MySQL sera alors obligé de convertir l’un des deux champsdans le type de l’autre.

• Attention aux jeux de caractères.Une table MyISAM statique (fixed) en utf-8 occupera environ trois fois plusd’espace que la même table en latin-1. En dynamique les tailles seront équivalentes.

Il existe une commande pour vous aider à choisir le type optimal : il s’agit dePROCEDURE ANALYSE. Cette procédure qui s’utilise avec une requête SELECT va analyserle contenu d’une table pour chacune des colonnes choisie, et afficher un rapport conte-nant des statistiques ainsi que le type optimal suggéré. Dans l’exemple qui suit, la pro-cédure analyse les colonnes customer_id, first_name et email de la table customer.

Gardez à l’esprit que le type optimal proposé n’est qu’une suggestion à un instantdonné : vous devez vous demander s’il est applicable dans votre contexte. Parexemple, la procédure propose pour la colonne first_name, une liste énumérée detoutes les valeurs présentes au moment de l’analyse (ENUM('AARON','ADAM',...) )comme type optimal. Dans ce cas de figure, cela n’a pas de sens car la liste des clientsest amenée à évoluer. Le type varchar est donc bien mieux adapté.

Affichage des résultats de la commande PROCEDURE ANALYSE()

MÉTHODE Un type optimal à un moment donné

Gardez à l’esprit que le type optimal proposé n’est qu’une suggestion à un instant donné : vous devezvous demander s’il est applicable dans votre contexte. Par exemple, la procédure propose pour lacolonne first_name, une liste énumérée de toutes les valeurs présentes au moment de l’analyse(ENUM('AARON','ADAM',...) ) comme type optimal. Dans ce cas de figure, cela n’a pas de senscar la liste des clients est amenée à évoluer. Le type varchar est donc bien mieux adapté.

mysql> SELECT customer_id, first_name, email FROM sakila.customer PROCEDURE ANALYSE()\G*************************** 1. row *************************** Field_name: sakila.customer.customer_id Min_value: 1 Max_value: 599 Min_length: 1 Max_length: 3 Empties_or_zeros: 0



169

Les jointuresAvant d’aller plus loin, un rappel sur les jointures nous paraît opportun.

Une base de données relationnelle permet d’organiser et de stocker des données sousla forme de tables liées entre elles par des relations. Dans de nombreux cas, uneinformation est répartie sur plusieurs tables et pour la récupérer en une seule requête,il faut effectuer une jointure. La jointure est une opération qui consiste a combiner(joindre) les enregistrements de deux tables pour en créer une nouvelle et la joindre àune autre, ainsi de suite jusqu’à la dernière, puis à l’afficher.

Prenons comme exemple les deux tables membres et profession avec la structuresuivante :

Nulls: 0 Avg_value_or_avg_length: 300.0000 Std: 172.9162 Optimal_fieldtype: SMALLINT(3) UNSIGNED NOT NULL*************************** 2. row *************************** Field_name: sakila.customer.first_name Min_value: AARON Max_value: ZACHARY Min_length: 2 Max_length: 11 Empties_or_zeros: 0 Nulls: 0 Avg_value_or_avg_length: 5.6644 Std: NULL Optimal_fieldtype: ENUM('AARON','ADAM','ADRIAN',...,'ZACHARY') NOT NULL *************************** 3. row *************************** Field_name: sakila.customer.email Min_value: [email protected] Max_value: [email protected] Min_length: 26 Max_length: 40 Empties_or_zeros: 0 Nulls: 0 Avg_value_or_avg_length: 31.8715 Std: NULL Optimal_fieldtype: VARCHAR(40) NOT NULL

membres:| Pascal | 1 | | Arnaud | 2 || Olivier | 2 | | Xavier | 3 | | Muriel | NULL |



Avec l’instruction INNER JOIN seuls les enregistrements qui satisfont à la condition dejointure sont retournés.

Les syntaxes équivalentes sont :

Le critère de jointure (id) ayant le même nom, la clause USING peut être utilisée ;

Cette variante est plus utilisée, mais elle est moins claire.

L’opération LEFT OUTER JOIN renvoie les enregistrements qui satisfont à la conditionde jointure ainsi que tous les enregistrements de la première table (à gauche, d’où lemot LEFT).

profession;| 1 | architecte | | 2 | dba | | 3 | cto | | 4 | développeur |

mysql> SELECT m.nom, p.description FROM membre AS m INNER JOIN profession AS p ON p.id = m.id;+---------+-------------+ | nom | description | +---------+-------------+ | Pascal | architecte | | Arnaud | dba | | Olivier | dba | | Xavier | cto | +---------+-------------+

SELECT m.nom, p.description FROM membre AS m

SELECT m.nom, p.description FROM membre AS m, profession AS p WHERE p.id = m.id;

mysql> SELECT m.nom, p.description FROM membre AS m LEFT OUTER JOIN profession AS p ON m.id = p.id;+---------+-------------+ | nom | description | +---------+-------------+ | Pascal | architecte | | Arnaud | dba | | Olivier | dba | | Xavier | cto | | Muriel | NULL |



171

RIGHT OUTER JOIN fonctionne suivant le même principe que LEFT, à la différence quece sont tous les enregistrements de la table de droite qui sont renvoyés. Rarement uti-lisé, on lui préfère LEFT car il suffit d’inverser l’ordre des tables.

Le produit cartésien est un type de jointure qui peut être très coûteux, car avec deuxtables qui contiennent respectivement n et m enregistrements, la requête renvoien × m lignes.

mysql> SELECT m.nom, p.description FROM profession AS p RIGHT OUTER JOIN membre AS m ON m.id = p.id;+---------+-------------+ | nom | description | +---------+-------------+ | Pascal | architecte | | Arnaud | dba | | Olivier | dba | | Xavier | cto | | Muriel | NULL | +---------+-------------+

mysql> SELECT m.nom, p.description FROM membre AS m, profession AS p;+---------+--------------+ | nom | description | +---------+--------------+ | Pascal | architecte | | Pascal | dba | | Pascal | cto | | Pascal | développeur | | Arnaud | architecte | | Arnaud | dba | | Arnaud | cto | | Arnaud | développeur | | Olivier | architecte | | Olivier | dba | | Olivier | cto | | Olivier | développeur | | Xavier | architecte | | Xavier | dba | | Xavier | cto | | Xavier | développeur | | Muriel | architecte | | Muriel | dba | | Muriel | cto | | Muriel | développeur | +---------+--------------+



MySQL supporte également les opérateurs suivants :• CROSS JOIN : pour MySQL, CROSS JOIN et INNER JOIN sont identiques, ce qui

diffère de la norme SQL ANSI ;• STRAIGHT_JOIN : est similaire à INNER JOIN. La seule différence est que la table à

gauche sera toujours lue avant celle de droite. Cela permet de forcer l’optimiseurdans le cas où il ne choisirait pas le plan d’exécution optimal.

Il existe trois algorithmes pour effectuer des jointures, nested loops, merge join et hashjoin. Pour gérer les jointures, MySQL n’implémente que le premier.

L’algorithme de boucles imbriquées (Nested loops) est le plus simple des algorithmes dejointure. Pour chaque enregistrement, MySQL analyse tous les éléments définis par lecritère de jointure et ne garde que les enregistrements qui correspondent. Évidemment,cet algorithme est très peu performant s’il doit traiter un grand nombre de valeurs. Pourl’améliorer, il faut absolument disposer d’un index sur le critère de jointure.

Voici l’algorithme :

Les autres types sont :• Merge join (Sort-Merge Join) : les relations sont triées en fonction des attributs

utilisés par la jointure. Il faut ensuite récupérer seulement ceux qui satisfont à lacondition.

• Hash join : consiste à créer une table de hachage (hash table) à partir des attributs dejointure et à y récupérer tous les éléments voulus ; il est en effet plus performant deréaliser cette opération avec un index hash qu’avec un B-tree (voir plus loin).

Les indexLorsqu’il reçoit une requête, l’optimiseur doit trouver la méthode la plus performantepour l’exécuter. Dans le cas d’une requête de lecture, pour pouvoir sélectionner etrenvoyer le résultat, il choisit entre utiliser l’index, s’il existe et s’il est pertinent, ouparcourir tous les enregistrements de la table, c’est-à-dire faire un full table scan. Enrègle générale, utiliser l’index se révèle plus performant que le parcours complet de latable car moins de données sont analysées et les I/O sont minimisés. L’impact ne serapas forcément le même pour les requêtes d’écriture, car il faut mettre à jour les don-nées et l’index.

Pour tous les éléments (e1) de T1 faire : Pour tous les éléments (e2) de T2 faire : si e1 et e2 satisfont la condition de jointure alors garder l’ensemble e1,e2.



173

Index B-treeLes algorithmes de génération d’index dans MySQL sont implémentés par lesmoteurs de stockage et pour la plupart dérivés du B-tree qui est une structure conte-nant les données triées sous la forme d’un arbre binaire équilibré (balanced). L’intérêtde cet algorithme est qu’il est optimisé pour minimiser les accès disque.

Pour fixer les idées, si une table compte 10 millions d’entrées, un full table scan lesanalysera toutes ; alors qu’avec un arbre binaire le nombre d’enregistrements analysés(N) sera de l’ordre de 23 (O(log2N)) grâce à une recherche dichotomique. C’estdonc un gain non négligeable par rapport à une recherche linéaire. La recherchelinéaire sera parfois utilisée par l’optimiseur sur des petites tables. Pour des tablesplus importantes, la recherche dichotomique est souvent plus intéressante.

Figure 6–1Arbre binaire équilibré (B-tree).

B.A.-BA

La recherche dichotomique est une technique algorithmique utilisable uniquement avec des structures dedonnées ordonnées.



Derrière ces chiffres théoriques, d’autres facteurs entrent en compte, notamment liésaux disques. Dans certains cas, rechercher les données par l’index peut être plus coû-teux qu’une lecture séquentielle.

Pour illustrer ce point, imaginez que le technicien de la compagnie d’électricité doivepasser chez tous les habitants d’un immeuble pour récupérer le relevé du compteur.S’il décide de s’acquitter de sa tâche en commençant par tous les habitants du rez-de-chaussée, puis tous les habitants du premier étage et ainsi de suite jusqu’au dernierétage, il sera plus performant que s’il procède par ordre alphabétique. Ce qui pourraitdonner dans ce dernier cas : monter chez Borghino au huitième étage, puis descendreau premier pour aller chez Dasini, monter à nouveau, mais au neuvième cette fois,pour aller chez Gadal...

Un autre inconvénient concerne les requêtes d’écritures qui risquent d’être ralenties :en plus de devoir écrire la donnée, il faut également écrire dans l’index au bonendroit, car rappelez-vous qu’il est trié.

En fonction de l’application, vous pouvez donc être amené à optimiser les perfor-mances des requêtes de lectures (c’est en général le cas car beaucoup d’applications eneffectuent une majorité) mais c’est parfois le cas inverse ; pensez alors aux inconvé-nients des index.

L’algorithme B-tree est implémenté par le moteur de stockage MyISAM. C’est lefichier qui a pour extension .MYI qui contient tous les index de chacune des tables. Lesindex y sont stockés et triés comme exposé précédemment et, dans les feuilles del’arbre, un pointeur permet d’accéder aux données qui correspondent à la valeur duchamp indexé (.MYD). Le principe est le même pour tout les index, exceptés les indexfulltext.

BON À SAVOIR Index Fulltext (Plaintext)

Fulltext est un type d’index utile pour rechercher des mots dans de gros volumes de textes. Il ne fonc-tionne que sur les tables MyISAM et ne peut être créé que sur des colonnes de types texte (char,varchar, et text).Son utilisation est différente des autres index : la recherche est effectuée avec la fonction MATCH() quipermet de sélectionner la colonne dans laquelle le mot est cherché et la fonction AGAINST() qui ellepermet de spécifier les mots recherchés. Les enregistrements retournés sont automatiquement triés parune notion de pertinence.N’hésitez pas à consulter la documentation pour plus d’informations :B http://dev.mysql.com/doc/refman/5.1/en/fulltext-natural-language.htmlUne alternative est le projet libre Sphinx, basé entre autres sur Lucene :B http://www.sphinxsearch.com/



175

Index B+treeInnoDB implémente une variante du B-tree, appelée B+tree. Cet algorithme est spé-cialisé dans le stockage de volumes de données trop importants pour tenir entière-ment en mémoire. En général les feuilles sont stockées sur le disque alors que lesautres nœuds restent en mémoire. De plus, contrairement à B-tree les enregistre-ments sont stockés dans les feuilles, les autres nœuds ne contiennent que les index.

Figure 6–2B-tree du moteur MyISAM

Figure 6–3Index B+tree



L’autre différence majeure avec MyISAM est la notion d’index en grappe (clusteredindex). La clé primaire sert à construire l’arbre B+tree sauf que dans les feuilles ontrouve, non pas un pointeur vers les données comme avec MyISAM, mais les enre-gistrements qui correspondent à la valeur de la clé primaire. InnoDB a donc besoind’une clé primaire pour fonctionner. S’il n’en trouve pas dans la structure de la table,il en crée une en interne sous la forme d’un entier de 6 octets.

Pour les index secondaires (autre que la clé primaire), le principe est presque lemême. Ils sont représentés également par un B+tree, sauf que dans les feuilles on neretrouve pas les enregistrements, mais la valeur de la clé primaire correspondante.Une seconde recherche, sur la clé primaire, est donc nécessaire.

Cela a deux incidences immédiates :• les enregistrements des tables InnoDB sont triés par rapport à la clé primaire. Si

par exemple vous voulez insérer un gros volume de données, triez-le par rapport àla clé primaire avant, ce qui limitera les I/O ;

• toutes les recherches passent par la clé primaire. La taille de cette dernière doitêtre la plus petite possible, car une mauvaise clé primaire sur une table InnoDBaura un impact négatif sur la taille des index secondaires et sur toutes les recher-ches indexées de cette table.

InnoDB implémente également l’algorithme hash adaptative, qui permet de générerautomatiquement une table de hachage en interne, lorsque le moteur détecte que desvaleurs d’index sont accédées fréquemment. Ce mécanisme est géré par le moteur etvous n’aurez donc pas la main dessus, contrairement au moteur de stockage Memory,qui utilise lui aussi un algorithme de hachage. C’est son algorithme par défaut : toutindex créé sur une table Memory sera donc une table de hachage, sauf si vous spéci-fiez le contraire.

Figure 6–4Index en grappe d’InnoDB



177

Index hashCet algorithme présente la particularité d’être performant pour les recherches d’éga-lités avec les signes = ou <=>. En revanche, il ne fonctionne pas pour les recherchespar intervalles ou pour les inégalités (BETWEEN, <, >=...) parce que les données ne sontpas triées dans la table de hachage. Pour les mêmes raisons, l’optimiseur ne pourrapas s’en servir pour optimiser la clause ORDER BY. Un autre de ses inconvénients estqu’il n’est pas très efficace s’il y a beaucoup de doublons.

Depuis MySQL 4.1, il est possible de contourner ces limitations, en mettant unindex B-tree. Pour chaque index de la table, vous avez donc la possibilité de choisirentre un hash et un B-tree. Si la table ne reçoit que des requêtes d’égalités, optezpour un index hash sur les colonnes ayant un index unique (primary key et uniqueindex). En présence de requêtes d’inégalités ou de beaucoup de doublons, optez pourun index B-tree. Et rien ne vous empêche, pour une même colonne, de placer unindex hash et un index B-tree si nécessaire (surindexation).

Attention, la surindexation est en général à éviter : elle augmente en effet la taille del’index et ajoute un surcoût au processus de mise à jour des index.

Dans l’exemple qui suit, les tables t_myisam et t_memory n’ont qu’une seuledifférence : leur moteur de stockage (respectivement MyISAM et Memory). Lacommande EXPLAIN est utilisée pour comparer les différents plans d’exécution.EXPLAIN est exposée plus en détails un peu plus loin dans ce chapitre.

BON À SAVOIR La table de hachage

On peut se représenter une table de hachage par un tableau associatif non ordonné qui permet une asso-ciation clé/donnée. L’accès à une donnée a lieu en transformant la clé en hash, grâce à une fonction dehachage.

Figure 6–5Index hash de Memory



La clé primaire de t_myisam est en B-tree alors que celle de t_memory est en hash :

Une recherche sur la clé primaire permet d’utiliser l’index sur t_myisam.

t_memory se comporte de façon identique :

mysql> SHOW INDEX FROM t_myisam \G *************************** 1. row *************************** Table: t_myisam Key_name: PRIMARY Column_name: IDCardinality: 4079 Index_type: B-tree...

mysql> SHOW INDEX FROM t_memory \G *************************** 1. row *************************** Table: t_memory Key_name: PRIMARY Column_name: IDCardinality: 4079 Index_type: HASH...

mysql> EXPLAIN SELECT * FROM t_myisam where id = 972 \G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t_myisam type: const possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: const rows: 1 Extra:

mysql> EXPLAIN SELECT * FROM t_memory where id = 972 \G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t_memory type: const possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: const rows: 1 Extra:



179

Une recherche d’inégalité utilise la clé primaire sur t_myisam mais pas sur t_memorydu fait de l’algorithme hash :

Ajout d’un index B-tree sur la colonne id (la clé primaire) de la table t_memory

mysql> EXPLAIN SELECT * FROM t_myisam where id < 93 \G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t_myisam type: range possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: NULL rows: 93 Extra: Using where

mysql> EXPLAIN SELECT * FROM t_memory where id < 93 \G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: t_memory type: ALL possible_keys: PRIMARY key: NULL key_len: NULL ref: NULL rows: 4079 Extra: Using where

mysql> CREATE UNIQUE INDEX idx_btree_id USING B-TREE ON t_memory(id);

mysql> SHOW INDEX FROM t_memory \G *************************** 1. row *************************** Table: t_memory Key_name: PRIMARY Column_name: IDCardinality: 4079 Index_type: HASH*************************** 2. row *************************** Table: t_memory Key_name: idx_btree_id Column_name: IDCardinality: NULL Index_type: B-tree



Malgré l’ajout de l’index B-tree, l’index hash (PRIMARY) continue d’être utilisé pour larecherche d’égalité. En revanche, l’index B-tree (idx_btree_id) est employé pour larecherche par intervalles :

mysql> EXPLAIN SELECT * FROM t_memory where id = 972 \G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t_memory type: const possible_keys: PRIMARY,idx_btree_id key: PRIMARY key_len: 4 ref: const rows: 1 Extra: 1 row in set (0.00 sec)

mysql> EXPLAIN SELECT * FROM t_memory where id < 93 \G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t_memory type: range possible_keys: PRIMARY,idx_btree_id key: idx_btree_id key_len: 4 ref: NULL rows: 186 Extra: Using where

Tableau 6–2 Les types d’algorithmes de génération d’index des moteurs de stockage

MyISAM InnoDB Memory

B-tree Oui À la demande

B+tree Oui

Hash Automatique Oui

ALTERNATIVE

Notez que MyISAM implémente également d’autres types d’algorithmes comme Rtree pour les indexgéométriques (GIS) ou Fulltext pour la recherche de mots dans du texte.



181

Optimisation des requêtesAvec le schéma, l’autre point clé d’une base de données performante et évolutive estle code SQL. Moins coûteux à modifier que le schéma, l’optimisation des requêtesdiminuera les temps de traitements, permettra d’absorber une charge plus impor-tante, et vous fera réaliser des économies sur le matériel tout en diminuant le risqueque la base de données soit le goulet d’étranglement de votre application.

Connaître l’optimiseur pour mieux le comprendre

Lorsqu’une requête SQL arrive sur le serveur, après les différentes étapes de vérifica-tion des droits, elle est analysée syntaxiquement (vérifier que les colonnes et les tablesexistent), puis transformée en un format binaire et réécrite dans le but de produire unarbre d’analyse (parse tree). Ensuite, l’optimiseur va, à l’aide de cet arbre, chercher leplan d’exécution optimal pour l’envoyer au moteur d’exécution de requêtes dumoteur de stockage.

Pour calculer le plan d’exécution, l’optimiseur se base sur plusieurs facteurs : lenombre d’enregistrements des tables, le nombre d’éléments dans les index, la sélecti-vité des index et les colonnes utilisées.

B.A.-BA La sélectivité

Avec MySQL, la pertinence d’indexer une colonne va dépendre de sa proportion plus ou moins granded’enregistrements identiques (doublons) à savoir sa sélectivité ou cardinalité (cardinality). Plus elle seragrande, plus il sera intéressant de mettre un index. La formule est :Sélectivité = Nombre d’enregistrements/Nombre d’enregistrements distincts.

Le meilleur résultat pour un index est une sélectivité de 1 (100 % de valeurs distinctes), ce qui signifieque tous les éléments sont différents. C’est notamment le cas pour la clé primaire.Un billet sur l'un de nos blogs traite du sujet : http://www.dbnewz.com/2008/09/05/



La commande EXPLAIN pour analyser l’exécution des requêtesDans un monde idéal, toutes les requêtes devraient être optimales. Les tables nedevraient comporter que des index utilisés, les requêtes utiliseraient les bons indexquand cela est nécessaire, elles ne renverraient que les données dont on a besoin(colonnes et enregistrements) et le tout avec un temps d’exécution satisfaisant ! Mal-heureusement cela n’est pas toujours le cas. Il est cependant possible de s’en appro-cher en analysant le plan d’exécution des requêtes avec la commande EXPLAIN.

Celle-ci ne fonctionne qu’avec des requêtes de type SELECT et permet de savoir dansquel ordre les tables sont traitées, de quelles manières les données sont récupérées etd’avoir une estimation du nombre d’enregistrements retournés. Elle n’est pas aussicomplète que les commandes équivalentes sur d’autres SGBD car elle n’a pas lemême niveau de détail. Cependant, les informations fournies donnent une idée assezprécise du plan d’exécution choisi par l’optimiseur.

On y remarque les manques suivants :• aucune information n’est disponible sur les déclencheurs (triggers), les procédures

stockées, les fonctions utilisateurs (UDF) ;• les résultats peuvent être imprécis si les statistiques ne sont pas à jour (ANALYZETABLE met à jour les statistiques) ;

• on ne peut pas savoir si un tri est effectué en mémoire ou sur disque (disponibleavec SHOW SESSION STATUS LIKE 'Created_tmp%';) ;

BON À SAVOIR Optimiseurs à base de règles ou de coût (cost based ou rules based)

Dans l’univers de la base de données il existe des optimiseurs basés sur le coût (cost based) ou basés surdes règles (rules based). MySQL utilise la première méthode : il calcule le coût d’accès aux données en sebasant sur le coût des I/O, des cycles processeurs, les coûts liés aux statistiques de la base de données(nombre d’enregistrements, distribution des données, plages de valeurs...) et les coûts d’analyse de larequête. Son principal avantage est de lui permettre de calculer le plan d’exécution optimal en fonctionde la distribution et de la volumétrie des données.Le calcul du coût comprend notamment le coût d’un accès disque et son unité est la lecture aléatoired’une page de 4 Ko. Les paramètres pris en compte dans ce calcul sont :• les statistiques sur les données ;

- le nombre de pages par tables/index ;- la sélectivité des tables/index ;- la taille des enregistrements et des index ;- la distribution des index ;

• le schéma ;- l’unicité de certains champs (clés primaires…) ;- les champs NULL.

De leur côté, les optimiseurs utilisent des règles syntaxiques pour évaluer les différents plans.



183

• la notion de coût n’apparaît pas (disponible avec SHOW SESSION STATUS LIKE

'Last_query_cost';).

EXPLAIN se place juste avant le mot-clé SELECT et produit un tableau avec les colonnessuivantes :• id : nombre entier qui permet d’identifier la ou les requêtes SELECT ;• select_type : nature du SELECT (simple, union, sous-requête, table dérivée...) ;• table : nom de la table utilisée par le plan d’exécution ;• type : stratégie d’accès aux données choisie par l’optimiseur. Cette partie est

détaillée plus loin ;• possible_keys : liste des index choisis par l’optimiseur lors de l’évaluation des

différents plans d’exécution ;• Key : nom de l’index choisi par l’optimiseur. En cas de problèmes de performance,

si ce champ vaut NULL, vérifiez que la table est correctement indexée. Si c’est lecas, essayez de réécrire la requête ;

• key_len : taille en octets de l’index choisi. Il est préférable qu’elle soit petite ;• ref : colonne ou constante choisie par l’index pour accéder aux données de la

table ;• rows : estimation du nombre de lignes que doit analyser l’optimiseur. La précision

de ce nombre dépend de la fraîcheur des statistiques (mises à jour avec la com-mande ANALYZE TABLE) ;

• Extra : informations complémentaires pouvant être utiles pour la compréhensiondu plan d’exécution choisi par l’optimiseur (voir page suivante).

Voici la liste des différentes valeurs que peut prendre la colonne type, classées dumoins performant au plus performant :• ALL : tous les enregistrements de la table sont parcourus (full table scan). En règle

générale, il faut éviter d’utiliser ce type d’accès. Cependant, si la table est petite, sil’index n’est pas assez sélectif, si il n’y a pas de clauses ON ou WHERE ou si la majeure

PRATIQUE Visualiser le plan d’exécution d’un DELETE ou d’un UPDATE

Impossible par défaut (EXPLAIN n’accepte que les commandes SELECT), visualiser le plan d’exécutiondes DML UPDATE ou DELETE nécessite une petite ruse. L’astuce consiste à remplacer les commandesDELETE ou UPDATE par une clause SELECT. Une petite réécriture de la requête est à prévoir mais lejeu en vaut la chandelle. Par exemple, le plan d’exécution de la requête :DELETE FROM ma_table WHERE id=972

peut être visualisé avec :EXPLAIN SELECT * FROM ma_table WHERE id=972;



partie des enregistrements de la table doit être lue, l’optimiseur peut choisird’effectuer un full table scan malgré la présence d’index.

• INDEX : équivalent à ALL mais pour les index (full index scan). En général, meilleurque le type précédent car l’index est souvent plus petit que les données.

• RANGE : l’index est parcouru sur un intervalle de valeurs (limited index scan). Ceplan d’accès est choisi quand des opérateurs tels que BETWEEN, >, <=... sont utilisésdans la clause WHERE de la requête. On peut le retrouver également avec des opéra-teurs de conditions multiples comme IN ou LIKE.

• UNIQUE_SUBQUERY et INDEX_SUBQUERY : concernent les sous-requêtes lorsqu’ellesretournent des valeurs uniques ou non.

• INDEX_MERGE : le résultat de plusieurs index est utilisé pour former un uniqueensemble de données. Jusqu’à la version MySQL 5, lorsque l’optimiseur avait lechoix entre plusieurs index pour une requête, il ne pouvait en choisir qu’un seul.Une astuce consiste à simuler l’index merge en décomposant la requête en plu-sieurs requêtes et en les unissant avec la clause UNION ALL :

• REF_OR_NULL : un index non unique et acceptant les valeurs NULL est utilisé pour larecherche sur plusieurs enregistrements.

• REF : un index non unique est utilisé pour la recherche (index lookup) sur plusieursenregistrements.

• EQ_REF : la clé primaire ou un index unique est utilisé.• CONST : l’optimiseur sait qu’au plus un enregistrement de la table sera lu. C’est le

cas lorsqu’il s’agit d’une clé primaire, d’un index unique ou lorsque la table n’aqu’un seul enregistrement.

• SYSTEM : la table ne contient qu’un seul enregistrement et en mémoire.

Les informations données par la colonne Extra peuvent indiquer un besoin d’amé-lioration de la requête. Voici les trois indications qui doivent retenir particulièrementvotre attention :• Using join buffer : le join buffer est un tampon (buffer) spécial utilisé pour amé-

liorer le temps d’exécution des jointures n’employant pas d’index. En d’autres ter-mes, il s’agit d’un produit cartésien, c’est-à-dire de la multiplication de tous lesenregistrements de la première table par ceux de la seconde. Si cette indicationapparaît, placez un index sur les critères de jointure.

• Using filesort : indique que les données sont triées par MySQL durant l’exécu-tion de la requête.

SELECT count(*) FROM table WHERE nom = 'Jean' UNION ALL SELECT count(*) FROM table WHERE taille > 170;



185

• Using temporary : indique qu’une table temporaire doit être créée par MySQLpour stocker un résultat durant l’exécution de la requête. Cette information apparaîtsouvent lorsque les clauses ORDER BY ou GROUP BY sont présentes. En revanche, lacommande n’indique pas si la table est créée sur disque ou en mémoire. Pour obte-nir cette information, exécutez la requête (sans la commande EXPLAIN) puis lancezjuste après la commande SHOW SESSION STATUS LIKE 'Created_tmp%';.

REMARQUE Attention à la fonction RAND()

La requête suivante permet d’obtenir un enregistrement choisi au hasard d’une table : SELECT * FROM City ORDER BY rand() LIMIT 1.C’est une très mauvaise façon de procéder, car comme vous pouvez le constater, elle est très coûteuse(Extra : Using temporary; Using filesort).

mysql> EXPLAIN SELECT * FROM City ORDER BY rand() LIMIT 1 \G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: City type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 4079 Extra: Using temporary;Using filesort

mysql> FLUSH STATUS; /* positionne les variables d'état à zéro */

mysql> SELECT * FROM City ORDER BY rand() LIMIT 1; +----+-------+-------------+----------+------------+ | ID | Name | CountryCode | District | Population | +----+-------+-------------+----------+------------+ | 35 | Alger | DZA | Alger | 2168000 | +----+-------+-------------+----------+------------+

mysql> SHOW SESSION STATUS LIKE 'Created_tmp%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 1 | | Created_tmp_files | 0 | | Created_tmp_tables | 1 | +-------------------------+-------+



Voici quelques conseils au cas où le résultat d’une commande EXPLAIN sur unerequête problématique ne serait pas satisfaisant :• ajouter un index pertinent et tester à nouveau ;• réécrire la requête ;• scinder la requête en plusieurs requêtes plus simples ;• ajouter des filtres dans la clause WHERE pour diminuer le nombre de lignes à

traiter ;• forcer l’optimiseur à modifier l’ordre des tables ;• contraindre l’optimiseur à utiliser un index précis ou l’empêcher d’utiliser l’index

qu’il a choisi ;• stocker le résultat dans une table (temporaire), pour ne pas l’exécuter à chaque

fois ;• exécuter le traitement hors de la base de données.

À chaque nouvelle version majeure de MySQL, l’optimiseur est amélioré. En règlegénérale ses choix sont plutôt bons. Toutefois, vous avez la possibilité d’influencerl’optimiseur en lui ordonnant d’utiliser ou non tel ou tel index :• USE INDEX : emploie l’index passé en argument. MySQL ne l’utilisera pas si le

coût de l’index est plus important que celui d’un full table scan ou s’il est dansl’impossibilité de le faire ;

• FORCE INDEX : utilise l’index passé en argument. MySQL exploitera alors l’indexsauf si cela lui est impossible ;

• IGNORE INDEX : n’utilise pas l’index passé en argument.

Il est également possible, dans le cas de jointures internes, de fixer l’ordre des tables(STRAIGHT_JOIN). Cependant, comme exposé précédemment, le plan d’exécutiondépend notamment du nombre d’enregistrements ; il peut donc évoluer. La vérité dujour n’est pas forcément celle de demain. Nous vous le déconseillons sauf si vous êtessûr de vous...

OUTILS Représentation graphique du plan d’exécution avec Maatkit

Maatkit propose un script Perl pour obtenir une représentation graphique des requêtes EXPLAIN.B http://www.maatkit.org/



187

Exemple d’optimisation d’un plan d’executionLa table rental_daz inspirée de la table rental de la base de données sakila, contient16 049 enregistrements et possède la structure suivante :

BON À SAVOIR Optimisation des index et réorganisation des tables avec ANALYSE TABLE et OPTIMIZE TABLE

Pour maximiser les chances d’obtenir un plan d’exécution optimal, les statistiques des tables doivent êtreà jour : c’est le rôle de la commande ANALYZE TABLE.Vous devez savoir qu’un verrou en lecture d’une durée équivalente à un full table scan, est placé sur lestables MyISAM durant l’opération. Cependant, comme MyISAM maintient automatiquement les statisti-ques sur le nombre d’enregistrements que contient la table, à chaque requête INSERT et DELETE, iln’est pas nécessaire d’exécuter souvent cette commande.Le fonctionnement d’InnoDB est quelque peu différent. Avec ce moteur, les statistiques sont mises à jourà chaque fois qu’un seizième des données a changé. Par exemple, si une table contient 100 000 enregis-trements, les statistiques seront mises à jour après que 100 000/16=6 250 données auront changé. Cettefaçon d’opérer est plus rapide que pour une table MyISAM équivalente ; de plus elle est totalement àchaud, c’est-à-dire sans aucun verrou.Une autre façon de mettre les statistiques à jour est d’utiliser OPTIMIZE TABLE. En fait, cette com-mande lance une opération ANALYZE TABLE dans l’optique de rééquilibrer l’index et ses blocs en lerecréant. Ce procédé est plus lourd que la simple mise à jour des statistiques, car elle réorganise égale-ment les données en plaçant un verrou en lecture sur la table, quel que soit son moteur.

mysql> SHOW CREATE TABLE rental_daz \G*************************** 1. row *************************** Table: rental_dazCreate Table: CREATE TABLE `rental_daz` ( rental_id int(11) NOT NULL AUTO_INCREMENT, rental_date datetime NOT NULL, inventory_id mediumint(8) unsigned NOT NULL, customer_id smallint(5) unsigned NOT NULL, return_date datetime DEFAULT NULL, staff_id tinyint(3) unsigned NOT NULL, last_update timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (rental_id), UNIQUE KEY rental_date (rental_date,inventory_id,customer_id), KEY idx_fk_inventory_id (inventory_id), KEY idx_fk_customer_id (customer_id), KEY idx_fk_staff_id (staff_id)) ENGINE=InnoDB AUTO_INCREMENT=16050 DEFAULT CHARSET=utf8



Plan d’exécution de la requête suivante

L’index rental_date est utilisé. Visualisons le coût de la requête :

Son coût est d’environ 3 842. Influençons l’optimiseur pour l’empêcher d’utiliserl’index rental_date et visualisons le coût de la nouvelle requête :

mysql> EXPLAIN SELECT * FROM rental_daz WHERE rental_date > SUBDATE(now(), INTERVAL 3 YEAR) \G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: rental_daz type: rangepossible_keys: rental_date key: rental_date key_len: 8 ref: NULL rows: 2744 Extra: Using where

mysql> SHOW STATUS LIKE 'Last_query_cost';+-----------------+-------------+| Variable_name | Value |+-----------------+-------------+| Last_query_cost | 3842.609000 |+-----------------+-------------+

mysql> EXPLAIN SELECT * FROM rental_daz IGNORE INDEX(rental_date) WHERE rental_date > SUBDATE(now(), INTERVAL 3 YEAR)\G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: rental_daz type: ALLpossible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 16298 Extra: Using where

mysql> SHOW STATUS LIKE 'Last_query_cost';+-----------------+-------------+| Variable_name | Value |+-----------------+-------------+| Last_query_cost | 3356.599000 |+-----------------+-------------+



189

Une opération full table scan est alors effectuée et l’optimiseur n’utilise donc pasl’index, ce qui est a priori plus coûteux. Cependant, l’estimation du coût de cetterequête est moins élevée que pour la première (qui elle utilise l’index rental_date) !

Le client de test mysqlslap permet de confirmer ou non les résultats, en donnant unedurée d’exécution :

mysqlslap confirme bien que full table scan est, dans ce cas précis, plus performantque la recherche par intervalles sur l’index. On se trouve dans un cas où l’optimiseurne choisit pas le plan d’exécution le plus performant.

Indexer les premiers caractères d’une colonneComme exposé précédemment, la taille des index peut affecter les performances desrequêtes ; elle doit être la plus petite possible. Cela peut se gérer soit en utilisant destypes de champs qui consomment moins de place (tinyint, enum, char(20)...) oualors, pour les champs de type chaîne de caractères (CHAR, VARCHAR, TEXT) en n’indexantpas toute la longueur de la colonne mais seulement les n premiers caractères, avec nassez grand pour que la sélectivité de l’index reste grande ; en d’autres termes, il ne fautpas que les doublons soient trop nombreux.

Par exemple, pour la colonne nom CHAR(255), indexer les 25 premiers caractères avecINDEX(nom(25)) donne un index 10 fois plus petit que INDEX(nom).

shell> mysqlslap -uroot -p --create-schema=sakila -i50 -q "SELECT * FROM rental_daz WHERE rental_date > SUBDATE(now(), INTERVAL 3 YEAR);"Benchmark

Average number of seconds to run all queries:0.287 seconds Minimum number of seconds to run all queries: 0.140 seconds Maximum number of seconds to run all queries: 1.172 seconds Number of clients running queries: 1 Average number of queries per client: 1

shell> mysqlslap -uroot -p --create-schema=sakila -i50 -q "SELECT * FROM rental_daz ignore index(rental_date) WHERE rental_date > SUBDATE(now(), INTERVAL 3 YEAR); "Benchmark

Average number of seconds to run all queries: 0.167 seconds Minimum number of seconds to run all queries: 0.078 seconds Maximum number of seconds to run all queries: 1.094 seconds Number of clients running queries: 1 Average number of queries per client: 1



Index couvrant (covering index)Lorsque toutes les colonnes de l’index sont référencées par les clauses JOIN et WHEREd’une requête SELECT, l’information se trouve entièrement dans l’index et aucuneréférence aux enregistrements n’est alors nécessaire. Cela a pour conséquence deminimiser les I/O.

Préfixe d’index (leftmost prefix indexes)Vous pouvez profiter du fait que MySQL permet l’utilisation des premières colonnesd’un index multiple pour éviter d’en créer de nouveaux.

Un index INDEX(a,b,c) sur les colonnes a, b et c, peut remplacer INDEX(a) etINDEX(a,b) dans les cas suivants (leftmost prefixing) :

Taille des indexLa taille des index doit être la plus petite possible, surtout dans le cas de la clé pri-maire d’InnoDB. Les index de type entier sont de bons candidats. À vous d’ajusteren fonction de vos besoins : tinyint, smallint, int...

Récapitulatif des bonnes pratiques d’optimisation des requêtesVoici un récapitulatif sur les bonnes pratiques à suivre pour limiter les problèmes etoptimiser des requêtes.

Avant de créer votre requête, se demander si elle est utile

Avez-vous besoin de connaître en temps réel le nombre d’utilisateurs connectés sur leforum ? Si la réponse est non, actualisez les données toutes les n minutes ou lorsquecela est nécessaire.

L’utilisateur a-t-il besoin de savoir que sa recherche renvoie 9 564 234 résultats ?Demandez-lui d’affiner sa recherche ou affichez une approximation (comme le faitun célèbre moteur de recherche).

SELECT * FROM T WHERE a=XSELECT * FROM T WHERE a=X AND b=YSELECT * FROM T WHERE a=X AND b=Y AND c=Z

BON À SAVOIR Pas de préfixes d’index pour les index hash

Pour pouvoir utiliser un préfixe d’index sur une table Memory, il faut que l’algorithme des index soit enB-tree. Les données n’étant pas triées dans une table de hachage, l’optimiseur ne peut alors effectuerqu’un full table scan.



191

Les données ont-elles leur place dans la base ?

Le contenu statique, les images, les vidéos, les fichiers binaires... peuvent souventêtre placés en dehors de la base de données. Cependant, les risques d’incohérencesaugmentent car il est facile d’effacer un fichier et d’oublier de mettre à jour l’enregis-trement correspondant.

Ramener seulement les enregistrements nécessaires

Le surplus de données provoque un surcoût pour le serveur, pour le réseau et pour leclient.

Jeux d’essais

Testez vos requêtes avec des jeux de données réalistes, proches de la production. Eneffet, l’optimiseur MySQL réagit différemment si une table contient peu d’enregis-trements ou si elle en stocke des millions.

Superviser sa base de données

L’évolution de la volumétrie ou de la charge peut modifier les performances de vosrequêtes.

Tester et valider ses changements avant de les appliquer en production

La requête qui fonctionne sur le poste du développeur et qui met à genou le serveurde production, un grand classique...

Utiliser les types de champs les plus petits possible

Davantage d’informations seront alors chargées en mémoire, ce qui minimisera les I/O.

Prêter une attention particulière aux colonnes de jointures

Les types de données courts accélèrent la comparaison.

Les colonnes jointes doivent de préférence être du même type de données ; c’est engénéral plus performant.

Penser aux summary tables

Utilisez des tables temporaires, Memory ou MyISAM, pour leurs performances enlecture, en tant que cache de données pour éviter d’exécuter plusieurs fois les requêtescoûteuses. En revanche, les données ne seront pas forcément à jour.

Découper les requêtes complexes en plusieurs plus simples.Écrire du SQL revient à écrire une phrase dans une langue. Plus la phrase est petiteet simple plus elle est facilement compréhensible par le serveur.



Import massif de données

Préférez aux opérations INSERT la commande LOAD DATA INFILE ou le client mysql-import pour importer dans les tables de gros volumes de données.

Pour les tables MyISAM, désactivez les index : DISABLE KEYS / ENABLE KEYS.

Pour les tables InnoDB, désactivez les contraintes si vous êtes sûr de vos données :UNIQUE_CHECKS=0, FOREIGN_KEY_CHECKS=0.

Les enregistrements des tables InnoDB étant triés dans l’ordre de la clé primaire,triez vos données dans cet ordre avant de les importer dans la table.

Attention aux mythes

SELECT count(*) ne coûte rien : c’est vrai, mais seulement pour les tables enMyISAM et sans clause WHERE.

La clause LIMIT n’est pas une clause miracle. Bien utilisée, elle limitera le nombred’enregistrements sur le client ; en revanche, elle n’aura pas forcément un impact surle traitement de la requête.


Bien configurer votre serveur MySQL n’est pas forcément aisé. Il vous faut unebonne dose d’expérience saupoudrée d’une pincée de bon sens. Le compromis entreperformance et rapidité trouvé à un instant t ne sera pas forcément bon à t+1 et nesera pas bon non plus pour une autre application. En effet, comme on a pu le voirdans les chapitres précédents, les performances vont dépendre du schéma, desmoteurs de stockage, du type de requêtes, de la volumétrie des données, de la charge,et de bien d’autres critères, ce qui vous oblige, tout d’abord, à bien connaître l’appli-cation. Ensuite, la liste des options du serveur MySQL est très importante et s’enri-chit à chaque nouvelle version. Les connaître toutes n’est pas une nécessité, maisconnaître certaines d’entre elles est incontournable. Nous les avons sélectionnéespour vous. Ces options vont être affinées grâce à la supervision et à l’analyse desvariables d’états (status) associées.

Tuning serveur : variables de session, variables globales, handlers

La majorité des options que nous allons aborder concernent des caches et des buffers.Le but est d’utiliser au mieux ces zones de mémoire pour minimiser les I/O. Elles nedoivent évidemment pas être trop petites (c’est le cas des paramètres par défaut de

7Optimiser son serveur mySQL



MySQL) mais elles ne doivent pas être trop grandes non plus. Une erreur couranteest de penser que qui peut le plus, peut le moins ; on peut répondre à cela que le tropest l’ennemi du plus...

En effet, en allouant un cache/buffer trop grand, vous gaspillez de la mémoire quipeut être utile pour un autre cache/buffer ou qui peut pousser la machine à utiliser sazone de swap. Un autre inconvénient est qu’allouer un gros buffer est en général pluscoûteux que pour un petit !

Figure 7–1Les principales variables du serveur MySQL

VOCABULAIRE Cache et buffer (tampon)

Un tampon (buffer) est une zone de mémoire utilisée dans le but de stocker de façon temporaire les don-nées intermédiaires d’un calcul ou exécution. Un cache est une zone de mémoire où l’information eststockée pour y être relue de nombreuses fois, dans le but de minimiser les accès à des couches plus coû-teuses – telles que le disque dur. Les données sont donc en théorie amenées à être stockées plus long-temps dans un cache que dans un buffer. Cela dit, les notions de cache et de buffer sont, dans la terminologie MySQL, identiques. Lekey_buffer en est un bon exemple : stockant les index des tables MyISAM destinés à être souventrelus, il devrait plutôt s’appeler cache_buffer !


Optimiser son serveur mySQLCHAPITRE 7

195

Les variables de sessionCertaines options du serveur se modifient au niveau de la session, ce qui est très pra-tique car elles peuvent être ajustées par rapport aux besoins spécifiques de chaqueclient. C’est le cas des six variables qui suivent.

read_buffer_sizeCe buffer est alloué entièrement en une seule fois lorsque le client en a besoin. Il sertlors des opérations de parcours exhaustif (full table scan). En général, ce type de pland’exécution est à éviter (consultez au chapitre précédent la section sur la commandeEXPLAIN), mais vous devez augmenter cette variable si l’application effectue beaucoupde lectures séquentielles.

La variable d’état select_scan est à surveiller. Elle indique le nombre de jointuresayant réalisé un scan exhaustif sur la première table. Les full table scan sur les tablesseules sont également comptabilisées car pour MySQL toute opération SELECT estune jointure, même sur une unique table !

read_rnd_buffer_sizeCe buffer est alloué en fonction des besoins du client. Il sert lors des lectures ordon-nées et peut donc être utile pour les commandes GROUP BY.

sort_buffer_sizeReprésente la taille du buffer alloué pour les commandes GROUP BY/ORDER BY. Il estalloué entièrement en une seule fois lorsque le client le demande.

Les variables d’état à surveiller sont sort_merge_passes et Created_tmp_files.

On peut décomposer la récupération du résultat d’une requête SELECT qui effectue untri en 3 phases.1 La clause WHERE permet de récupérer les enregistrements.2 Les enregistrements sont triés.3 Les enregistrements sont lus dans l’ordre du tri.

La variable sort_merge_passes est affectée lors du tri à la phase 2. Le tri s’effectueen mémoire dans le buffer contrôlé par sort_buffer_size puis, une fois les donnéestriées, survient la phase 3. Si le buffer est trop petit, les enregistrements déjà triés etles autres vont être stockés dans un fichier temporaire créé sur le disque, qui seradonc utilisé en lieu et place du buffer. Cependant, ce fichier doit être trié à son tour ;MySQL crée alors un deuxième fichier temporaire pour y stocker les enregistrementsenfin triés. C’est ce deuxième tri qui incrémente la variable sort_merge_passes.



Bien entendu, les tris sur disque sont coûteux. Il faut donc tenter de les éviter en aug-mentant la valeur de sort_buffer_size qui peut diminuer le nombre desort_merge_passes et de Created_tmp_files.

join_buffer_sizeCe buffer est utilisé notamment lors des jointures sans index. La priorité est doncd’optimiser la jointure en ajoutant des index. Cependant, si cela ne s’avère pas pos-sible, augmentez cette valeur si la variable d’état à superviser Select_full_join estélevée. Il faut savoir qu’un buffer est utilisé par jointure ce qui implique, qu’en cas dejointures multiples, plusieurs buffers puissent être employés.

Select_full_join indique le nombre de jointures sans index effectuées (produitcartésien) : il faut donc éviter d’en réaliser.

tmp_table_size et max_heap_table_sizetmp_table_size est une variable au nom explicite qui permet bien de fixer la taillemaximale au-delà de laquelle les tables temporaires en mémoire créées par MySQL(avec le moteur Memory) se transforment en table MyISAM en migrant les donnéessur le disque. Parallèlement, il existe une variable nommée max_heap_table_size quipermet de fixer la taille maximale des tables avec pour moteur de stockage Memory(Heap est l’ancien nom de Memory).

Il est important de connaître la limite des tables temporaires en mémoire créées parMySQL : c’est la plus petite de ces deux valeurs. Le plus simple est de leur donner lamême valeur.

Les deux variables d’état à superviser sont created_tmp_tables etcreated_tmp_disk_tables. Si leur ratio (tables temporaires/tables temporaires surdisque) est élevé, augmentez tmp_table_size et max_heap_table_size.

Notez qu’une valeur de created_tmp_disk_tables élevée peut indiquer une utilisa-tion de BLOB ou TEXT, deux types non supportés par le moteur de stockage Memory.Les tables temporaires seront alors obligatoirement en MyISAM donc sur disque.

Les variables globales au serveurLes variables suivantes concernent le serveur tout entier.

Le cache de tableIl est chargé de mettre en cache la structure des tables (.frm). L’option esttable_definition_cache. Leurs descripteurs de fichiers sont également mis encache, l’option est table_open_cache.



197

Les variables d’état à superviser sont :• open_table_definitions : nombre de .frm en cache actuellement ;• open_tables : nombre de descripteurs de fichier en cache actuellement ;• opened_table_definitions : nombre total de .frm mis en cache ;• opened_tables : nombre total de descripteurs de fichier qui ont été mis en cache.

Si opened_tables (en unités par seconde) est important, augmentez alorstable_open_cache et table_definition_cache.

Le cache de threadUn thread est utilisé pour chaque connexion. Le rôle du cache de thread(thread_cache_size) est alors de le garder en mémoire après la déconnexion du client,en attente d’une prochaine connexion. Sa taille se définit en nombre de threads.

Les variables d’état à superviser sont :• threads_cached : nombre de threads dans le cache ;• threads_connected : nombre de connexions actuelles ;• threads_created : nombre total de threads créés ;• threads_running : nombre de threads actifs ;• connections : nombre de connexions au serveur (réussie ou non).

Figure 7–2Le cache de thread



Il faut que threads_created augmente lentement ; plusieurs stratégies sont àexplorer. Augmenter thread_cache_size si :• le hit ratio du cache de thread est bas. Il est calculé avec la formule suivante :threads_created/connection ;

• threads_created (en unités par seconde, threads_created/uptime) est impor-tant.

Table_locks_immediate et Table_locks_waitedLes verrous permettent d’assurer la cohérence des données mais peuvent être un freinà l’obtention de bonnes performances. En effet, plus longtemps une table sera ver-rouillée, plus le temps d’exécution des requêtes qui lui sont adressées sera long. Si lavaleur de la variable Table_locks_waited est élevée et que vous rencontrez des pro-blèmes de performances, plusieurs pistes sont à examiner.• Optimisez vos requêtes pour que les verrous soient plus courts.• Si vous utilisez des tables MyISAM, fixez concurrent_insert à 2 (vous trouverez

plus de détails ci-après).• Utilisez un moteur de stockage qui emploie le verrou niveau enregistrements

(InnoDB).• Répliquez des tables pour que des traitements se fassent sur un autre serveur.• Partitionnez les tables horizontalement ou verticalement pour fragmenter voire

paralléliser les traitements.

Aborted_clientsIl s’agit du nombre de connexions fermées non proprement. Les causes peuvent être :• des problèmes de réseau ;• une valeur max_allowed_packet trop faible.

Aborted_connectsC’est le nombre de connexions au serveur MySQL qui ont échoué. Les causes peuventêtre :• des problèmes de réseau ;• un mauvais mot de passe ou nom d’utilisateur ;• une tentative de connexion à un schéma inexistant ;• une tentative d’attaque.



199

Les handlersDans la terminologie MySQL, les handlers sont les événements de l’interface entrele serveur et les moteurs. Les variables d’état handler_* sont très utiles pour opti-miser les requêtes.

handler_read_first : comptabilise le nombre de lectures de la première valeur del’index. Une valeur élevée peut indiquer un grand nombre de full index scan.

handler_read_key : indique le nombre d’enregistrements récupérés grâce à l’index.Une valeur élevée signale une bonne utilisation de l’index.

handler_read_next : révèle une lecture ordonnée de l’index (une valeur, la suivante,puis la suivante...). C’est un indicateur de lecture d’index par intervalles ou de fullindex scan.

handler_read_prev : comptabilise le nombre de lectures de l’index dans l’ordre con-traire (ORDER BY … DESC).

handler_read_rnd et handler_read_rnd_next fournissent le nombre d’enregistre-ments et le nombre d’enregistrements suivants lus dans le fichier de données. Cesdeux variables sont clairement des indicateurs de mauvaises performances, car ellessont souvent la conséquence de full table scan ou de full join (jointures sans index).

Le rapport handler_read_rnd_next/handler_read_rnd vous donne une estimationde la taille moyenne d’un full table scan. Il faut alors optimiser votre requête ou votreschéma.

Ces variables peuvent être utilisées en complément de la commande EXPLAIN et de lavariable d’état last_query_cost pour mieux comprendre le plan d’exécution et opti-miser une requête.

Exemple d’optimisation d’une requête

Structure de la table city

mysql> SHOW CREATE TABLE city \G*************************** 1. row ***************************Table: cityCreate Table: CREATE TABLE `city` (ÌD` int(11) NOT NULL AUTO_INCREMENT,`Name` char(35) NOT NULL DEFAULT »,`CountryCode` char(3) NOT NULL DEFAULT »,`District` char(20) NOT NULL DEFAULT »,`Population` int(11) NOT NULL DEFAULT ‘0′ ,PRIMARY KEY (ÌD`),KEY Ìdx_population_cc` (`Population`,`CountryCode`)) ENGINE=MyISAM



Affichage du plan d’exécution

Le champ Extra : using index indique que MySQL utilise un index couvrant(covering index), c’est-à-dire que l’information est entièrement accessible en parcou-rant l’index (pas d’accès au fichier de données). Le champ type : index signale quel’optimiseur effectue un full index scan. Avec Using temporary et Using filesort

une table temporaire est créée et un tri effectué.

Handler_read_first, Handler_read_key et Handler_read_next indiquent ici un fullindex scan. Handler_read_rnd et Handler_read_rnd_next traduisent un full tablescan sur la table temporaire.

Handler_update donne une indication sur le nombre de mises à jour dans la tabletemporaire (à cause du tri).

mysql> EXPLAIN SELECT avg(Population) FROM city GROUP BY CountryCode\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: ctype: indexpossible_keys: NULLkey: Idx_population_cckey_len: 7ref: NULLrows: 4079Extra: Using index; Using temporary; Using filesort

mysql> SHOW STATUS LIKE ‘Last_query_cost’\G*************************** 1. row ***************************Variable_name: Last_query_costValue: 4963.520924

mysql> SHOW STATUS LIKE ‘handler%’;+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Handler_read_first | 1 || Handler_read_key | 4079 || Handler_read_next | 4079 || Handler_read_prev | 0 || Handler_read_rnd | 232 || Handler_read_rnd_next | 233 || Handler_update | 3847 || Handler_write | 232 |+----------------------------+-------+



201

Handler_write comptabilise le nombre de lignes insérées dans la table temporaire.

Ces deux derniers paramètres confirment donc la création de la table temporaire etl’opération de tri.

Pour obtenir plus d’informations sur le tri

Sort_rows est le nombre d’enregistrements triés dans la table temporaire.

Sort_scan est le nombre de tris effectués.

Created_tmp_tables est le nombre de tables temporaires créées. La bonne nouvelleest que la table temporaire est placée en mémoire (Created_tmp_disk_tables=0).

Avec KEY Ìdx_cc_population` (`CountryCode`,`Population`) un index plus per-tinent, la structure de la table city est la suivante :

mysql> SHOW SESSION STATUS LIKE ’sort%’;+-------------------+-------+| Variable_name | Value |+-------------------+-------+| sort_merge_passes | 0 || sort_range | 0 || sort_rows | 232 || sort_scan | 1 |+-------------------+-------+

mysql> SHOW SESSION STATUS LIKE ‘created%’;+-------------------------+-------+| Variable_name | Value |+-------------------------+-------+| Created_tmp_disk_tables | 0 || Created_tmp_files | 0 || Created_tmp_tables | 1 |+-------------------------+-------+

mysql> SHOW CREATE TABLE city \G*************************** 1. row ***************************Table: cityCreate Table: CREATE TABLE `city` (ÌD` int(11) NOT NULL AUTO_INCREMENT,`Name` char(35) NOT NULL DEFAULT »,`CountryCode` char(3) NOT NULL DEFAULT »,`District` char(20) NOT NULL DEFAULT »,`Population` int(11) NOT NULL DEFAULT ‘0′ ,PRIMARY KEY (ÌD`),KEY Ìdx_cc_population` (`CountryCode`,`Population`)) ENGINE=MyISAM



L’optimiseur estime que le coût de la requête est le même qu’avec le précédent index.Cependant, l’index Idx_cc_population(CountryCode,Population) optimise les per-formances de la requête car il n’y a plus, dans la colonne Extra, ni Using temporaryni Using filesort.

Handler_read_first et Handler_read_next valident le full index scan.

mysql> EXPLAIN SELECT AVG(Population) FROM city GROUP BY CountryCode\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: ctype: indexpossible_keys: NULLkey: Idx_cc_populationkey_len: 7ref: NULLrows: 4079Extra: Using index

mysql> SHOW STATUS LIKE ‘Last_query_cost’\G*************************** 1. row ***************************Variable_name: Last_query_costValue: 4963.520924

mysql> SHOW STATUS LIKE ‘handler%’;+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Handler_read_first | 1 || Handler_read_key | 0 || Handler_read_next | 4079 || Handler_read_prev | 0 || Handler_read_rnd | 0 || Handler_read_rnd_next | 0 || Handler_update | 0 || Handler_write | 0 |+----------------------------+-------+

mysql> SHOW SESSION STATUS LIKE 'sort%';+-------------------+-------+| Variable_name | Value |+-------------------+-------+| sort_merge_passes | 0 || sort_range | 0 |



203

Pas de tris ni de table(s) temporaire(s). Avec l’index Idx_cc_population, la requêteest donc plus performante.

Les droits des utilisateursMySQL permet une gestion très fine des droits. La granularité des permissions va del’instance à la colonne en passant par les tables et les schémas. La principale règle estque l’application ne doit pas avoir tous les droits, pour des raisons évidentes de sécurité.

Un découpage des rôles sur le serveur de production peut ressembler à ceci :• Tous les droits pour l’administrateur de l’instance (root). Seul le DBA possède ce

mot de passe ; il a le droit de créer les utilisateurs et les divers objets (schémas,tables, procédures stockées...).

• Pour l’applicatif qui ne fait que lire, les droits de lecture sur les tables (ou sché-mas) de l’application : GRANT SELECT ON appli.* TO user_appli@’%’

IDENTIFIED BY ’mot_de_passe’;.• Pour l’applicatif qui modifie les données, les droits de modification sur les tables

(ou schémas) de l’application : GRANT INSERT, DELETE, UPDATE ON appli.* TOuser_appli@’%’ IDENTIFIED BY ’mot_de_passe’;.

• Pour la réplication : GRANT REPLICATION SLAVE ON *.* TO user_appli@’%’

IDENTIFIED BY ’mot_de_passe’;.

N’oubliez pas qu’il faut sécuriser le mot de passe : il doit être composé d’un mélangede chiffres, de lettres minuscules et majuscules, de caractères non alphabétiques et ildoit comporter plus de 8 caractères.

D’une manière générale, il ne faut donner à l’utilisateur que les droits pour qu’il fassece qu’il doit faire et surtout pas plus. Une attention particulière doit être portée auxdroits SUPER qui permet de changer des variables de configurations serveur à chaud,

| sort_rows | 0 || sort_scan | 0 |+-------------------+-------+

mysql> SHOW SESSION STATUS LIKE 'created%';+-------------------------+-------+| Variable_name | Value |+-------------------------+-------+| Created_tmp_disk_tables | 0 || Created_tmp_files | 0 || Created_tmp_tables | 0 |+-------------------------+-------+



FILE qui autorise d’écrire et de lire des fichiers sur le serveurs et GRANT OPTION quiautorise de donner ses droits à un autre utilisateur.

Évitez de créer des utilisateurs avec pour host un Fully Qualified Domain Name ouFQDN (comme mysql1.eyrolles.com) ; préférez une adresse IP (comme213.244.11.247).

Avec un FQDN, à chaque connexion le serveur devra demander au DNS derésoudre l’adresse. Cela a un impact sur la durée de connexion (qui peut être nonnégligeable ; l’un des auteurs de cet ouvrage a constaté sur l’une de ses machines unsurcoût d’une à deux secondes à chaque connexion d’un client sur le serveur car leDNS était particulièrement lent). L’option skip-name-resolve désactive larecherche de noms par DNS.

Optimisations pour InnoDB, MyISAM et MEMORY

Optimisation InnoDBLa structure en grappe de l’index d’InnoDB lui permet de stocker en mémoire aussibien ses index que ses données. C’est la variable innodb_buffer_pool_size qui con-trôle la taille de ce cache (c’est d’ailleurs plus un cache qu’un buffer). Cette variableest extrêmement importante pour les performances des tables InnoDB, car commevous vous en doutez, plus sa taille est importante, plus les I/O sont minimisés. Surun serveur dédié, avec seulement des tables InnoDB pour votre application (sansprendre en compte les tables système qui sont en MyISAM et doivent absolument lerester), on peut le monter, si nécessaire, jusqu’à 80 % de la RAM.

Pour ses propres journaux, InnoDB permet de gérer leurs tailles, leur nombre et lataille de leur buffer.

innodb_log_file_size permet de spécifier la taille des journaux. Des fichiers degrande taille diminuent les I/O mais augmentent les temps de restauration. 128 Moest en général une bonne valeur.

innodb_log_buffer_size définit la taille du buffer des journaux. Entre 1 et 8 Mosont en général suffisants.

innodb_log_files_in_group est le nombre de journaux d’InnoDB. La valeur pardéfaut est 2. Il n’y a pas de raisons de la changer dans la plupart des cas.

Les valeurs préconisées sont, bien entendu, à affiner en fonction de vos applications.

InnoDB étant ACID, chaque transaction validée (COMMIT) conduit à un accès disquepour la flusher, c’est-à-dire l’écrire sur le disque et donc la rendre persistante (ou



205

durable, la lettre D de ACID). Ce comportement peut être modifié en empêchant leflush à chaque COMMIT pour limiter les I/O et ainsi gagner en performance. Il y auraalors un flush par seconde environ, lors des checkpoints d’InnoDB. L’inconvénientest que, dans le pire des cas, vous pourrez perdre une seconde de transactions. Lavariable est innodb_flush_log_at_trx_commit. Elle peut prendre trois valeurs :• 0 : accès disque seulement lors des checkpoints. Il y a un risque de perdre des

transactions en cas d’arrêt brutal de MySQL ou de la machine hôte.• 1 : le comportement par défaut. Chaque transaction validée est écrite sur le dis-

que.• 2 : accès disque lors des checkpoints. Il y a un risque de perdre des transactions en

cas d’arrêt brutal de la machine hôte (mais pas de l’instance mysqld de MySQL).

Le cache du dictionnaire des tables en InnoDB est paramétrable avec l’optioninnodb_additional_mem_pool_size. La taille usuelle varie entre 8 et 16 Mo, valeur àaugmenter si la commande SHOW ENGINE INNODB STATUS vous le demande ou si vousgérez un très grand nombre de tables InnoDB.

L’option innodb_flush_method permet de configurer la manière dont InnoDB inter-agit avec le système de fichiers. La liste complète des valeurs qu’elle peut prendre estdisponible dans la documentation. Nous vous conseillons O_DIRECT ou la valeur pardéfaut, notamment si vous travaillez sous environnement MS Windows.

Optimisation MyISAMContrairement à InnoDB, le moteur MyISAM ne stocke que ses index dans uncache : le key_buffer. Le moteur laisse le soin au système d’exploitation de gérer lesenregistrements. Le cache d’index de MyISAM a néanmoins le même but que lesautres caches, celui de minimiser les I/O. L’option qui permet de le paramétrer estkey_buffer_size. Le buffer n’est pas alloué entièrement d’un seul coup mais enfonction des besoins. Sur un serveur dédié, qui ne contient que des tables MyISAM,il peut représenter aux alentours de 30 % de la RAM voire jusqu’à 50 % mais pasplus, car le système d’exploitation risque de swaper. Une bonne méthode est de cal-culer la taille des index des tables MyISAM (.MYI) du serveur.

Pour mesurer son efficacité, il faut surveiller les variables d’état key_reads, qui repré-sentent le nombre de blocs de l’index lus sur le disque, et key_read_requests, quidonnent le bloc de l’index lu dans le key_buffer.

On obtient donc : Hit ratio = 100 - ((key_reads * 100)/key_read_requests)

Cette valeur doit être supérieure à 99,97 %. Dans le cas contraire, revoyez votreschéma, optimisez vos requêtes et/ou augmentez key_buffer_size dans la limite des30 à 50 % pour un serveur dédié avec seulement des tables MyISAM.



Si certaines des tables sont plus critiques que d’autres et doivent absolument placerleurs index dans le cache, vous avez la possibilité de créer d’autres caches que vouspourrez dédier à une ou plusieurs tables. Il vous revient de les paramétrer correcte-ment pour que les index y tiennent entièrement. Si c’est nécessaire, vous pouvez éga-lement précharger les index dans le cache, ce qui évitera aux premières requêtesd’aller les chercher sur le disque.

Cache d’index multiples

Extrait de la section [mysqld] du fichier my.cnf

Contenu du fichier mysqld_init.sql

Le moteur de stockage MyISAM implémente le verrou niveau table, ce qui rend cetype de tables peu performantes dans un environnement avec beaucoup de lectures etd’écritures. Il est cependant possible de paralléliser SELECT et INSERT grâce à l’optionconcurrent_insert. Elle prend trois valeurs :• 0 : les requêtes INSERT se comportent comme les autres requêtes d’écriture ; elles

doivent attendre que la commande SELECT se termine pour relâcher le verrou enlecture sur la table ;

• 1 : la valeur par défaut. Si une opération SELECT est en cours sur la table, la com-mande INSERT peut être effectuée seulement s’il n’y a pas de trous (causés par desinstructions DELETE) dans la table, c’est-à-dire si SHOW TABLE STATUS a la colonneData_free qui vaut 0. La priorité est donc de boucher les trous ;

• 2 : les requêtes INSERT ne sont pas gênées par les SELECT. Les trous ne seront pasbouchés et les tables auront besoin d’être entretenues avec la commande OPTIMIZETABLE, s’il y a des DELETE, pour boucher les trous.

[mysqld]key_buffer_size=2G # taille du cache d’index communcache_idx_table1_table2.key_buffer_size=1G; # Création d’un cache d’index appelé cache_idx_table1_table2 avec une taille de 1 Gocache_idx_table3.key_buffer_size=500M; # Création d’un cache d’index appelé cache_idx_table3 avec une taille de 500Moinit_file=/usr/mysql/data/mysqld_init.sql# fichier d’initialisation qui contient les ordres pour assigner les tables dans leurs caches respectifs et pour pré-charger les index.

CACHE INDEX db.t1, db.t2 IN cache_idx_table1_table2; CACHE INDEX db.t3 IN cache_idx_table3;LOAD INDEX INTO CACHE db.t1, db.t2,db.t3;



207

Optimisation MemoryLes données et les index des tables qui ont pour moteur de stockage Memory sontstockés uniquement en mémoire (seule la structure est persistante car un fichier .frm estcréé). Les avantages d’un tel moteur sont la rapidité d’accès aux données et les deux algo-rithmes d’index hash et B-tree qu’il implémente (consultez la section « Les index »,page 172).

Au rayon des inconvénients, outre le risque de perdre toutes les données à l’arrêt duserveur, vous devez faire attention à ce que données et index n’utilisent pas toute lamémoire disponible. Avec l’option max_heap_table_size vous pouvez définir la taillemaximale de toutes les tables Memory du serveur. Attention, cette option n’est pasrétroactive, les tables Memory déjà créées ne sont pas affectées. Il vous faudra alors lesrecréer en effectuant soit une commande ALTER TABLE ...ENGINE =Memory, soit uneopération CREATE TABLE ou alors TRUNCATE TABLE (qui supprime la table et la recrée).

Il est possible de fixer la taille maximale individuellement, avec l’option MAX_ROWS.Elle se place dans la syntaxe de création ou de modification de la table.

Si vous voulez vous assurer que les tables Memory contiennent des données dès ledémarrage du serveur MySQL, vous pouvez utiliser l’option init-file qui va lire unfichier contenant des requêtes SQL au démarrage. Dans ce fichier, vous pourrezinsérer des requêtes pour charger les données (LOAD DATA INFILE, INSERT INTO …SELECT). C’est très utile en cas d’arrêt brutal.

Le cache de requêtes (query cache)Le cache de requêtes ou query cache est un système de cache mémoire interne àMySQL, transparent pour l’application, qui ne stocke que les requêtes SELECT et leurrésultat.

ATTENTION Limiter la taille des tables

max_heap_table_size est une limite par table. Il est tout à fait possible de saturer la mémoire encréant une multitude de tables.

RAPPEL Limitations du moteur Memory

Le moteur de stockage Memory ne supporte pas les types de champs TEXT et BLOB. De plus, tous sesenregistrements sont de taille fixe, c’est-à-dire qu’une colonne de type VARCHAR(255) sera stockéecomme un CHAR(255) qui utilise (en général) plus d’espace.



Pour des raisons de performance, les requêtes sont hachées avant d’être stockées dans lecache. La fonction de hachage est la fonction MySQL password(). L’inconvénient decette méthode est que les requêtes doivent être strictement identiques (même casse,mêmes espaces...) pour une utilisation optimale du cache. Bien qu’elles renvoient lemême résultat, les trois requêtes suivantes sont différentes pour le cache de requêtes :

En vérifiant les valeurs de hachage respectives, on obtient :

Figure 7–3Le cache de requêtes

SELECT nom, prenom FROM client WHERE client_id=123 SELECT nom, prenom FROM client WHERE client_id=123; /*plusieurs espaces entre client et WHERE. */select nom, prenom FROM client WHERE client_id=123; /* À cause de la casse du select */

mysql> SELECT PASSWORD('SELECT nom, prenom FROM client WHERE client_id=123'); +----------------------------------------------------------------+ | PASSWORD('SELECT nom, prenom FROM client WHERE client_id=123') | +----------------------------------------------------------------+ | *79210368274F82B25F2CABB01CEF24CE7FED24BD | +----------------------------------------------------------------+



209

En cas de modifications d’une table dont les données sont dans le cache, toutes lesrequêtes en relation avec cette table sont invalidées ; le cache de requêtes est toujours àjour. Il n’est donc en général pas pertinent de placer en cache les requêtes SELECT sur destables très souvent modifiées. Le cache de requêtes est en revanche utile lorsque :• les modifications sur les tables ne sont pas très fréquentes ;• il y a beaucoup de requêtes de lectures identiques ;• les tables sont en MyISAM, un peu moins pour InnoDB à cause de l’implémen-

tation du MVCC ;• vous utilisez plusieurs petites tables au lieu d’une seule volumineuse ;• si vous envoyez vos écritures par lots (type batch), l’invalidation n’aura lieu qu’une fois.

Il est difficile de savoir de prime abord si le cache de requêtes va avoir un impactpositif ou non. Son efficacité est lié au type de requêtes SELECT, à leur fréquence et àla fréquence des écritures dans les tables... Le gain n’est pas évident et est loin d’êtresystématique, car pour chaque requête qui arrive sur le serveur, MySQL doit en plusde l’analyser, la hacher, vérifier si elle est présente dans le cache et tout ceci a un coût.Une requête qui renvoie un gros résultat peut être intéressante à placer dans le cachesi sa durée d’exécution est longue. Mais si elle doit prendre de la place en évinçant ungrand nombre de requêtes, ces dernières causeront des accès disque supplémentairespour être à nouveau insérées dans le cache.

Vous pouvez calculer le taux d’efficacité du cache de requêtes avec la formulesuivante : Qcache_hits/(Qcache_hits + Com_select). Bien entendu, plus le résultatest élevé, plus le cache est intéressant. Cependant, même un résultat de 50 % pour-rait signifier qu’il apporte un gain... Finalement, la seule vraie règle que l’on peutvous donner, qui est de plus tout le temps valable, est de tester !

mysql> SELECT PASSWORD('SELECT nom, prenom FROM client WHERE client_id=123'); +-----------------------------------------------------------------+ | PASSWORD('SELECT nom, prenom FROM client WHERE client_id=123') | +-----------------------------------------------------------------+ | *80F8F4FEF436C414CFE5EAB91BDB67895A6DEB22 | +-----------------------------------------------------------------+

mysql> SELECT PASSWORD('select nom, prenom FROM client WHERE client_id=123'); +----------------------------------------------------------------+ | PASSWORD('select nom, prenom FROM client WHERE client_id=123') | +----------------------------------------------------------------+ | *D6FE3655027A6CBDECA109577D33BCEBB5DFDCA7 | +----------------------------------------------------------------+



Gestion du cache de requêtesLe cache de requêtes n’est pas utilisable par défaut, car la variable query_cache_sizevaut 0. Pour l’activer, il faut lui donner une taille en octets dans le fichier de configu-ration. Vous pouvez cependant l’activer à chaud avec la commande SET GLOBAL

query_cache_size. Assurez-vous également que la variable query_cache_type estdifférente de OFF.

Il peut prendre trois valeurs :• ON : les requêtes SELECT sont mises en cache. Une certain nombre de critères doi-

vent cependant être respectés :– la clause SQL_NO_CACHE ne doit pas être présente dans la requête SELECT ;– le résultat renvoyé doit être inférieur à la valeur de query_cache_limit ;– la requête ne doit pas contenir de fonctions non déterministes (now, rand,

current_date...).• DEMAND : ne stocke que les requêtes contenant la clause SQL_CACHE.• OFF : désactive le cache. Notez que la mémoire n’est désallouée que siquery_cache_size = 0.

Pour une optimisation maximale, il est parfois nécessaire de choisir explicitement lesrequêtes qui iront dans le cache. Dans ce cas, réglez query_cache_type à DEMAND etsélectionnez vos requêtes en ajoutant la clause SQL_CACHE.

Le cache peut être défragmenté avec la commande FLUSH QUERY CACHE. Elle ne levidera pas. Si c’est ce que vous recherchez, utilisez alors la commande RESET QUERYCACHE. FLUSH TABLES vide également le cache de requêtes, comme si vous redémar-riez le serveur.

Les variables d’état à surveiller sont :• Qcache_free_blocks : nombre de blocs libres ;• Qcache_free_memory : mémoire libre ;• Qcache_hits : nombre de fois qu’il a servi ;• Qcache_inserts : nombre de requêtes insérées ;• Qcache_lowmem_prunes : nombre de requêtes supprimées par manque de place ;• Qcache_not_cached : nombre de requêtes impossibles à placer en cache ;• Qcache_queries_in_cache : nombre de requêtes dans le cache ;• Qcache_total_blocks : nombre de blocs de mémoire.

ATTENTION Taille du cache de requêtes

Les phases d’invalidation peuvent être assez coûteuses. Il est donc recommandé de ne pas donner unetaille trop importante au cache de requêtes (128 à 256 Mo maximum).



211

Le partitionnementLe partitionnement est un type d’architecture qui consiste à diviser une table en plu-sieurs parties. Cette technique de conception peut être une solution pour augmenterles performances de votre application notamment si le volume de données est impor-tant. Les tables peuvent être partitionnées verticalement, c’est-à-dire découpées dansle sens des colonnes, ou horizontalement, découpées cette fois dans le sens des enre-gistrements. MySQL ne gère automatiquement que le partitionnement horizontaldepuis la version 5.1 ; c’est donc ce type que nous allons évoquer ci-après.

L’optimiseur sait sur quelles partitions se trouve chaque enregistrement. Il se peutalors, si les données recherchées ne se trouvent pas sur toutes les partitions, que letemps de réponse d’une recherche s’en trouve amélioré. Ce mécanisme s’appelle le

Figure 7–4Les différents types de parti-tionnement



pruning ; en d’autres termes, c’est la faculté d’analyser seulement les partitions quicontiennent les enregistrements recherchés.

La clause PARTITIONS de la commande EXPLAIN permet de connaître les partitionsanalysées par l’optimiseur.

Visualisation des partitions parcourues par le plan d’exécution sur deux scénarios

MySQL propose quatre types de partitionnement. Il se définit au niveau de la struc-ture de la table, lors de la création ou en modifiant sa structure :• RANGE : permet de spécifier des intervalles de valeurs ;• LIST : est une division des données sous forme de listes de valeurs ;• HASH : est l’utilisation d’une clé de hachage pour répartir les données de façon

homogène ;• KEY : est similaire au type HASH mais avec moins de contraintes.

Les principaux moteurs de stockage acceptent le partitionnement (InnoDB, MyISAM,Memory...). La clé de partitionnement, c’est-à-dire la ou les colonnes choisies pour être

mysql> EXPLAIN PARTITIONS SELECT * FROM City_range\ G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: City_range partitions: p0,p1,p2,p3,p4 type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 4079 Extra:

mysql> EXPLAIN PARTITIONS SELECT * FROM City_range WHERE id IN (1974, 1999, 1001)\G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: City_range partitions: p1 type: range possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: NULL rows: 3 Extra: Using where



213

partitionnées, doit être de type entier ou composée d’une fonction qui retourne un entierou une valeur NULL. Cette limitation ne s’applique cependant pas pour le partitionne-ment par KEY. Si la table possède un index unique ou une clé primaire, la clé de partitiondoit être au moins une partie de cet index unique (ou clé primaire).

Le partitionnement par RANGE

Pour chaque partition, la valeur doit être strictement inférieure à la borne. Parexemple, dans la partition p_id_moins_de_128 seront stockées les valeurs comprisesentre 64 et 127. L’ordre des partitions est important : elles ne peuvent être définiesque de la plus petite à la plus grande et la clause MAXVALUE, qui permet de spécifier laborne maximale de toutes les partitions, ne peut être que la dernière de la liste.

Le plus important dans le partitionnement est le choix de la clé de partitionnement.Ce choix s’effectue principalement en fonction du type de requêtes exécutées sur latable. L’algorithme RANGE est très utile pour partitionner des dates. Mais les typesdatetime et timestamp de MySQL ne sont pas des entiers. Il faut donc utiliser unefonction sur cette colonne qui renvoie un entier ou la valeur NULL.

La fonction YEAR() est toute indiquée : elle extrait l’année d’une date et la retournesous la forme d’un entier. Une autre fonction recommandée est TO_DAYS(). Elleprend une date en entrée et retourne un entier qui représente le nombre de joursdepuis l’année 0. La fonction peut également être placée lors de la définition dechaque partition. Notez que la valeur NULL est considérée comme étant inférieure àtous les nombres entiers. En d’autres termes, si le champ a des valeurs NULL, ces der-nières iront dans la première partition.

PARTITION BY RANGE (ID) ( PARTITION p_id_moins_de_64 VALUES LESS THAN (64), PARTITION p_id_moins_de_128 VALUES LESS THAN (128), PARTITION p_id_moins_de_256 VALUES LESS THAN (MAXVALUE));

PARTITION BY RANGE (YEAR(date_inscription)) ( PARTITION p1 VALUES LESS THAN (1970), PARTITION p2 VALUES LESS THAN (1980), PARTITION p3 VALUES LESS THAN (1990), PARTITION p4 VALUES LESS THAN (2000), PARTITION p5 VALUES LESS THAN (2010));



Le partitionnement par LIST

Pour partitionner par LIST, il faut indiquer les valeurs acceptées pour chaque parti-tion. L’algorithme LIST permet d’employer la valeur NULL comme valeur de partition-nement. En revanche, si vous essayez d’insérer un nombre qui n’est pas dans la listedes valeurs permises d’une des partitions, une erreur sera lancée par MySQL. Cemécanisme permet de renforcer la cohérence des données dans le SGBDR.

Le partitionnement par HASH

Il faut indiquer le nombre de partitions à créer. L’algorithme de partitionnementHASH est idéal pour les valeurs séquentielles, comme les AUTO_INCREMENT. En effet, ilpermet de distribuer de façon homogène les données dans les différentes partitions. Ladistribution des données sur les partitions est assez simple : c’est un modulo (le reste dela division entière). Si vous disposez de trois partitions, p0, p1 et p2, un enregistrementira dans p0, le suivant dans p1, le suivant dans p2, le suivant dans p0, etc.

Le calcul effectué par MySQL est le suivant :

L’algorithme HASH a une variante, LINEAR HASH, qui a pour effet de rendreplus rapide les tâches de maintenance sur les tables partitionnées (suppression,fusion, ajout...). En contrepartie, la distribution des données sur les différentes parti-tions est moins homogène.

Le partitionnement par KEY

Comme pour le type HASH, il faut indiquer le nombre de partitions à créer. Ce par-titionnement permet lui aussi de distribuer de façon homogène les données dans lesdifférentes partitions. Il se différencie néanmoins par la possibilité donnée à l’utilisa-teur de choisir plusieurs colonnes ou aucune comme critère de partitionnement à

PARTITION BY LIST (nature_message) ( PARTITION p_undef VALUES IN (NULL), PARTITION p_faux VALUES IN (0), PARTITION p_vrai VALUES IN (1));

PARTITION BY HASH (id_ville) PARTITIONS 4 ;

IF(ISNULL(valeur_partition), 0, ABS(valeur_partition)) MOD nbr_de_partitions

PARTITION BY KEY (isbn) PARTITIONS 3 ;



215

condition qu’elles appartiennent toutes à la clé primaire (ou un index unique), oualors que la table ne contienne pas de clé primaire ou d’index unique.

Partitionner sur différents disquesLes tables MyISAM peuvent stocker leurs partitions à des endroits différents de celuidu répertoire de données par défaut. Ceci est valable pour les fichiers de données(.MYD) mais également pour les fichiers d’index (.MYI). Cette possibilité est bien pra-tique en cas de fortes charges et/ou de gros volumes de données, pour répartir les don-nées et la charge de votre application sur plusieurs disques. Notez que cette fonctionna-lité n’est disponible que pour MyISAM mais pas en environnement MS Windows.

Partitionner sur différents disques avec MyISAMLa syntaxe à appliquer est la suivante :

CREATE TABLE `message` ( `message_id` tinyint(3) unsigned NOT NULL AUTO_INCREMENT, `message_texte` varchar(60000) NOT NULL DEFAULT '', KEY ìdx_message_id` (`message_id`)) ENGINE = MYISAMPARTITION BY HASH(message_id) ( PARTITION m1 DATA DIRECTORY = '/disque1/donnee' INDEX DIRECTORY = '/disque1/index' , PARTITION m2 DATA DIRECTORY = '/disque2/donnee' INDEX DIRECTORY = '/disque2/index', PARTITION m3 DATA DIRECTORY = '/disque3/donnee' INDEX DIRECTORY = '/disque3/index');

BON À SAVOIR Évolution du partitionnement

Certaines contraintes sont levées à partir de MySQL 5.5. Il est par exemple possible de partitionner unetable en fonction de plusieurs colonnes qui peuvent être de type entier, chaîne (char, varchar), DATEou DATETIME.B http://dev.mysql.com/doc/refman/5.5/en/partitioning.html



Les architectures modernes doivent faire face de plus en plus fréquemment à diversesproblématiques telles que le dimensionnement, la tolérance aux pannes ou encore lacontinuité de services. Une des réponses apportées par les systèmes de gestion debases de données est la possibilité de pouvoir générer et gérer plusieurs copies desdonnées (ou répliques). MySQL implémente, depuis la version 3.23.15, une solutionde réplication native, gratuite et plutôt simple à mettre en œuvre, qui se nomme toutsimplement MySQL replication.

Introduction à la réplicationAvant de présenter les différents mécanismes de la réplication, définissons quelquestermes qui seront employés dans ce chapitre.

La réplication est un procédé qui consiste à recopier des données sur plusieurs serveurs.Une réplication peut être synchrone : un serveur A envoie des données à un serveur Bet doit attendre que ce dernier finisse son traitement et le prévienne (avec un accusé deréception, par exemple), pour qu’il puisse poursuive. Une réplication peut égalementêtre asynchrone : dans ce cas, le serveur A n’attend pas de réponse du serveur B pourcontinuer. Les serveurs répliqués sont de deux types : le maître, qui contient les don-nées de référence, et l’esclave, qui s’y approvisionne.

8La réplication MySQL



La réplication MySQL est asynchrone, ce qui permet d’obtenir de bonnes perfor-mances. En revanche, au moment où ces lignes sont écrites, il n’existe aucun méca-nisme intégré dans MySQL qui permette de s’assurer que les répliques contiennentexactement les mêmes données. Cependant, des alternatives existent comme la répli-cation semi-synchrone de la MySQL Replication Team (http://forge.mysql.com/wiki/Repli-cationFeatures/SemiSyncReplication), MysqlSyncReplication de Google (http://code.google.com/p/google-mysql-tools/wiki/MysqlSyncReplication) ou encore Galera Replication de Codership(http://www.codership.com/en/products/galera_replication).

La réplication est composée d’un seul serveur maître et d’un ou plusieurs serveursesclaves. Si en théorie il n’y a pas de limite au nombre d’esclaves, en pratique les con-traintes sont d’ordre économique et physique (nous reviendrons sur ce dernier pointultérieurement). Toute modification de données doit s’effectuer sur le maître carl’information ne peut circuler que dans un seul sens, du maître vers l’esclave. En

Figure 8–1Architectures de réplication


La réplication MySQLCHAPITRE 8

219

d’autres termes, si des écritures sont exécutées sur un esclave, les répliques ne serontplus identiques. Une conséquence de cette limitation est que le maître peut devenirun goulot d’étranglement à cause des requêtes d’écritures. Autre point épineux, larécupération des données du maître par l’esclave est réalisée par un seul thread, ce quipeut entraîner en cas de forte charge sur le maître ou sur l’esclave, ou si ce dernier estmoins performant, des retards de réplication.

La réplication offre une grande diversité d’architectures, du simple « un maître et unesclave » à des chaînes de serveurs.

Intérêt de la réplicationUne application reste rarement figée ; ses fonctionnalités peuvent changer au gré desbesoins du client ou de nouvelles contraintes. Il suffit par exemple que votre applica-tion web gagne en popularité, pour que la base de données qui ne se faisait pasremarquer jusque-là, commence à montrer des signes d’essoufflement et ce, parceque le volume des données a considérablement augmenté et/ou que la charge desrequêtes s’est démultipliée. Pensez aux coûts liés à une rupture de service qui peuventse chiffrer en centaines de milliers d’euros... est-ce cela la rançon du succès ?

Si vous vous reconnaissez dans ce portrait robot d’une success story annoncée, c’est quevous avez sûrement besoin d’une architecture de base de données qui réponde auxproblématiques de haute disponibilité, de capacités de dimensionnement, de redon-dance géographique ou alors qui vous permette d’opérer des sauvegardes à chaud. Laréplication de MySQL est ce dont vous avez besoin car elle propose des solutions àces différentes problématiques.

Le dimensionnement horizontal (scale out)C’est la possibilité d’assumer une augmentation de la charge des requêtes de lecture,en la répartissant sur plusieurs esclaves. Aucun bénéfice pour les requêtes d’écritureparce qu’elles doivent toutes s’effectuer sur le maître.

La sauvegarde à chaud (hot backup)Un des serveurs esclaves peut servir de serveur de sauvegarde, ce qui permet de réa-liser des sauvegardes à chaud, c’est-à-dire sans impact sur l’application. Attentiontoutefois, une réplique ne peut être considérée comme une sauvegarde. Une requêtemalheureuse sur le maître (DROP TABLE, DELETE/UPDATE sans clause WHERE…) serarépliquée sur les esclaves, y compris celui dédié à la sauvegarde. De plus, la réplica-



tion ne contient, nativement, aucun mécanisme qui permette de s’assurer que toutesles répliques contiennent exactement les mêmes données.

Le basculement automatique (Failover)En cas de panne du serveur actif, l’application peut être basculée sur le serveur passif(actif/passif du point de vue de l’application car le serveur MySQL fonctionne sur lesdeux machines). La continuité de service est alors assurée. Notez que la réplicationétant asynchrone, certaines précautions doivent être prises. Ce point est discuté ulté-rieurement dans ce chapitre.

Redondance géographiqueLa réplication est asynchrone. Ainsi, elle offre la possibilité, sans pénaliser les perfor-mances du serveur maître, de répartir ses données à différents endroits (villes, pays,continents...). C’est un bon moyen de réduire les risques liés aux sinistres et, pour lesclients, d’établir des bases de données locales accessibles uniquement en lecture pourles données répliquées. Notez qu’il est toujours possible d’utiliser ces serveursMySQL locaux, en écriture sur des tables elles aussi locales, ces dernières ne faisantpas partie de la réplication.

Le cas du décisionnelLes esclaves n’ont pas besoin d’être connectés en permanence au maître. Il est doncpossible d’activer et de désactiver la réplication à souhait pour alimenter un entrepôtde données (data warehouse). De plus, la granularité de la réplication étant la table,ces dernières peuvent être réparties sur plusieurs serveurs pour améliorer les perfor-mances des requêtes complexes. Ce point est discuté ultérieurement dans ce chapitre.

Tester une nouvelle version de MySQLLa réplication offre une compatibilité ascendante : il est donc pratique de mettre enplace un serveur de tests comme réplique, pour s’assurer du bon fonctionnement devotre application avec une nouvelle version du serveur ou plus simplement pourtester de nouveaux moteurs de stockage. La version de la réplique doit être supérieureou égale à celle du maître.



221

À l’intérieur de la réplicationLe processus de réplication est assez simple : l’essentiel du travail est réalisé parl’esclave qui se connecte sur le serveur maître avec un compte utilisateur qui possèdele droit REPLICATION SLAVE et l’informe de sa présence. Les étapes du processus (voirfigure 8-2) sont :

1. Une requête d’écriture arrive sur le maître.2. Elle est stockée dans son journal binaire.3. à 6. io_thread la récupère et la copie sur l’esclave dans le journal relais (relaylog).7. Enfin, sql_thread l’exécute sur l’esclave. La requête est répliquée.

Les informations relatives à la réplication sont rendues persistantes grâce à desfichiers créés sur l’esclave :• master.info contient les informations relatives au io_thread comme le nom du

journal binaire du maître, la position dans ce journal, le nom du compte utilisa-teur de réplication, les informations relatives au serveur maître, etc.

• relay-log.info contient les informations relatives au sql_thread comme le nomet la position dans le relay-log, le nombre d’octets lus du journal binaire du maî-tre, etc.

Mise en place de la réplicationMettre en place une architecture de réplication est une opération assez basique. Laprocédure est détaillée dans la documentation officielle de MySQL (http://

Figure 8–2Les détails de la réplication



dev.mysql.com/doc/refman/5.1/en/replication.html). En substance, il faut configurer les deuxtypes de serveurs, le maître et l’esclave comme expliqué ci-après.

Configuration du maître1 Activez le journal binaire dans le fichier de configuration.2 Donnez une valeur unique (parmi toutes les répliques) au paramètre server-id.

Section mysqld issue du fichier de configuration MySQL

3 Créez un utilisateur qui sera employé uniquement pour la réplication. Il ne doitposséder que le droit REPLICATION SLAVE, qui lui permet de n’effectuer que lestâches de réplication.

4 Après redémarrage du serveur MySQL pour que les nouvelles informations pla-cées dans le fichier de configuration soient prises en compte, vérifiez que tout s’estbien déroulé.

Vérification du paramétrage du serveur maître

[mysqld]log-bin = mysql-binserver-id =1

mysql> GRANT REPLICATION SLAVE ON *.* TO replic_user@’%’ IDENTIFIED BY ’P455w0Rd’;

ATTENTION Mot de passe en clair

Le mot de passe de l’utilisateur est stocké en clair dans le fichier master.info. Ce dernier doit doncêtre protégé et c’est une raison supplémentaire de ne donner que le droit REPLICATION SLAVE àl’utilisateur de réplication.

mysql> SHOW VARIABLES LIKE ’server_id’ \G*************************** 1. row ***************************Variable_name: server_id

Value: 1

mysql> SHOW VARIABLES LIKE ’log_bin’ \G*************************** 1. row ***************************Variable_name: log_bin

Value: ON



223

5 La dernière étape consiste à effectuer une sauvegarde du maître en la synchroni-sant avec les journaux binaires. Elle sera restaurée sur l’esclave pour initialiser laréplication. Le but est d’obtenir, à un instant t, deux serveurs avec exactement lesmêmes données. Plusieurs méthodes sont possibles (copie physique à froid,LVM, etc.). L’une d’entre elles est l’utilisation du client texte mysqldump qui per-met de réaliser des sauvegardes logiques (des dumps) HOT si la base ne compteque des tables InnoDB ou WARM (avec un verrou en lecture) dans le cas con-traire. C’est l’option --master-data qui permet la synchronisation de la sauve-garde avec les journaux binaires, en rajoutant, dans le dump, la commande CHANGEMASTER TO MASTER_LOG_FILE=’mysql-bin.xxxxxx’, MASTER_LOG_POS=xxx. Cettecommande est utilisée par le serveur esclave pour paramétrer la réplication. Nousy reviendrons dans quelques lignes.

Si vous utilisez un autre moyen de sauvegarde, vous devez verrouiller la base et récupérerles informations relatives au journal binaire avec la commande SHOW MASTER STATUS.

mysql> SHOW GRANTS FOR replic_user@’%’;*************************** 1. row ***************************Grants for replic_user@%: GRANT REPLICATION SLAVE ON *.* TO ’replic_user’@’%’ IDENTIFIED BY PASSWORD ’*24C0571BAA4117CC0452B2CD186A3DD9D9B3920F’

shell> mysqldump ----lock-all-tables ----master--data ----flush--logs ----routines ----all--databases --u user_dump --p > sauvegarde_totale.sql

mysql> FLUSH TABLES WITH READ LOCK;/* Verrouille toute la base en lecture seule */

mysql> SHOW MASTER STATUS \G*************************** 1. row ***************************

File: mysql-bin.003217 Position: 46239

Binlog_Do_DB: Binlog_Ignore_DB: /* Permet de récupérer le journal et sa position */

/* Effectuer la sauvegarde ! */

mysql> UNLOCK TABLES;/* Et ne surtout pas oublier de déverrouiller */



Attention, le filtre ne fonctionne pas pour les DDL si les requêtes d’écriture sontexécutées depuis un autre schéma. Pour les DML, le mode de journalisation ROWpermet de s’affranchir de cette limitation.

Dans le fichier de configuration du serveur maître, on précise de ne pas stocker dansle journal binaire les requêtes d’écritures concernant les schémas mysql et test.

La connexion au schéma mysql et la création de la table t1 (DDL) dans le schématest sur le serveur maître sont réalisées de la manière suivante :

La table est quand même créée sur le serveur esclave. Le filtre ne fonctionne pas carla requête n’est pas exécutée dans le schéma test du maître.

Différente cause, même effet : le filtre ne fonctionne toujours pas, pour une DMLcette fois.

BON À SAVOIR Filtrage des données répliquées

Vous pouvez choisir de ne répliquer que les données de certaines bases. Le filtre peut prendre place sur leserveur maître. Il consiste à demander au serveur de ne stocker dans le journal binaire que les transac-tions concernant les tables appartenant aux bases sélectionnées avec le paramètre binlog-do-db oualors de lui demander d’ignorer les transactions concernant les bases avec binlog-ignore-db. Laliste des bases filtrées peut être visualisée avec la commande SHOW MASTER STATUS.

[mysqld]binlog-ignore-db = mysqlbinlog-ignore-db = test

mysql_master> USE mysqlmysql_master> CREATE TABLE test.t1(i int);

mysql_slave> SHOW TABLES IN test;+----------------+| Tables_in_test |+----------------+| t1 | +----------------+

mysql_master> INSERT INTO test.t1 (i) VALUES (97224);

mysql_slave> SELECT * FROM test.t1;+-------+| i |+-------+| 97224 | +-------+



225

En revanche, si la requête est exécutée depuis le schéma test du maître, la donnée dela table répliquée de l’esclave n’est pas modifiée. Dans ce cas, le filtre fonctionne :

Configuration de l’esclave1 Donnez une valeur unique au paramètre server-id (différente de celle du maître

et des autres esclaves).

2 Configurez la réplication, en donnant à l’esclave toutes les informations nécessai-res pour qu’il puisse se connecter au maître et surtout à la bonne position dans lebon journal binaire :– MASTER_HOST : adresse IP ou nom d’hôte du serveur maître ;– MASTER_USER : compte que va devoir utiliser l’esclave pour se connecter au ser-

veur maître ;– MASTER_PASSWORD : mot de passe du compte utilisateur de réplication ;– MASTER_PORT : port du serveur maître ;– MASTER_LOG_FILE : nom du journal binaire du maître, dans lequel les données

ont été insérées après la sauvegarde restaurée sur l’esclave ;– MASTER_LOG_POS : position dans le journal binaire du maître.

Si vous avez utilisé mysqldump avec l’option master-data, vous n’avez pas besoin derenseigner ces deux derniers paramètres car ils sont configurés lors de la restauration.Dans le cas contraire, il faut y mettre les valeurs de la commande SHOW MASTER

STATUS exécutée précédemment sur le maître.

mysql_master> USE testDatabase changedmysql_master> UPDATE t1 SET i=93;mysql_slave> SELECT * FROM test.t1;+-------+| i |+-------+| 97224 | +-------+

[mysqld]server-id=10

Restaurer la sauvegarde du maître sur l’esclave :

shell> mysql -u user_restore -p < sauvegarde_totale.sql



3 Et enfin, démarrez la réplication :

Configuration avancée de l’esclavePlusieurs paramètres permettent d’affiner la configuration du serveur esclave. Avecl’option slave_compressed_protocol, il est possible de compresser le flux des don-nées entre le maître et l’esclave au format gzip, mais au prix d’une charge processeurplus importante.

Nous avons vu que la réplication s’effectue du maître vers l’esclave et que si une écri-ture a lieu sur ce dernier, les deux répliques ne sont plus identiques, ce qui peutentraîner une cassure de la réplication. Pour réduire les risques, il est possible deplacer l’esclave en lecture seule avec l’option read_only = 1. Malgré tout, les clientsayant le droit SUPER pourront y écrire.

La réplication se met en route automatiquement à chaque démarrage du serveurMySQL. Ce comportement peut être modifié avec l’option skip-slave-start. Nousvous conseillons d’activer cette option car, en cas d’arrêt imprévu du serveur, il est plusprudent de mener quelques investigations afin de s’assurer que les données sont dansun état cohérent, avant de redémarrer. Vous devrez alors utiliser START SLAVE.

mysql> CHANGE MASTER TO MASTER_HOST = ’23.24.25.1’, MASTER_USER = ’replic_user’, MASTER_PASSWORD = ’P455w0Rd’, MASTER_PORT = 3306;

/* Avec éventuellement MASTER_LOG_FILE = ’mysql-bin.003217’, MASTER_LOG_POS = 46239; */

ATTENTION Ancienne méthode de configuration

Il existe une autre manière de configurer la réplication. Elle consiste à mettre les informations suivantesmaster-host, master-user, master-password et master-port dans le fichier de configu-ration. Mais cette méthode est obsolète et ne sera plus gérée par MySQL dans les futures versions.

mysql> START SLAVE;

REMARQUE Mettre à jour l’esclave avant le maître

Il est conseillé d’utiliser les mêmes versions de MySQL pour toutes les répliques. Néanmoins, en cas deversions majeures différentes, l’esclave doit employer la version ayant le chiffre le plus élevé. L’une desraisons est que si le format des journaux binaires est mis à jour sur le maître d’une version du serveurMySQL plus récente que celle de l’esclave, ce dernier pourrait ne pas être capable de déchiffrer le nou-veau format.



227

Comme vous le savez, le journal binaire stocke toutes les requêtes d’écritures reçuespar le serveur. Les données répliquées sont des requêtes d’écritures et il est doncnaturel de penser qu’elles sont à leur tour stockées dans le journal binaire de l’esclave.Ce n’est pourtant pas le cas par défaut. Pour que cela se produise, il faut activerl’option log_slave_updates sur le serveur esclave.

Les options report_host et report_port permettent respectivement de récupérer lenom d’hôte et le port de l’esclave sur le maître. C’est pratique lorsque l’architecturede réplication comporte beaucoup de serveurs.

MySQL permet de ne répliquer que les données de certaines tables. Le filtre peutfonctionner sur le maître, comme nous l’avons vu au paragraphe précédent ; cepen-dant, il peut également opérer sur l’esclave.• replicate-do-db (replicate-ignore-db) permet de répliquer (ou de ne pas

répliquer) les tables d’un schéma.• replicate[-wild]-do-table (replicate[-wild]-ignore-table) sert à répliquer

(ou à ne pas répliquer) cette table.

Ce type d’architecture sert notamment lorsqu’on désire répartir des données(schémas, tables) sur différents serveurs, ou encore si vous ne souhaitez pas répliquerles tables système qui contiennent les utilisateurs. Attention tout de même, commepour les variables binlog-ignore-db et binlog-ignore-db sur le serveur maître, desprécautions liées au contexte d’exécution des requêtes et au mode de journalisationdoivent être prises. Voir la documentation officielle pour plus de détails.

Filtrage de la réplication sur le serveur esclave

Commandes de la réplicationUne fois l’architecture de réplication mise en place, il faut s’assurer de son bon fonc-tionnement et pouvoir détecter les problèmes. MySQL fournit un ensemble de com-mandes pour la gérer et la superviser.

[mysqld] # serveur esclave parisienreplicate-do-db = fournisseurreplicate-do-db = paris_client[mysqld] # serveur esclave lyonnaisreplicate-do-db = fournisseurreplicate-do-db = lyon_client



Sur l’esclaveLa commande RESET SLAVE efface les fichiers master.info et relay-log.info et réi-nitialise les fichiers relais, en mettant à jour relay-bin.index et en supprimant lesindex relay-bin.xxxxxx pour reprendre la numérotation à .000001 (relay-bin.000001). Elle sert principalement à réinitialiser la réplication lors d’un Failover,après une erreur de réplication, etc.

[START | STOP] SLAVE permet d’arrêter et démarrer la réplication. Néanmoins, unegestion plus fine des threads est possible en ajoutant, à ces deux commandes, le nomde celui que l’on veut manipuler, io_thread ou sql_thread. C’est souvent utile pours’assurer que l’esclave s’arrête à un point précis (lors d’un changement de maître parexemple) ou pour essayer de corriger un problème de réplication.

Une autre possibilité, mais seulement pour la commande START SLAVE, est de pou-voir démarrer et surtout programmer l’arrêt du sql_thread, en s’assurant que les évé-nements du journal binaire du maître ou du journal relais de l’esclave sont exécutésjusqu’à une certaine position. C’est particulièrement utile pour synchroniser deuxserveurs, comme le permet la fonction MASTER_POS_WAIT.

Synchronisation de deux serveurs avec la clause UNTIL de la commande START SLAVE SQL_THREAD

ATTENTION Conséquences d’un RESET SLAVE

Attention à l’utilisation de la commande RESET SLAVE. Une fois exécutée, l’esclave n’aura plusaucune information sur son maître, ni sa position dans le journal binaire, ni dans le journal relais. Il vousfaudra alors remettre en place une réplication avec la commande CHANGE MASTER TO.

mysql> STOP SLAVE io_thread ;/* arrête seulement le thread IO *//* attendre que le sql_thread termine sa tâche */

mysql> STOP SLAVE sql_thread;/* arrête seulement le thread SQL */

/* sur le maître */mysql_master> FLUSH TABLES WITH READ LOCK;

mysql_master> SHOW MASTER STATUS \G*************************** 1. row ***************************


/* sur l’esclave */mysql_slave> START SLAVE SQL_THREAD UNTIL MASTER_LOG_FILE = ’mysql-bin.000019’, MASTER_LOG_POS =121068330;



229

Une autre alternative consiste à utiliser la fonction MASTER_POS_WAIT.

Synchronisation de deux serveurs avec la fonction master_pos_wait

mysql_slave> SHOW SLAVE STATUS \G*************************** 1. row ***************************

… Slave_IO_Running: No Slave_SQL_Running: Yes

… Exec_Master_Log_Pos: 5621573

Until_Condition: Master Until_Log_File: mysql-bin.000017 Until_Log_Pos: 121068330

/* du temps passe...*/mysql_slave> SHOW SLAVE STATUS \G*************************** 1. row ***************************

… Slave_IO_Running: No

Slave_SQL_Running: No … Exec_Master_Log_Pos: 121068330

Until_Condition: Master Until_Log_File: mysql-bin.000019 Until_Log_Pos: 121068330

/* sur le maître */mysql_master> FLUSH TABLES WITH READ LOCK;

mysql_master> SHOW MASTER STATUS \G*************************** 1. row ***************************


/* sur l’esclave */mysql_slave> START SLAVE;

mysql_slave> SELECT MASTER_POS_WAIT(’mysql-bin.000019’, 121068330);/* rend la main quand l’esclave a rattrapé son retard sur le maître */

mysql_slave> STOP SLAVE;


… Slave_IO_Running: No

Slave_SQL_Running: No … Exec_Master_Log_Pos: 121068330



Pour superviser la réplication, une commande suffit : SHOW SLAVE STATUS. Elle récu-père notamment les informations concernant le maître et l’esclave contenues dans lesjournaux master.info et relay-log.info.

Parmi les informations importantes, on peut noter :• Slave_IO_State : donne le statut de io_thread. Par exemple Waiting for

master to send event indique que io_thread a récupéré toutes les données dujournal binaire du maître ;

• Slave_IO_Running et Slave_SQL_Running : si une de ces deux valeurs vaut No, laréplication est arrêtée. Ces deux paramètres sont à surveiller, car c’est grâce à euxque vous vous apercevrez que la réplique ne fonctionne pas normalement (ou plusdu tout) ;

• Read_Master_Log_Pos : position, dans le journal binaire, du dernier événement luet ramené sur l’esclave par io_thread ;

• Exec_Master_Log_Pos : position du dernier événement, du journal relais, exécutépar sql_thread ;

• Master_Log_File : nom du dernier journal binaire du maître ;• Relay_Master_Log_File : nom du journal binaire dans lequel io_thread a lu son

dernier événement.

• quelques mots sur la variable Seconds_Behind_Master, qui estime le nombre desecondes de retard qu’a l’esclave sur le maître. Ce temps est calculé en comparant lavaleur du timestamp du serveur esclave avec celui enregistré au moment de l’écrituredes événements dans le journal binaire (consultez le chapitre 5 sur les journaux pourplus d’explications). Ce nombre peut être imprécis à cause de plusieurs raisons(réseau instable, une transaction très longue, etc.) ; il faut donc le prendre pour cequ’il est, c’est-à-dire une estimation. Cependant, des outils de meilleure précisionexistent, comme le script mk-heartbeat du maatkit (http://www.maatkit.org/) ;

• Last_Error indique l’erreur courante ayant causé l’arrêt de la réplication. Vousretrouverez ces informations dans le journal des erreurs.

ASTUCE Comment savoir si le serveur esclave a du retard ?

Avec ces quatre variables, vous pouvez savoir si le serveur esclave a du retard sur le serveur maître. Ilfaut pour cela que Read_Master_Log_Pos = Exec_Master_Log_Pos ainsi queMaster_Log_File = Relay_Master_Log_File.



231

La commande SHOW SLAVE STATUS

Une autre façon de s’assurer du bon fonctionnement des threads io_thread etsql_thread est d’exécuter la commande SHOW STATUS LIKE ’Slave_running’. Elleretournera la valeur ON si et seulement si Slave_IO_Running =

YesetSlave_SQL_Running = Yes.

mysql> SHOW SLAVE STATUS \G*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 23.24.25.1Master_User: replic_userMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000017Read_Master_Log_Pos: 31135551Relay_Log_File: mysql-relay-bin.000047Relay_Log_Pos: 31135684Relay_Master_Log_File: mysql-bin.000017Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 31135551Relay_Log_Space: 31135684Until_Condition: NoneUntil_Log_File: Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error: Last_SQL_Errno: 0Last_SQL_Error:



De plus, si vous avez renseigné dans le fichier de configuration de l’esclave les para-mètres report-host et report-port, alors il est possible de consulter ces informa-tions avec la commande SHOW VARIABLES LIKE ’report%’;

Enfin, la commande SHOW PROCESSLIST permet de connaître l’état de io_thread etde sql_thread.

Visualiser l’état de io_thread et de sql_thread

Sur le maîtreSur le serveur maître, deux types d’informations vont être utiles : les données liéesaux connexions esclaves et celles du journal binaire.

SHOW SLAVE HOSTS permet d’obtenir des informations (server_id, nom d’hôte,port...) des esclaves connectés aux maîtres, sous réserve que les paramètresreport_host, report_port... soient renseignés dans le fichier de configuration desesclaves. Les renseignements concernant les threads sont disponibles avec la com-mande SHOW PROCESSLIST.

mysql> SHOW PROCESSLIST \G*************************** 1. row ***************************

Id: 12 User: system user Host:

db: NULLCommand: Connect

Time: 91 State: Waiting for master to send event Info: NULL

*************************** 2. row *************************** Id: 13 User: system user Host:

db: madininaCommand: Connect

Time: 87 State: update Info: INSERT INTO utilisateur VALUES (2101913295,’Florian’,15,

852645)

ASTUCE Déconnexion d’un serveur esclave

Les commandes SHOW PROCESSLIST et SHOW SLAVE HOSTS ne permettent pas de s’apercevoirqu’un esclave vient de se déconnecter. Pour forcer MySQL à mettre à jour leurs informations, exécutez lacommande FLUSH PRIVILEGES.



233

SHOW GRANTS FOR peut être également utile notamment pour s’assurer que le compteesclave ne possède que les droits strictement nécessaires, c’est-à-dire REPLICATION SLAVE.

En ce qui concerne la gestion du journal binaire, les commandes sont nombreuses :SHOW MASTER STATUS, SHOW BINARY LOGS, SHOW BINLOG EVENTS, SHOW BINLOG

EVENTS, PURGE MASTER LOGS et RESET MASTER. Elles sont détaillées dans le chapitre 5,sur les journaux de MySQL.

Problèmes liés à la réplicationLes performances et la fiabilité de la réplication s’améliorent à chaque nouvelle ver-sion. Malheureusement, vous serez confronté un jour ou l’autre à un problèmevenant d’un arrêt brutal de serveur ou d’une erreur de manipulation. Il vous faudradès lors trouver l’origine du problème et le corriger en laissant les données dans unétat cohérent. Dans ce paragraphe, nous allons essayer de vous donner des méthodeset astuces afin d’établir un diagnostic pertinent dans l’optique de réparer votre répli-cation dans les plus brefs délais.

En cas de soucis, le premier réflexe est de consulter le journal des erreurs. La proba-bilité d’obtenir une indication sur la nature du problème et un début de piste d’inves-tigation est plutôt élevée.

En cas de problèmes lors du premier lancement de la réplication, vérifiez les pointssuivants :1 Le journal binaire est-il activé sur le maître ?2 Le server-id est-il unique sur chacune des répliques ?3 L’utilisateur de réplication a-t-il le droit REPLICATION SLAVE. Son mot de passe

est-il correct ?4 La connexion au serveur maître avec le compte de réplication fonctionne-t-elle

(mysql -u replic_user -h 23.24.25.1 -pP455w0Rd) ?5 Les informations de la commande CHANGE MASTER TO sont-elles correctes ? Véri-

fiez avec SHOW SLAVE STATUS.6 La configuration permet-elle des connexions (locales ou distantes) au serveur

(skip-networking, bind-address, parefeu...) ?7 Votre serveur a-t-il besoin de stocker dans son journal binaire les événements de

la réplication (placez log-slave-updates dans le fichier de configuration) ?

ATTENTION RESET MASTER peut casser la réplication

Une attention particulière doit être portée à la commande RESET MASTER qui efface tous les journauxbinaires. Elle doit être utilisée avec précaution en cas de réplication, car le risque de la casser est élevé.



Les problèmes les plus couramment rencontrés sont la plupart du temps liés auxthreads io_thread et sql_thread.

IO_THREAD stoppéSi le thread io_thread est stoppé, cela peut être dû à un problème de connexion avecle maître. Vérifiez la connexion de l’esclave sur le maître (nom d’hôte, port...), la pré-sence de l’utilisateur de réplication, ses droits, le parefeu...

Autre piste : io_thread ne trouve pas le journal binaire car il a été malencontreuse-ment effacé, corrompu... Utilisez la commande SHOW SLAVE STATUS afin de vérifierles informations de connexions (nom de journal binaire, la bonne casse, le bonnuméro…). En cas de corruption du fichier, vous avez toujours la possibilité d’uti-liser mysqlbinlog ou votre éditeur hexadécimal préféré pour essayer de récupérer lestransactions (consultez le point PITR du chapitre 5, page 157). Cependant, il estsouvent plus simple de réinitialiser la réplication en repartant d’une sauvegarde dumaître. De plus, si vous ne récupérez pas toutes les transactions, le maître et l’esclavepeuvent ne plus être cohérents.

SQL_THREAD stoppéSi le thread sql_thread est stoppé, c’est probablement à cause d’un problème derequêtes sur l’esclave. SHOW SLAVE STATUS indiquera l’erreur dans son champLast_Error. À ne pas confondre avec Last_IO_Error et Last_SQL_Error qui mon-trent l’erreur précédente. Une requête exécutée sur le maître mais qui ne s’exécute passur l’esclave peut signifier que les deux bases de données ne contenaient pas les mêmesdonnées ou la même structure. Le maître et l’esclave ont-ils été correctement synchro-nisés lors de l’initialisation de la réplication ? Y a-t-il eu des écritures sur l’esclave ?

Il est possible de rendre le serveur esclave en lecture seule grâce au paramètre read-only. La réparation dépendra de l’ampleur de la tâche. Vous avez la possibilité deréparer manuellement, en exécutant les requêtes directement sur l’esclave pour cor-riger la situation et en ignorant ensuite la requête qui échoue avec la variable globale

shell> tail -n1 mysql-error.err091015 18:14:06 [ERROR] Slave I/O: error connecting to master ’[email protected]:23150’ - retry-time: 60 retries: 86400, Error_code: 1045

shell> tail -n1 mysql-error.err091015 18:07:43 [ERROR] Error reading packet from server: File ’./mysql-bin.000025’ not found (Errcode: 2) ( server_errno=29)



235

sql_slave_skip_counter. Cette variable ne fonctionne que si sql_thread est arrêté.Attention tout de même, car mal utilisé l’esclave risque de ne pas avoir les mêmesdonnées que le maître.

Ignorer une requête avec la (dangereuse) commande sql_slave_skip_counter

Là encore, la correction manuelle peut être particulièrement coûteuse. Si vous êtesdans ce cas de figure, il ne vous reste alors plus qu’à réinitialiser la réplication enreprenant les étapes exposées auparavant, c’est-à-dire effectuer une sauvegarde duserveur maître en la synchronisant avec le journal binaire, la rejouer sur l’esclave, évo-quer la commande CHANGE MASTER TO puis lancer la réplication avec SLAVE START.


… Slave_IO_Running: Yes Slave_SQL_Running: No

… Last_Errno: 1396 Last_Error: Error ’Operation DROP USER failed for

’linda’@’%’’ on query. Default database: ’world’. Query: ’drop user toto’mysql_slave> SET GLOBAL sql_slave_skip_counter=1;

mysql_slave> SLAVE START sql_thread;


… Slave_IO_Running: Yes Slave_SQL_Running: Yes

… Last_Errno: 0

Last_Error:

DANGER Ignorer les erreurs peut provoquer des incohérences

sql_slave_skip_counter permet d’ignorer des requêtes du journal binaire. La valeur usuelle àindiquer est 1. Il est possible de devoir exécuter plusieurs fois cette commande pour ignorer plusieursévénements. Dans certains cas, une valeur supérieure à 1 est requise. Vous trouverez plus d’informationsdans la documentation de MySQL.B http://dev.mysql.com/doc/refman/5.1/en/set-global-sql-slave-skip-counter.htmlUne alternative est de fixer slave-skip-errors=all. Dans ce cas, io_thread continuera en cas d’erreurs.Cela est dangereux car le risque de trouver l’esclave dans un état incohérent est très grand. Il est égale-ment possible d’ignorer seulement un type d’erreur. Il suffit pour cela de remplacer le mot clé all par lecode MySQL de l’erreur à ignorer. Cette technique est tout aussi déconseillée, les risques étant les mêmesque ceux exposés précédemment.



Autres types de problèmes, ceux liés à une corruption des journaux binaires ou relais.Ces problèmes peuvent survenir après un arrêt brutal ou être la conséquence d’unbogue (situation rencontrée sur d’anciennes versions, lors d’une charge importante detransactions dans le journal binaire). Vous pouvez essayer de limiter les risques en con-figurant le maître avec les valeurs sync_binlog et innodb_flush_log_at_trx_commità 1. L’activation de ces deux paramètres peut avoir impact non négligeable sur lesperformances ; effectuez des tests avant de les changer. Comme souvent, il vous faudratrouver le bon compromis en testant. Dans ce cas, réinitialiser la réplication est plussimple que d’essayer de réparer en rejouant les bonnes requêtes et en ignorant les mau-vaises avec sql_slave_skip_counter.

Les journaux binaires ne sont pas purgés automatiquement par défaut (consultez lechapitre 5 traitant des journaux). Vous devez donc utiliser une procédure de sur-veillance de l’espace disque ainsi qu’une procédure de suppression de ces journaux.Dans le cas contraire, si le serveur se retrouve en manque d’espace disque, la base serafigée, en attente d’une libération future de place sur le disque et une erreur sera notéedans le journal des erreurs. En théorie, une fois que MySQL s’aperçoit qu’il y a denouveau de la place, la réplication repart comme si rien ne s’était passé. En pratiquele risque est grand de devoir réinitialiser la réplication.

En cas d’erreur Disk is full writing, MySQL vérifie toutes les minutes si del’espace disque à été libéré et inscrit, si ce n’est pas le cas, toutes les dix minutes, unmessage d’erreur dans le journal des erreurs.

shell> tail mysql-error.err090723 2:32:55 [ERROR] /usr/local/libexec/mysqld: Disk is full writing ’/usr/local/mysql/log/mysql-bin.000095’ (Errcode: 28). Waiting for someone to free space... Retry in 60 secs090723 2:33:26 [ERROR] Error writing file ’/usr/local/mysql/log/mysql-slow.log’ (errno: 1)090723 2:42:55 [ERROR] /usr/local/libexec/mysqld: Disk is full writing ’/usr/local/mysql/log/mysql-bin.000095’ (Errcode: 28). Waiting for someone to free space... Retry in 60 secs

BON À SAVOIR Tables temporaires et réplication

La création de tables temporaires (CREATE TEMPORARY TABLE) n’est pas recommandée pour laréplication. En effet, leur durée de vie étant la session, en cas de redémarrage de l’esclave, la table exis-tera encore sur le maître, mais plus sur l’esclave.D’autres problèmes potentiels connus sont répertoriés dans la documentation de MySQL : B http://dev.mysql.com/doc/refman/5.1/en/replication-features.html



237

Architectures de réplication avancéesUne des forces de la réplication est sa grande modularité. Pour répondre à desbesoins aussi variés que la répartition de la charge, la haute disponibilité et biend’autres, vous devrez aller au-delà de la simple architecture « un maître, un esclave ».Nous allons vous présenter quelques topologies de réplications parmi les plus utili-sées. Bien entendu, cette liste est loin d’être exhaustive, mais elle vous donnera unaperçu de l’étendue des possibilités et, nous l’espérons, des idées pour implémenter laréplication à votre convenance. Attention toutefois, plus votre architecture est com-plexe, plus son entretien et la résolution des problèmes risquent d’être coûteux.

Dual master en actif/passif

REMARQUE MySQL Cluster

MySQL Cluster est la solution haute disponibilité de MySQL et de partage de la charge pour les requêtesde lectures et d’écritures. Ses principaux avantages sont :• moteur transactionnel ;• Failover automatique et rapide ;• différentes tâches de maintenance online (sauvegarde, ajout de nœuds, changement de structure…) ;• synchronisation automatique des nœuds sur leur réplique ;• pas de Single Point Of Failure (SPOF) ;• architecture shared nothing (chaque nœud du cluster peut avoir ses propres ressources matérielles) ;• cluster à faible coût.Elle présente les inconvénients suivants : • relativement complexe à mettre en place ;• utilisation de moteur NDB qui a certaines limitations (pas d’index Fulltext, pas de clés étrangères…) ;• nécessité d’adapter l’application à l’architecture MySQL Cluster ;• pas adapté aux requêtes complexes (jointures sur plus de 3 tables, sous-requêtes…) ;• pas adapté aux gros volumes de données (les index doivent se trouver entièrement en mémoire).

Figure 8–3Réplication circulaire actif/passif



Les objectifs de cette architecture sont :• haute disponibilité ;• sauvegarde à chaud ;• partage de la charge des requêtes de lecture.

Le principe de la réplication dual master est d’utiliser deux serveurs qui se répliquentmutuellement et forment une boucle logique. Le fonctionnement est le même que laréplication simple : on a donc bien un serveur maître et un serveur esclave qui répli-quent leurs données, du maître vers l’esclave. La nuance vient du fait que l’esclave estégalement maître du premier serveur. En conséquence, les données peuvent égale-ment être répliquées dans l’autre sens. Cependant, il n’y a pas de risque qu’unerequête répliquée boucle indéfiniment d’un serveur à l’autre, car chaque requête (outransaction) est préfixée par l’identifiant du serveur (server_id) du maître et ne peutdonc pas être répliquée à nouveau sur ce dernier.

Cette architecture peut être implémentée en mode actif/passif ou en mode actif/actif.Nous évoquerons dans ce chapitre le premier mode ; le second sera détaillé au cha-pitre suivant.

Tout d’abord, les notions d’actif et passif sont à considérer du point de vue de l’applica-tion. L’instance MySQL active est connue et vue par l’application alors que la passive,elle, ne l’est pas. Toutefois, dans ce cas, les deux instances de MySQL fonctionnent.

La topologie dual master s’adapte bien aux applications qui ont été conçues pour com-muniquer avec une seule instance de MySQL parce qu’il s’agit d’une configuration avecune seule base de données (n clients et 1 serveur MySQL). En d’autres termes, l’appli-cation ne connaît qu’une machine à la fois. Les besoins de retoucher le code sont icitrès faibles. La deuxième machine, la passive, joue le rôle de spare, c’est-à-dire qu’elleprend le relais au cas où la première machine ne serait plus accessible : on obtient doncune architecture de haute disponibilité. Autre avantage, la deuxième machine peut éga-lement servir à récupérer une partie de la charge des requêtes des lectures de l’applica-tion. Dans ce cas, ce n’est plus strictement une configuration actif/passif, et cela aug-mente la complexité du code. Enfin, cette machine peut également tenir le rôle deserveur de sauvegardes, ce qui permet d’effectuer des sauvegardes à chaud. Bien évide-ment, en cas de besoin, rien n’empêche de rajouter des esclaves.

DANGER Une réplique n’est pas une sauvegarde

Ne compter que sur la réplication pour mener des sauvegardes est très risqué. En effet, comme exposéau début de ce chapitre, une requête d’écriture malheureuse sur le maître sera répliquée sur les esclaves.De plus, la réplication ne contient aucun mécanisme qui permette de s’assurer que toutes les répliquescontiennent exactement les mêmes données.



239

ConfigurationLe plus simple est d’utiliser deux machines quasi identiques, c’est-a-dire de mêmejournal binaire, même utilisateur de réplication et même mot de passe. Le paramètrelog_slave_updates peut être activé. Ce dernier a pour inconvénient de produire unesurcharge sur le serveur car il va journaliser les requêtes répliquées. En revanche, ilapporte une sécurité supplémentaire pour les données en gardant une copie des jour-naux binaires du serveur actif sur le serveur passif. Cette copie est utile pour réaliserdu PITR ou des sauvegardes incrémentales (consulter le chapitre 5 sur la journalisa-tion) sans impact sur l’applicatif. N’oubliez pas le paramètre skip_slave_start.

Nous vous conseillons d’activer le mode lecture seule (read-only) sur le serveurpassif. Ce changement peut s’effectuer dynamiquement avec SET GLOBAL read_only=’ON’.

Disposer de deux machines de configuration si proche offre un autre avantage : lorsdu passage sur le deuxième serveur, il n’est pas nécessaire de repasser sur le premier(failback) une fois que ce dernier est à nouveau disponible.

L’identifiant des serveurs (server-id) doit évidemment être unique sur chacun desnœuds.

Exemple : switchover pour une mise à jour online des serveurs MySQLSoit A le serveur actif et B le passif.1 Sur B, arrêtez le thread io_thread (STOP SLAVE io_thread).2 Laissez le thread sql_thread terminer la réplication. Supervisez avec SHOW SLAVE

STATUS, puis arrêtez sql_thread : STOP SLAVE sql_thread.3 Arrêtez le serveur B (c’est la phase la plus délicate car si A tombe le service n’est

plus assuré).4 Récupérez les valeurs de Master_Log_File et Exec_Master_Log_Pos du serveur B

avec SHOW SLAVE STATUS. Optionnel : effectuez une sauvegarde du serveur B(simple précaution, en prenant les fichiers master.info et relay-log.info).

5 Mettez à jour le serveur MySQL sur B.

OUTILS Supervision des serveurs

La réplication MySQL ne s’occupe pas de la supervision des serveurs. Vous devez utiliser un système quipermettra de détecter l’absence d’une machine ou du service MySQL, mais également d’initier le bascu-lement de l’application du serveur l’actif (qui ne répond plus) vers le serveur passif (qui devient alorsactif). Un programme comme Pacemaker (successeur d’heartbeat version 2) vous aidera à gérer cettepartie. B http://clusterlabs.org/wiki/Main_Page



6 Assurez-vous que B est toujours paramétré pour être un esclave (et également unmaître).

7 Démarrez B et vérifiez que tout s’est bien passé dans le journal des erreurs.8 Lancez la réplication avec START SLAVE et vérifiez que tout fonctionne correcte-

ment avec SHOW SLAVE STATUS (en cas de souci, reportez-vous aux informationsglanées lors de l’étape 4).

9 Interdisez les écritures sur A :– SET GLOBAL read_only=’ON’; verrouille les serveurs en lecture seule. Placez

également cette instruction dans le fichier de configuration ;– FLUSH TABLES WITH READ LOCK; au cas où un traitement (planifié) se lancerait

en root ou tout autre utilisateur avec le droit SUPER ;– SHOW MASTER STATUS; pour récupérer le numéro du journal binaire et la posi-

tion.10 Laissez le serveur B rattraper son retard au niveau de la réplication (cela peut

prendre du temps). Utilisez la fonction master_pos_wait avec comme paramètresle numéro et la position du journal binaire de A (étape 9) : SELECT

master_pos_wait(’mysql-bin.xxxxxx’,N);. La fonction rendra la main une foisl’esclave à jour.

11 Une fois B à jour, exécutez SHOW MASTER STATUS;. Les informations serviront àreconfigurer A.

12 Si B est en lecture seule, autorisez les écritures avec SET GLOBAL

read_only=’OFF’;. Mettez également à jour le fichier de configuration.13 Routez les écritures et les lectures sur B qui devient alors le serveur actif.14 Reconfigurez le serveur A pour qu’il soit esclave de B et qu’il reparte sur le bon

fichier binaire et à la bonne position : CHANGE MASTER TO MASTER_LOG_FILE =’mysql-bin.xxxxxx’, MASTER_LOG_POS = N;.

Notez que si vous ne redémarrez pas le serveur A, il est possible que vous ayez besoinde tuer les requêtes d’écritures verrouillées par la commande FLUSH TABLES WITH

READ LOCK de l’étape 9. Vous pourrez les voir avec SHOW PROCESSLIST. Relâchezensuite les verrous (UNLOCK TABLES).

Dans le même ordre d’idée, d’autres manipulations sont possibles comme un change-ment de structures des tables, une modification d’index ou une optimisation d’unetable volumineuse ou toute autre opération longue et coûteuse. Il faut les exécuter surle serveur passif et ensuite permuter.



241

RécapitulatifLes avantages de l’architecture dual master en actif/passif sont :• simplicité de mise en œuvre, pas (ou peu) de retouche sur un code existant ;• coûts faibles, ne nécessite que deux machines ;• haute disponibilité ;• partage de la charge des requêtes de lecture possible ;• possibilité de redondance géographique ;• basculement manuel (switchover) dans le but d’effectuer des tâches online (mise à

jour de versions, changement de structure, installation de patches…) ;• basculement automatique couplé à un système de gestion de la haute disponibilité

(possible).

Ses inconvénients sont :• réplication asynchrone, aucune assurance que les données sont exactement les

mêmes sur les deux instances ;• nécessité d’un système externe de gestion de la haute disponibilité ;• pas de partage de la charge possible pour les requêtes d’écritures.

Dual master en actif/actifLes objectifs de cette architecture sont :• haute disponibilité ;• partage de la charge des requêtes de lectures ;• sauvegarde à chaud possible.

Cette architecture est quasiment identique à la réplication circulaire actif/passif.L’application peut répartir ses requêtes de lectures sur les deux machines mais peuten plus y écrire et c’est là que le bât blesse. Une croyance populaire veut que cettearchitecture permette de répartir la charge des requêtes d’écritures sur les deuxmachines. Ce n’est malheureusement pas le cas car toutes les requêtes exécutées surune machine seront également exécutées sur l’autre. Il faut donc admettre que la

ALTERNATIVE Commencer par le maître

Il est parfois nécessaire de stopper le serveur actif en premier. Dans ce cas :1. Arrêtez les mises à jour sur l’actif.2. Récupérez le numéro et la position du journal binaire.3. Assurez-vous que le passif est à jour.Le passif devient actif et il peut recevoir les requêtes d’écritures.



réplication ne répond tout simplement pas aux problématiques de partages de lacharge des requêtes d’écritures !

La possibilité d’écrire sur les deux machines peut poser deux types de problèmes auniveau de :• la violation des contraintes d’unicité des valeurs ou des objets de la base de

données ;• l’ordre d’exécution des requêtes.

Examinons en premier lieu la violation des contraintes d’unicité. Il est possible queles mêmes objets (schémas, tables...) soient créés sur les deux serveurs avant qu’ils nesoient répliqués, ce qui entraîne une rupture de la réplication au moment où le threadsql_thread exécute la requête. Ce problème peut être contourné en interdisant àvotre application d’exécuter des instructions CREATE SCHEMA/DATABASE/TABLE ou descommandes DROP.

De la même manière, les tables étant présentes sur les deux serveurs, une mêmedonnée écrite dans le champ ayant une contrainte d’unicité, des deux côtés avantréplication, entraîne elle aussi l’arrêt du sql_thread. Le cas trivial est celui des clésprimaires avec une clause auto_increment. Ce problème peut également être con-tourné en réglant des pas d’incréments différents, comme expliqué ci-dessous.

Extrait des sections [mysqld] des deux serveurs

Figure 8–4Réplication circulaire actif/actif

[mysqld] # sur le serveur Aauto_increment_increment = 10auto_increment_offset = 1

[mysqld] # sur le serveur Bauto_increment_increment = 10auto_increment_offset = 2



243

Un article de Giuseppe Maxia, intitulé « Advanced MySQL Replication Techniques »(http://dev.mysql.com/tech-resources/articles/advanced-mysql-replication.html) traite du sujet.

Malheureusement, votre application n’emploiera certainement pas que des clés pri-maires auto_increment. Vous utilisez peut-être également des index de type uniqueet, dans ce cas, il n’y a pas de solution miracle. Toutefois, une possibilité est de conce-voir l’application pour qu’elle écrive une partie des données sur la machine A etl’autre partie sur la machine B. Les problèmes de violations des contraintes d’unicitédes valeurs ou des objets seront levés au prix d’une augmentation de la complexité ducode. En revanche, en cas de panne d’une des deux machines, les écritures sur lestables concernées ne pourront plus s’effectuer. Un dernier point à prendre en compteégalement, toujours en cas de panne d’une des deux machines, est qu’il faut vousassurer que le serveur qui reste soit dimensionné pour absorber la charge de lecturede deux machines (on peut également y ajouter la charge des requêtes d’écritures dela machine en panne au cas où vous l’autoriseriez).

Le problème de l’ordre d’exécution des requêtes peut être encore plus contraignant :avec la journalisation SBR, des requêtes ne s’exécutant pas dans le même ordre sur lesdeux serveurs peuvent donner des résultats différents. Par exemple, soit la table T1qui contient un n-uplet de valeur 1. Sur le serveur A, en ajoutant 5, cela donne 6.Avant que la requête de mise à jour soit répliquée, une autre requête multiplie par 2la valeur du n-uplet de T1 sur le serveur B, ce qui produit donc 2. Après réplicationde ces deux requêtes UPDATE sur B pour la première (5+2) et sur A pour la seconde(6 × 2), une simple requête de lecture sur la table T1 renvoie les valeurs 12 et 7, res-pectivement les serveurs A et B. On se retrouve donc avec deux serveurs qui n’ontplus les mêmes données !

Figure 8–5Problème de l’ordre des requêtes



Avec la journalisation RBR, les serveurs ne se retrouveront pas dans cet état incohé-rent. En prenant les valeurs de l’exemple précédent, vous obtiendrez la même valeursur les deux serveurs, c’est-à-dire soit 6, soit 2 (tout dépend de la rapidité d’exécutiondes requêtes sur chaque serveur).

RécapitulatifLes avantages de l’architecture dual master en actif/actif sont :• haute disponibilité ;• coûts faibles, ne nécessite que deux machines ;• partage de la charge des requêtes de lectures possible ;• possibilité de redondance géographique ;• basculement manuel (switchover) dans le but d’effectuer des tâches online (mise à

jour de versions, changement de structure, installation de patches…) ;• basculement automatique couplé à un système de gestion de la haute disponibilité

(possible).

Ses inconvénients sont :• problème des champs auto_increment;• problème des clés uniques ;• problème de l’ordre des requêtes, sauf en RBR ;• pas de partage de la charge possible pour les requêtes d’écritures ;• des contraintes au niveau du code de l’application ;• nécessité d’un système externe de gestion de la haute disponibilité ;• réplication asynchrone, aucune assurance que les données soient exactement les

mêmes sur les deux instances.

Réplication circulaire (nombre de réplications > 2)La réplication circulaire est une extension de l’architecture dual master : elle utilise n(n>2) serveurs qui forment une boucle logique. Les contraintes sont les mêmes maismultipliées par le nombre de nœuds.

L’intérêt de telles architectures n’est pas forcément évident sauf si les différentes con-traintes ne vous posent pas de problèmes.

Esclave relaisLes objectifs de cette architecture sont :• partage de la charge des requêtes de lectures ;



245

• Possibilité de redondance géographique.

À l’instar des connexions clientes, chaque esclave consomme de la mémoire sur lemaître. Cette surcharge vient du thread créé qui exécute la commande Binlog Dumpchargée de lire les événements du journal binaire. De plus, dans certains cas, lesesclaves peuvent également être la source d’une augmentation des I/O du maître (siune multitude d’esclaves attaquent des événements différents dans les journauxbinaires du maître).

Pour ces raisons, si vous avez besoin de beaucoup d’esclaves, vous ne pourrez peut-être pas tous les connecter au même maître sous peine de voir ses performances sedégrader. La solution consiste alors à implémenter une architecture arborescente,c’est-à-dire un maître à la racine, un pool d’esclaves dans les feuilles et, entre lesdeux, un ou plusieurs niveaux de serveurs à la fois maîtres et esclaves.

L’architecture esclave relais est une variante composée d’un maître en racine, unmaître/esclave (l’esclave relais) en niveau intermédiaire et n esclaves dans les feuilles.L’esclave relais permet d’épargner au maître la charge des esclaves. En d’autrestermes, son unique rôle est de lire les données du maître pour que les esclaves lesrécupèrent. Notez que rien ne vous empêche d’utiliser plusieurs esclaves relais.

Figure 8–6Architecture esclave relais



De façon classique, l’application va effectuer ses écritures sur le maître, quelques lec-tures également lorsque cela est nécessaire et uniquement des lectures sur les esclaves.On voit donc que pour l’application l’esclave relais n’existe pas !

Ce petit détail est d’une grande importance pour cette topologie. En effet, la réplica-tion offre beaucoup de libertés, notamment au niveau de la structure des tables ; il estpar exemple possible de stocker les tables en InnoDB sur le maître parce que vous aurezun fort besoin de cohérence (intégrité référentielle, transactions) et de les enregistrer enMyISAM sur l’esclave, tout simplement parce ce qu’elles ne seront, pour l’application,accédées qu’en lecture. Sur le maître, vous pouvez envisager de créer peu d’index pourne pas ralentir les écritures, alors que sur l’esclave, toutes les combinaisons d’index per-tinentes seront requises pour que les requêtes de lectures soient efficaces.

Le schéma n’est pas le seul bénéficiaire de cette souplesse ; le maître peut être para-métré pour sécuriser les écritures (transactions, journaux) au détriment de la perfor-mance alors que, sur les esclaves, ce sera le contraire, pour le serveur MySQL commepour le matériel.

Pour en revenir à l’esclave relais, y stocker des données ne présente donc d’intérêt nipour l’application, ni même pour les esclaves, car seuls les journaux binaires les inté-ressent. Il est donc possible d’utiliser sur l’esclave relais le moteur de stockage Black-hole (consultez le chapitre 3 sur les moteurs de stockage) qui, comme les autresmoteurs, stocke les événements dans son journal binaire mais n’enregistre pas lesdonnées ce qui permet d’économiser des I/O.

L’inconvénient est que ce type d’architecture rend tout basculement difficile du faitde la spécialisation des différents nœuds.

ConfigurationPour la configuration des serveurs composant l’architecture esclave relais, on retrouveles trois familles : le maître, l’esclave relais et les esclaves.

Pour le maître (M), la priorité est d’assurer la cohérence et la sécurité des données :• Le moteur de stockage par défaut est InnoDB.• Le serveur MySQL sera paramétré pour assurer au maximum la persistance dis-

que des données et des événements du journal binaire.• Sur le maître, des clés primaires, uniques et étrangères sont présentes.• Le stockage des données s’effectue en RAID 1+0 si possible.



247

Extrait de la section [mysqld]

Pour l’esclave relais (R), le moteur de stockage par défaut est Blackhole.

Le fichier de configuration contient entre autres :

Enfin, pour les esclaves (E), la priorité est axée sur la performance.• moteur de stockage par défaut : MyISAM ;• possibilité de rajouter des index (simple, Fulltext…) ;• stockage des données : RAID 5.


RécapitulatifLes avantages de l’architecture esclave relais sont :• partage de la charge des requêtes de lectures ;• possibilité de redondance géographique ;• optimisation personnalisée de chacun des nœuds.

Ses inconvénients sont :• coût ;• complexité ;• états d’avancement des esclaves potentiellement différents ;• pas de partage de la charge possible pour les requêtes d’écritures ;

[mysqld]default_storage_engine = InnoDBinnodb_flush_log_at_trx_commit = 1innodb_support_xa = 1sync_binlog = 1

[mysqld]default_storage_engine = Blackholesync_binlog = 1log_slave_updatesskip_slave_startread_only

[mysqld]default_storage_engine = MyISAMsync_binlog = 0delay_key_write = ONskip_slave_startread_only



• des contraintes au niveau du code de l’application ;• basculement manuel complexe ;• pas de basculement automatique ;• réplication asynchrone, aucune assurance que les données soient exactement les


Partitionnement adapté au décisionnelLes objectifs de cette architecture sont :• base de données répliquée et partitionnée (éventuellement sur différents sites) ;• partage de la charge des requêtes de lectures ;• possibilité de faire du décisionnel.

Le maître est utilisé de façon classique dans un environnement OLTP alors quel’esclave contient des données destinées à être traitées dans un environnement déci-sionnel pour une utilisation de type (pseudo) OLAP (consultez la remarque sur lamodélisation du chapitre 6 traitant de l’optimisation). Sur le maître, le schéma estdonc normalisé avec des tables en InnoDB, alors que sur l’esclave le schéma estdénormalisé en MyISAM, avec des données redondantes, dans des tables d’agréga-tions alimentées par des déclencheurs (triggers) et des procédures stockées (en plusdes tables répliquées). Pour ne pas pénaliser les requêtes de lectures sur les esclaves àcause des verrous en écriture niveau table, les données ne sont pas répliquées entemps réel, mais qu’une fois par jour, la nuit durant les heures de fermeture desbureaux. De plus seules les données de type A sont répliquées sur le site A ; mêmeprincipe pour le site B.

Figure 8–7Architecture décisionnelle partitionnée



249

ConfigurationSur le maître, la configuration est la suivante :• Le moteur de stockage par défaut est InnoDB.• Le serveur MySQL sera paramétré pour assurer au maximum la persistance dis-

que des données et des événements du journal binaire.• Des clés primaires, uniques et étrangères sont présentes.• Le stockage des données s’effectue en RAID 1+0 si possible.


Sur l’esclave :• Moteur de stockage par défaut : MyISAM.• Ajout d’index pertinents (simple, Fulltext...).• Seules les données utiles sont répliquées grâce à la directive replicate_wild_do_table.• Stockage des données : RAID 5.


Même principe pour le deuxième esclave avec replicate_wild_do_table=B.%

Pour le démarrage et l’arrêt de la réplication, utilisez START SLAVE STOP SLAVE

[io_thread|sql_thread].

Pour disposer d’une haute disponibilité, il est possible d’ajouter un serveur pourconstituer un dual master.

[mysqld]default_storage_engine = InnoDBinnodb_flush_log_at_trx_commit = 1innodb_support_xa = 1sync_binlog = 1

[mysqld]replicate_wild_do_table = A.%default_storage_engine = MyISAMsync_binlog = 0delay_key_write = ONskip_slave_startread_only



RécapitulatifLes avantages de l’architecture partitionnée sont pour le décisionnel :• partage de la charge des requêtes de lectures ;• partitionnement des données ;• possibilité de réplication sur différents sites ;• possibilité de faire du décisionnel.

Ses inconvénients sont :• pas de dimensionnement pour les requêtes d’écritures ;• des contraintes au niveau du code de l’application ;• complexité de mise en œuvre ;• réplication asynchrone, aucune assurance que les données soient exactement les


Bonnes pratiquesVoici les principaux paramètres auxquels vous devez prêter attention. La configura-tion idéale n’existant pas, validez-les sur les serveurs avant la mise en production.

Nommez de façon explicite les fichiers nécessaires à la réplication

Ne configurez pas la réplication dans le fichier de configuration. Cette façon de pro-céder est obsolète et disparaîtra dans les prochaines versions de MySQL. Utilisez lacommande CHANGE MASTER TO.

Sur le maître, on se focalise en règle générale plutôt sur la sécurité que sur la perfor-mance.

sync_binlog = 1 : écrit dans le log binaire chaque fois qu’une transaction est validée.Cela diminue le risque de perte de données en cas d’arrêt brutal mais augmente lesaccès au disque, ce qui affecte les performances.

Pour les tables MyISAM : delay_key_write = OFF (ou ON): écrit les index sur ledisque à chaque requête d’écriture à OFF.

Pour les tables InnoDB :• innodb_flush_log_at_trx_commit = 1 : écrit sur le disque chaque transaction validée ;• innodb_support_xa = 1 : synchronise le log binaire avec les données.

log_bin = mysql-binlog_bin_index = mysql-bin.indexrelay_log = mysql-relay-binrelay_log_index = mysql-relay-bin.index



251

Sur l’esclave, on se focalise souvent sur la performance plutôt que sur la sécurité :sync_binlog = 0 (ou 1).

Pour les tables MyISAM :

Pour les tables InnoDB :

• skip_slave_start : empêche la réplication de redémarrer automatiquement.• read_only : empêche les écritures sur l’esclave (sauf pour l’utilisateur root ou

celui possédant le droit SUPER).

delay_key_write = ON

innodb_flush_log_at_trx_commit = 2innodb_support_xa = 0

Figure 8–8Architecture de sharding réplication



À SAVOIR Le sharding

La réplication ne permet pas de dimensionner sa plate-forme pour pouvoir répondre à une évolution dela charge des requêtes d’écritures. Cela peut être un inconvénient majeur dans certaines architectures oùla volumétrie des données est très importante avec (ou non) une charge de requêtes également problé-matique. Si malgré les optimisations apportées à la base de données et l’ajout de systèmes de cachevous arrivez aux limites des serveurs, le sharding peut être une solution. Il consiste à découper la base dedonnées en sous-ensembles appelés shards, en général de taille équivalente, contenant chacun une par-tie des données. Ce partitionnement, niveau application, a pour but de permettre aux requêtes de bras-ser des volumes de données de moindre importance et de diminuer les temps de traitements.Le critère de partitionnement des shards est très important. C’est grâce à lui que la répartition des don-nées sera homogène et que les gains en performances seront au rendez-vous. En général c’est un identi-fiant unique comme la clé primaire.Les principales stratégies de partitionnement sont :Par intervalles :• entier : id entre 0 et 1 million, entre 1 million et 2 millions...• texte : nom entre A et C, entre D et G...Par modulo ou hachage :• id modulo nombre de shards ;• md5(id).En fonction de la charge :• nombre d’enregistrements dans la base ;• charge de la machine hôte.Les shards peuvent être répliqués sous la forme maître esclave(s) pour pouvoir profiter de tous les avan-tages de la réplication abordés dans ce chapitre. Le sharding n’est cependant pas la panacée : il peut êtrecomplexe à mettre en œuvre en imposant des contraintes au niveau du code de l’application pour pou-voir lire et écrire les données dans le bon shard. Certaines informations ne peuvent (doivent) pas êtrepartitionnées et devront être soit redondantes sur chacun des shards (avec des risques pour les perfor-mances et l’intégrité des données), soit être centralisées (risque de single point of failure (SPOF) oupoint individuel de défaillance). Les problèmes d’intégrité des données peuvent apparaître égalementlors de la validation des transactions ou pour la sauvegarde lorsqu’elle est réalisée sur un shard à la fois.Ces différents aspects sont à prendre en considération dans la réflexion à mener pour mettre en placeune architecture de sharding.


Chercher une réponse ne se résume pas à interroger un moteur de recherche dansl’urgence. Il existe en effet d’autres leviers à actionner en cas de besoin, lorsqu’uneréponse plus ou moins rapide est requise ou tout simplement pour enrichir ses con-naissances au fil de l’eau.

Fort heureusement, trouver de l’aide n’est pas qu’une question d’urgence. Une ques-tion qui ne nécessite pas forcément un délai de résolution immédiat peut tout à faittrouver sa place sur un forum, par exemple. En revanche, lorsque le temps presse,cette même question peut tout d’un coup se transformer en une véritable quête chro-nométrée sans pitié qui épuisera le sablier...

Pour éviter de perdre son temps, précieux de toute façon, nous allons vous présenternos sources d’informations préférées. Elles sont nombreuses. Retenez celles qui vouscorrespondent le mieux, selon votre expérience avec MySQL ou votre affinité avecl’anglais. En effet, si la communauté francophone est de plus en plus présente sur latoile, la plupart des contenus pointus sont toujours en anglais. Il ne tient qu’à vous derejoindre nos efforts et diffuser à votre tour de l’information en français sur Internet.LeMug.fr, l’association française des utilisateurs de MySQL, fait partie de ces initia-tives susceptibles de vous intéresser.

Selon le degré d’urgence requis, les voies à emprunter sont différentes, voici notresélection, à parcourir selon le temps dont vous disposez.

9Où trouver de l’aide ?



Trouver de l’aide en urgence

Les ressources internesSi vous êtes le seul dans votre entreprise à manipuler les bases de données MySQLou à détenir les connaissances nécessaires à leur fonctionnement, passez au para-graphe suivant... Cependant, il existe peut-être dans votre service ou ailleursquelqu’un susceptible de vous aider. En effet, selon la taille et l’organisation de votresociété, il est possible qu’une cellule « bases de données » (pas forcément dédiée àMySQL) soit en place ; le tout est de le savoir, ou de la joindre. Difficile par exempled’obtenir une réponse immédiate si ce groupe de personnes se trouve dans un autrepays... Décalage horaire, disponibilité, autant d’obstacles synonymes de délai supplé-mentaire pour obtenir la réponse que vous cherchez.

Prenez les devants et demandez autour de vous si une telle cellule serait un jour sus-ceptible de vous aider en pareille situation.

Les ressources externesNous ne détaillerons pas les nombreuses formules offertes par chaque organisme pro-posant des solutions de support, de conseil, ou de formation autour de MySQL ;cependant, les points d’entrée vers celles-ci seront indiqués.

Les moteurs de rechercheImbattable au niveau prix, il va de soi que le moteur de recherche est évidemment unpoint d’entrée incontournable à tester avant toute chose. Soumettre le numéro del’erreur rencontrée, saisir le message d’erreur entouré de guillemets, font partie desgestes à tenter. Blogs, site de MySQL lui-même, interface de gestion des bugs(MySQL toujours), etc., les points de chute sont nombreux... Et anglophones la plu-part du temps. Aussi, n’hésitez pas à formuler votre question en anglais si la versionfrançaise de celle-ci échoue.

Pensez également à utiliser les moteurs de recherche propres à un blog ou à celui d’unsite Internet tel que http://www.mysql.com ou http://planet.mysql.com/ sans oublier sa décli-naison française bien sûr : http://fr.planet.mysql.com/.

Le support officiel MySQLL’étendue de la gamme proposée par MySQL est très vaste. En ce qui concernel’urgence, l’offre de support (http://www.mysql.com/support/) est celle qui convient à notre


Où trouver de l’aide ?CHAPITRE 9

255

catégorie. Il s’agit ici d’obtenir le plus rapidement possible un ingénieur supportcapable de diagnostiquer le problème et de le résoudre. Les possibilités offertes parcette formule sont disponibles sur le site. Certaines options vous permettent de dis-poser d’un support annuel doté d’un temps de réponse garanti et d’un nombre illi-mité de questions dont vous définissez le caractère d’urgence.

Nous avons personnellement eu l’occasion de tester avec satisfaction le support à dis-tance ainsi que le conseil sur site de MySQL.

Les organismes externesPlusieurs compagnies privées proposent elles aussi du support MySQL. Les plusconnues sont celles déjà citées dans cet ouvrage. En voici quelques-unes :• http://www.percona.com

• http://www.pythiangroup.com

• http://www.openquery.com

• http://www.provenscaling.com

À vous de faire le tri parmi les tarifs et les formules qui vous sont proposés afin detrouver celle qui convient à vos besoins. Peut-être avez-vous déjà un administrateurMySQL en interne ? Inutile donc d’en louer un à distance ; en revanche souscrire à uneformule de support en cas de coup dur ou d’absence de votre DBA peut s’avérer utile.

Ces sociétés de conseil proposent en général un numéro d’urgence bien visible surleur page d’accueil. Le support s’effectuera principalement (pour ne pas dire exclusi-vement) en anglais.

Alternative française à la langue de Shakespeare, Capdata (http://www.capdata.fr) disposede compétences en interne dédiées à MySQL. Il existe également d’autres SSII pro-posant des offres tournées vers MySQL. La plupart des grands groupes semblentposséder des compétences MySQL en interne. Attention toutefois à ces sociétésgénéralistes : les compétences purement MySQL y sont relativement rares maisplutôt orientées Oracle ou SQL Server.

Nous vous conseillons, lorsque cela est possible, de rencontrer les consultants suscep-tibles d’être vos futurs interlocuteurs en cas d’urgence. Mieux vaut être pointilleuxpendant les entretiens afin d’éviter les mauvaises surprises le jour où l’urgence son-nera à votre porte. Cela est d’autant plus vrai que du fait de leur rareté aujourd’hui,les compétences MySQL reposent parfois sur un tout petit nombre decollaborateurs ; il suffit parfois qu’un seul bon élément quitte le navire pour que leniveau général s’en ressente.



Trouver de l’aide hors contexte d’urgenceOffres de surveillance à distance, possibilité de débogage ou d’installation de versionsle tout par un administrateur de bases de données loué pour l’occasion, tout cela estpossible. Les organismes susceptibles d’offrir ce type de services sont les mêmes queceux offrant du dépannage d’urgence.

MySQL, là encore, dispose d’une offre de conseil très riche, http://www.mysql.com/consulting/, et il est possible de réserver un consultant sur site quelques jours le tempsd’un audit, d’une séance d’optimisation ou d’une opération de maintenance délicateque vous ne souhaitez pas effectuer en interne.

Il n’est pas toujours nécessaire d’avoir un consultant sur place : c’est pourquoi lesoffres à distance concernant ce type de service ont un sens. Là encore, outre MySQL,comparez les différentes formules des sociétés citées précédemment (Percona,Pythian Group, Open Query, Capdata...), elles proposent toutes ce genre de services.

FormationsNous ne l’avons pas encore évoqué jusqu’à maintenant mais il est également possiblede se former à MySQL par le biais de formations, qu’elles soient organisées parMySQL ou non. Si la maison mère possède bien évidemment une offre dédiée, http://www.mysql.com/training/, c’est également le cas d’organismes externes comme Alter WayFormation (http://www.anaska.com/formation-mysql.php) qui disposent de différents cursusofficiels et en français. D’autres organismes ne devraient pas manquer d’apparaîtresous les termes Formations MySQL sur un moteur de recherche...

Où poser votre question ?Une question, même démunie de tout caractère d’urgence, mérite une réponse.Lorsque le temps n’est plus (vraiment) le critère numéro un de votre recherche, il estpossible de choisir d’autres voies que celles évoquées précédemment. Nous partonsdu principe que vous n’avez pas trouvé de réponse suffisamment précise auprès d’unmoteur de recherche.

L’association LeMugNous avons fondé LeMug.fr, le MySQL User Group France (http://www.lemug.fr) afinque tous les utilisateurs francophones de MySQL se retrouvent et puissent échangerleurs questions et retours d’expérience dans un même lieu.

Nous sommes tous susceptibles d’apporter une réponse à quelqu’un ou de poser unequestion à l’ensemble de la liste. N’hésitez pas à nous rejoindre, cette liste constitue un



257

moyen rapide et fiable d’obtenir de l’information précise, en français bien sûr. Le forumdu site est gratuit ; cependant l’accès à la liste de diffusion nécessite une inscription.

L’adhésion annuelle est fixée à ce jour à 20 euros, cotisation utilisée pour le fonction-nement de l’association et l’organisation d’événements.

Les blogsNous détaillons nos blogs préférés dans la section « Aller plus loin et enrichir sesconnaissances ». Cependant, si votre question est assez proche d’un thème évoquépar un auteur d’un de ces blogs, pourquoi ne pas publier votre question par le biaisd’un commentaire ? À condition que celle-ci soit relative au billet principal, l’auteurde l’article ou un autre lecteur est susceptible de vous venir en aide.

Les forums et mailing-lists MySQL officielsLe site officiel de MySQL héberge plusieurs forums consacrés à différents thèmes.Moteurs de stockage, réplication, performance, outils, etc., les sujets sont nombreux.Attention au temps de réponse cependant ; les thèmes les plus populaires ne sont pas tropmal lotis, mais pour peu que vous vous intéressiez à quelque chose de plus exotique...

Autre aspect à prendre en compte sur les forums en général : n’importe qui est sus-ceptible de vous répondre. Les forums de MySQL ne sont pas les plus mal fré-quentés, bien sûr, mais si votre question se trouve dans un forum peu fréquenté, lepoids de chaque réponse a d’autant plus d’importance. Veillez donc à ne pas toutprendre pour argent comptant.

L’adresse de la mailing-list est : http://lists.mysql.com/.

Aller plus loin et enrichir ses connaissancesParcourir rapidement les dernières mises à jour des blogs MySQL de sa sélectiondevrait faire partie des tâches quotidiennes de l’administrateur de bases de données.

Cette technique est le meilleur moyen de rester informé de l’actualité générale deMySQL mais également d’aborder des points très techniques selon les blogs par-courus. Voici notre sélection des meilleurs sites ou blogs pour continuer à apprendrejour après jour.



La blogosphère de la communautéPoint d’entrée incontournable de la communauté MySQL, le site http://planet.mysql.com.Il référence les auteurs de blogs MySQL selon leur langue. La déclinaison françaisede ce portail, http://fr.planet.mysql.com/, est à porter au crédit d’un des auteurs de cetouvrage, Pascal Borghino, par ailleurs également président de l’association LeMug.

Si vous ne devez retenir qu’une adresse de notre sélection, retenez celle de http://planet.mysql.com. Les plus grands experts de MySQL y sont référencés aux côtésd’autres administrateurs partageant leurs expériences autour de MySQL. Si vousavez du contenu intéressant à partager, inscrivez-vous sur le portail.

Voici notre sélection concernant ce portail.

Tableau 9–1 Sélection française sur planet fr

Auteur(s) Adresse

Pascal Borghino – Yahoo!Arnaud Gadal – Virgin MobileStéphane Combaudon – Orange

http://www.dbnewz.com

Olivier Dasini - Orange Business Services http://dasini.net/blog/

Christophe « hello » Villeneuve - Alterway http://www.nexen.net/

Tableau 9–2 Sélection anglophone sur planet us

Auteurs Adresse

Mark Callaghan – Facebook http://mysqlha.blogspot.com/

Peter Zaitsev (et son équipe) – Percona http://www.mysqlperformanceblog.com/

Baron Schwartz – Percona http://www.xaprb.com/blog/

Lenz Grimmer – Sun/MySQL http://www.lenzg.net/

Domas Mituzas – Facebook http://mituzas.lt/

Brian Aker – Sun/MySQL http://krow.livejournal.com/

Giuseppe Maxia – Sun/MySQL http://datacharmer.blogspot.com/

Sheeri K. Cabral – Pythian Group http://www.pythian.com/news/author/sheeri

Ronald Bradford http://ronaldbradford.com/blog/

Shlomi Noach http://code.openark.org/blog/

Dathan Pattishall http://mysqldba.blogspot.com/

Michael « Monty » Widenius – Monty AB http://monty-says.blogspot.com/

Jay Pipes – Sun/MySQL http://jpipes.com/

Roland Bouman http://rpbouman.blogspot.com/

Jeremy Cole http://jcole.us/blog/

Eric Bergen http://ebergen.net/wordpress/



259

Les séminaires webLes webinars sont de courts exposés (une heure environ, et parfois en français !) con-sacrés à l’étude ou à la présentation d’un thème spécifique. Alliant image et son, cetteformule est plus vivante qu’un simple document et permet d’être consultée àn’importe quel moment (http://www.mysql.com/news-and-events/on-demand-webinars/).

Outils et sources de MySQLLe site http://forge.mysql.com/ tente de centraliser les initiatives, outils et scripts autour deMySQL. Avant de réinventer la roue, prenez le temps de le consulter.

À noter que Percona propose ses adaptations et outils à l’adresse suivante https://launchpad.net/percona-innodb. Il s’agit des patches, de l’outil de backup Percona-XtraBackupet de leur propre moteur de recherche basé sur le plug-in InnoDB : Percona-XtraDB.

En ce qui concerne les sources de MySQL ou les dernières versions, vous allez devoirutiliser Bazaar. Vous trouverez les instructions sur http://forge.mysql.com/wiki/MySQL_Bazaar_Howto. Les sources sont également disponibles sur le site de MySQL ;cependant ce sont uniquement les sources des versions courantes.

La conférence MySQLGrande messe annuelle de MySQL, celle-ci se joue depuis quelques années en Cali-fornie, à Santa Clara. Épicentre de toute l’actualité MySQL pour quelques jours,c’est le lieu à fréquenter si vous êtes disponible (et motivé !) au mois d’avril.

Le programme se trouve sur le site consacré à la conférence, http://www.mysqlconf.com.

Outre le programme, ce site a une fonctionnalité essentielle pour nous tous : ilarchive le contenu de la plupart des présentations de la conférence précédente. Lecontenu disponible est donc une mine d’or à exploiter à l’adresse suivante (exemplepour la conférence 2009) : http://www.mysqlconf.com/mysql2009/public/schedule/proceedings.

À ne manquer sous aucun prétexte...

Il existe en Europe une conférence similaire, bien que très allégée en termes de con-tenu, qui n’a pas lieu tous les ans. La dernière date de 2008.

Un des objectifs de l’association LeMug est d’organiser une grande conférenceannuelle autour de MySQL.

On trouve cependant des sessions MySQL lors des réunions AFUP (Associationfrançaise des utilisateurs de PHP) avec notamment la venue de Monty Wideniusrécemment (novembre 2009) pour l’occasion.



Les certificationsOpportunité d’en apprendre davantage, obligation professionnelle pour d’autres, lescertifications divisent en général. Inutiles ou au contraire accélérateurs de carrière, lesavis sont très partagés. Si ce domaine vous intéresse, ce billet sur l’un de nos blogsrelate le passage des certifications développeurs, DBA et Cluster : B http://www.dbnewz.com/2008/06/13/


IndexAAborted_clients, variable 99, 198Aborted_connects, variable 99, 198ACID (atomicité, cohérence, isolation,

durabilité) 59, 60, 204agrégation 166ALL, type explain 183ALTER TABLE, commande 13, 66, 68ANALYZE TABLE, commande 15, 66, 182ARCHIVE, moteur 72avg_row_length, variable 68

BB+tree, index 175BBU (Battery Backed Unit) 42BBWC (Battery-Back Write Cache) 19, 38, 42benchmark 25, 131bind-adress, variable 6binlog 4binlog_format

MIXED 157ROW 157STATEMENT 157variable 157

binlog-ignore-db, variable 224, 227Blackhole, moteur 73BLOB Streaming Engine (MyBS), moteur 76BLOB, type 67, 196blog, aide 257blogosphère, aide 258Bonnie++, outil 132B-tree, index 58, 72, 173

Ccapacity planning 136cat, Unix 16, 120

certification, aide 260CHANGE MASTER TO, commande 226char, type 67, 167CHECK TABLE, commande 15clé

étrangère 58, 106primaire 146

cœur 25cohérence 118Com_select, variable 92commande

ALTER TABLE 13ANALYZE TABLE 15CHECK TABLE 15DROP 13EXPLAIN 11GRANT 9OPTIMIZE TABLE 15REPAIR TABLE 4ROLLBACK 13SET 12SHOW FULL PROCESSLIST 4

COMMIT, commande 40, 57, 61, 115concurrent_insert, variable 206conférence, aide 259Connections, variable 197CONST, type explain 184contrainte 58crash recovery 147CREATE TABLE, commande 38Created_tmp_disk_tables, variable 90, 196Created_tmp_files, variable 195Created_tmp_tables, variable 90, 196, 201CROSS JOIN, jointure 172CSV (Comma Separated Value), moteur 74



Ddata_free, variable 69datawarehouse 77DDL (Data Definition Language) 54, 101deadlock 104, 107delay_key_write, variable 65, 250DELETE, commande 152df -kh, Unix 3, 122DISABLE KEYS, commande 192disk seek 115dmesg, Unix 121DML (Data Manipulation Language) 101droits des utilisateurs 203DROP, commande 13dtrace, Unix 127dual master 237

actif/actif 241actif/passif 237

duplicate entry 147

EENABLE KEYS, commande 192EQ_REF, type explain 184esclave (slave) 225event scheduler 147Example, moteur 73Exec_Master_Log_Pos, variable 230expire_logs_days, variable 156EXPLAIN, commande 11, 151, 177, 182, 212

FFalcon, moteur 60, 73Federated, moteur 73fichier

MYD 4MYI 4

file, privilège 204filefrag, Unix 127fincore, Unix 127FLUSH HOSTS, commande 99FLUSH LOGS, commande 142FLUSH QUERY CACHE, commande 210FLUSH TABLES WITH READ LOCK,

commande 119, 223

FLUSH TABLES, commande 210FORCE INDEX, commande 186FOREIGN_KEY_CHECKS, commande 192formation, aide 256forum, aide 257fsync, Unix 40, 43Fulltext, index 58, 67, 174

Ggeneral_log_file, variable 148GIS, index 67, 180GRANT, commande 8, 9, 203, 222GROUP BY, commande 195

HHandler_read_first, variable 199Handler_read_key, variable 199Handler_read_next, variable 199hash join, algorithme 172hash, index 58, 72, 177HEAP, moteur 71hints 104htop, Unix 3

IIBMDB2I, moteur 74IGNORE INDEX, commande 186index 58, 172

couvrant (covering) 190préfixe 190

INDEX, type explain 184INDEX_MERGE, type explain 184information_schema 21, 50, 113INNER JOIN, jointure 170InnoDB

ib_logfile, fichier 63ibdata, fichier 62iblog, fichier 62idb, fichier 62moteur 7, 19, 25, 49, 58, 60, 82, 143, 176, 204undo log, fichier 62

innodb_additional_mem_pool_size, variable 205innodb_buffer_pool_pages_free, variable 97innodb_buffer_pool_read_requests, variable 98,

112


Index 263

innodb_buffer_pool_reads, variable 98, 112innodb_buffer_pool_size, variable 31, 46, 82innodb_buffer_size, variable 145innodb_data_file_path, variable 143innodb_file_per_table, variable 62innodb_flush_log_at_trx_commit, variable 40,

205, 236innodb_flush_method, variable 43, 205innodb_log_buffer_size, variable 204innodb_log_file_size, variable 143, 204innodb_log_files_in_group, variable 204innodb_support_xa, variable 250innodb_thread_concurrency, variable 29, 106,

113innotop, outil 83, 131INSERT DELAYED, commande 95INSERT, commande 95insert_method, variable 70INSTALL PLUGIN, commande 53iostat, Unix 3, 16, 83, 124

Jjoin_buffer_size, variable 196jointure 169journal 141

binaire (binlog) 141, 155erreur 141général 141, 153requête lente (slowlog) 141, 148

Kkey_buffer_size, variable 24, 31, 46, 84, 93, 145,

205key_read_request, variable 93key_read_requests, variable 85key_reads, variable 85, 93Kickfire, moteur 77

LLast_Error, variable 230LEFT OUTER JOIN, jointure 170LeMug.fr, aide 253LOAD DATA INFILE, commande 192log binaire 4log_buffer, variable 40

log_output, variable 152log_queries_not_using_indexes, variable 149log_slave_updates, variable 227log-bin, variable 222log-slow-admin-statements, variable 149long_query_time, variable 10, 149lshw, outil 121LVM (Logical Volume Management) 117lvs, Unix 122

MMaatkit, outil 83, 131, 186mailing-list, aide 257Maria, moteur 75MASTER_HOST, variable 225MASTER_LOG_FILE, variable 225, 230MASTER_LOG_POS, variable 225MASTER_PASSWORD, variable 225MASTER_PORT, variable 225MASTER_USER, variable 225max_connections, variable 23, 88max_heap_table_size, variable 46, 72, 90, 196,

207max_rows, variable 68MCD (modèle conceptuel de données) 164Mdbtools, moteur 76megacli, Unix 123memcached 9MEMORY, moteur 46, 71, 207merge join, algorithme 172MERGE, moteur 69métadonnées 56min_examined_row_limit, variable 149MLD (modèle logique de données) 164moteur 49

InnoDB 7MyISAM 7

moteurs de recherche, aide 254mount, Unix 122MPD (modèle physique de données) 164mpstat, Unix 124mutex 106MVCC (Multi Version Concurrency

Control) 60, 75, 109, 209



my.cnf 15, 23, 46, 82MyISAM

frm, fichier 64myd, fichier 4, 64myi, fichier 4, 64

MyISAM, moteur 7, 49, 63, 69, 92, 148, 174, 205myisam_recover, option 147myisamchk, outil 65, 66, 84myisampack, outil 68mysql 84MySQL Administrator, outil 96mysql_slow_log_filter, outil 151mysql_slow_log_parser, outil 151mysqladmin, outil 82, 84mysqlcheck, outil 15, 65mysqld 95mysqld_safe 143mysqldump, outil 225mysqldumpslow, outil 10, 150mysqlhotcopy, outil 65, 118mysqlimport, outil 192mysqlreport, outil 83, 96, 130mysqlsla, outil 10, 151mysqlslap, outil 189MySQLTuner, outil 127mytop, outil 83, 131

NNDB, moteur 74nested loop, algorithme 172netstat, Unix 124null 167NUMA, architecture 25

OO_DIRECT 43OLAP (Online Analytical Processing) 28, 33,

167OLTP (Online Transaction Processing) 28, 33,

167open_files, variable 87open_table_definitions, variable 197open_tables, variable 87, 197opened_table_definitions, variable 197

opened_tables, variable 87, 197oprofile, Unix 127optimiseur 167, 181

cost based 182rule based 182

OPTIMIZE TABLE, commande 15, 65option USE_FRM 4ORDER BY, commande 195, 199organisme externe, aide 255outil 15

mysqldumpslow 10mysqlsla 10

Ppartition

HASH 212, 214KEY 212, 214LIST 212, 214RANGE 212, 213

partitionnement 211PARTITIONS, variable 212PBXT, moteur 19, 60, 75PITR (Point In Time Recovery) 160, 239PROCEDURE ANALYSE, commande 21, 168produit cartésien, jointure 171PURGE BINARY LOGS, commande 156pvs, Unix 122

QQcache_free_blocks, variable 210Qcache_free_memory, variable 92, 210Qcache_hits, variable 92, 210Qcache_inserts, variable 210Qcache_lowmem_prunes, variable 92, 210Qcache_not_cached, variable 210Qcache_queries_in_cache, variable 92, 210Qcache_total_blocks, variable 210query cache 9, 207query_cache_size, variable 92, 210query_cache_type, variable 210

RRAID 34, 36

ReadAheadNone 123write-back 123


Index 265

write-through 123random 33RANGE, type explain 184READ LOCK, commande 66read_buffer_size, variable 195Read_Master_Log_Pos, variable 230read_only, variable 226read_rnd_buffer_size, variable 195REF, type explain 184REF_OR_NULL, type explain 184Relay_Master_Log_File, variable 230REPAIR TABLE, commande 4, 65replicate-do-db, variable 227réplication 146, 217

asynchrone 218basculement automatique 220binlog 4circulaire 244décisionnel 220dimensionnement horizontal 219I/O 146master 146master.info, fichier 221master-slave 219partition 248redondance géographique 220relais 244relay-log.info, fichier 221row based 12sauvegarde à chaud 219semi-synchronous 218slave 146SQL, 146statement based 12

REPLICATION SLAVE, commande 221RESET MASTER, commande 156RESET QUERY CACHE, commande 92, 210RESET SLAVE, commande 228Rethinkdb, moteur 78RIGHT OUTER JOIN, jointure 171ROLLBACK, commande 13, 57, 61, 115row based 12row_format, variable 69

Sscaling 22SELECT, commande 95, 151select_full_join, variable 96sémaphore 105séminaire web, aide 259sequential 33server-id, variable 222SET GLOBAL, commande 150, 152SET, commande 12SGBDR 164sharding 252SHOW BINARY LOGS, commande 156SHOW BINLOG EVENTS IN,

commande 157SHOW CREATE TABLE, commande 56SHOW ENGINE INNODB STATUS,

commande 104SHOW ENGINES, commande 51SHOW FULL PROCESSLIST, commande 4,

16, 21SHOW GLOBAL STATUS, commande 16, 82,

85SHOW GLOBAL VARIABLES,

commande 82, 85, 142SHOW GRANTS, commande 99, 223SHOW INNODB STATUS, commande 16, 83SHOW MASTER STATUS, commande 156,

223, 229SHOW PLUGINS, commande 54SHOW PROCESSLIST, commande 232SHOW SESSION STATUS, commande 182SHOW SLAVE HOSTS, commande 232SHOW SLAVE STATUS, commande 100, 229,

231SHOW TABLE STATUS, commande 56, 68SHOW TABLES, commande 224SHOW VARIABLES, commande 53skip-name-resolve, variable 8, 204skip-networking, variable 6skip-slave-start, variable 226slave_compressed_protocol, variable 226Slave_IO_Running, variable 230Slave_IO_State, variable 230



Slave_SQL_Running, variable 230slave-skip-errors (variable) 12slow_queries, variable 91slow_query_log, variable 148SMP, architecture 25sort_buffer_size, variable 23, 84, 95, 195sort_merge_passes, variable 95, 195sort_rows, variable 201sort_scan, variable 201Spider, moteur 77SQL_CACHE, commande 210sql_log_bin, variable 156sql_slave_skip_counter, variable 12, 235, 236SSD (Solid State Drive) 44, 78START SLAVE, commande 226statement based 12STOP SLAVE, commande 228STRAIGHT_JOIN, jointure 172super, privilège 5, 203, 226support officiel MySQL, aide 254surindexation 177sync_binlog, variable 15, 40, 155, 236synchronous 40sysbench, outil 133SYSTEM, type explain 184

Ttable_cache, variable 46table_definition_cache, variable 196Table_locks_immediate, variable 198Table_locks_waited, variable 97, 198table_open_cache, variable 88text, type 67, 196thread 23, 27, 46, 106thread_cache_size, variable 89, 197threads_cached, variable 197threads_connected, variable 88, 197threads_created, variable 197threads_running, variable 197tinyint, type 167tmp_table_size, variable 46, 72, 90, 196TokuDB, moteur 77

top, Unix 3, 16, 83, 124transaction 58transactionel 118TRUNCATE, commande 71

Uuname, Unix 120UNINSTALL PLUGIN, commande 54UNIQUE_CHECKS, commande 192UNLOCK TABLES, commande 223UPDATE, commande 27, 152uptime, Unix 124uptime, variable 87usage, privilège 99USE INDEX, commande 186USE, commande 68, 224use_frm (option) 4using filesort, extra explain 184using join buffer, extra explain 184using temporary, extra explain 185utf-8 168

Vvarbinary, type 67varchar, type 67variable

bind-adress 6bind-adress=127.0.0.1 6long_query_time 10skip-name-resiolve 8skip-networking 6slave-skip-errors 12sql_slave_skip_counter 12sync_binlog 15

vgs, Unix 122vmstat, Unix 16, 83, 124

WWRITE LOCK, commande 66

XXtraDB, moteur 72


Documents

Audit Et Optimisation MySQL 5 Bonnes Pratiques Pour l'Administrateur