Vous êtes sur la page 1sur 288

Diagnostic durgence et traitements de choc Procdures adaptes au niveau durgence : dix minutes, une heure,

une journe Dans les entrailles de votre serveur MySQL Caractristiques physiques et lments cls du serveur
Mmoire Disques CPU Rseau 64 bits Limites de MySQL face au hardware CPU multicoeur Rplication
monothreade Fonctionnement de MyISAM et dInnoDB tude des diffrents moteurs de stockage Comprendre
son moteur de stockage MyISAM InnoDB Doit-on forcment sacrifier les performances la stabilit ? Analyser
le fonctionnement de son serveur MySQL : monitoring O trouver les informations pertinentes Variables systme et
variables dtat Quels outils choisir ? Outils propres MySQL mysqladmin / mysqladministrator Outils externes
iostat et vmstat top et htop Dtecter les goulets dtranglement I/O disques CPU Rseau valuer
les performances de son serveur Benchmarks et dimensionnement (capacity planning) Exploiter les logs Logs
derreur Dtection des requtes coteuses : slow queries log Logs systme syslog dmesg Problmes lis
la rplication Solutions aux problmes frquents Rplication et performance Rplication et fiabilit Reprise
sur arrt dune rplication Tuning du serveur MySQL Analyser les tables Analyser les index Vrifier les droits
des utilisateurs Fichier de configuration de MySQL Le trop ennemi du bien ? Les paramtres quil faut
matriser O trouver de laide Blogs Forums.

qui sadresse cet ouvrage ?


tous les administrateurs de bases de donnes en qute de performances ;
Aux DBA MySQL souhaitant aiguiser leur capacit auditer et optimiser leurs bases ;
Aux administrateurs systme souhaitant approfondir leur comprhension des relations entre une base MySQL et les
matriel et systme dexploitation sous-jacents ;
Aux dveloppeurs (Java, PHP, Ruby, Python) utilisant MySQL et rencontrant des problmes de performances.

Arnaud Gadal est


ladministrateur des bases
de donnes MySQL de
Virgin Mobile. Il est certifi
MySQL 5 (dveloppement,
administration, cluster),
membre du MySQL User
Group et principal auteur
sur www.dbnewz.com

Audit et optimisation

Au sommaire

Olivier Dasini a 10 ans


dexprience en tant que
consultant et formateur
certifi MySQL. Aujourdhui
expert en bases de donnes
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.

Audit et
optimisation

MySQL 5

MySQL 5

Cet ouvrage sadresse tous ceux qui conoivent, exploitent et maintiennent une base de donnes MySQL et souhaitent optimiser les performances de leurs serveurs ou rencontrent des problmes de charge. Il rpond aux questions
de ladministrateur : que faire en cas de problmes de performances lis la base de donnes ? Quelles directions
prendre face un serveur MySQL rticent, en pleine situation durgence alors que les utilisateurs grondent ?
Quil sagisse dune mauvaise gestion de la mmoire vive, de disques saturs, dune gestion perfectible des index,
de requtes trop gourmandes, de moteurs de stockage inadapts, etc., cet ouvrage aidera ladministrateur ou le
dveloppeur MySQL trouver le goulet dtranglement en cause. Non sans dcortiquer le fonctionnement du serveur
MySQL et de ses diffrents moteurs (InnoDB, MyISAM, Merge, Memory/HEAP, Archive.), les auteurs guident le
DBA travers toutes les bonnes pratiques daudit et doptimisation, de la conception du schma de la base jusqu
la rsolution des problmes lis la rplication, sans oublier de lclairer sur les choix matriels faire pour ses
serveurs.

Conception : Nord Compo

Un concentr dexpertise pour le DBA MySQL : les bonnes pratiques,


de la conception loptimisation

Pascal Borghino est


architecte de bases de
donnes chez Yahoo!
International. Il est
confront au quotidien
de nombreux problmes,
tant au niveau du design,
de lextensibilit que des
performances. Il est
prsident et fondateur
du MySQL User Group
Francophone (LeMUG.fr) et
crateur du blog
www.dbnewz.com.

9 7 8221 2 1 263 41

La grande majorit des applications web sadossent la base de donnes MySQL et imposent
ladministrateur de base de donnes des contraintes de performances et de fiabilit.

Les auteurs

Code diteur : G12634


ISBN : 978-2-212-12634-1

MySQL 5

P. B o r g h i n o
O. Dasini
A. Gadal

Audit et optimisation

Bonnes pratiques
pour ladministrateur

Pascal Borghino
Olivier Dasini
Arnaud Gadal

35

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Un concentr dexpertise pour le DBA MySQL : les bonnes pratiques,


de la conception loptimisation
Cet ouvrage sadresse tous ceux qui conoivent, exploitent et maintiennent une base de donnes MySQL et souhaitent optimiser les performances de leurs serveurs ou rencontrent des problmes de charge. Il rpond aux questions
de ladministrateur : que faire en cas de problmes de performances lis la base de donnes ? Quelles directions
prendre face un serveur MySQL rticent, en pleine situation durgence alors que les utilisateurs grondent ?
Quil sagisse dune mauvaise gestion de la mmoire vive, de disques saturs, dune gestion perfectible des index,
de requtes trop gourmandes, de moteurs de stockage inadapts, etc., cet ouvrage aidera ladministrateur ou le
dveloppeur MySQL trouver le goulet dtranglement en cause. Non sans dcortiquer le fonctionnement du serveur
MySQL et de ses diffrents moteurs (InnoDB, MyISAM, Merge, Memory/HEAP, Archive.), les auteurs guident le
DBA travers toutes les bonnes pratiques daudit et doptimisation, de la conception du schma de la base jusqu
la rsolution des problmes lis la rplication, sans oublier de lclairer sur les choix matriels faire pour ses
serveurs.

Au sommaire
Diagnostic durgence et traitements de choc Procdures adaptes au niveau durgence : dix minutes, une heure,
une journe Dans les entrailles de votre serveur MySQL Caractristiques physiques et lments cls du serveur
Mmoire Disques CPU Rseau 64 bits Limites de MySQL face au hardware CPU multicoeur Rplication
monothreade Fonctionnement de MyISAM et dInnoDB tude des diffrents moteurs de stockage Comprendre
son moteur de stockage MyISAM InnoDB Doit-on forcment sacrifier les performances la stabilit ? Analyser
le fonctionnement de son serveur MySQL : monitoring O trouver les informations pertinentes Variables systme et
variables dtat Quels outils choisir ? Outils propres MySQL mysqladmin / mysqladministrator Outils externes
iostat et vmstat top et htop Dtecter les goulets dtranglement I/O disques CPU Rseau valuer
les performances de son serveur Benchmarks et dimensionnement (capacity planning) Exploiter les logs Logs
derreur Dtection des requtes coteuses : slow queries log Logs systme syslog dmesg Problmes lis
la rplication Solutions aux problmes frquents Rplication et performance Rplication et fiabilit Reprise
sur arrt dune rplication Tuning du serveur MySQL Analyser les tables Analyser les index Vrifier les droits
des utilisateurs Fichier de configuration de MySQL Le trop ennemi du bien ? Les paramtres quil faut
matriser O trouver de laide Blogs Forums.

qui sadresse cet ouvrage ?


tous les administrateurs de bases de donnes en qute de performances ;
Aux DBA MySQL souhaitant aiguiser leur capacit auditer et optimiser leurs bases ;
Aux administrateurs systme souhaitant approfondir leur comprhension des relations entre une base MySQL et les
matriel et systme dexploitation sous-jacents ;
Aux dveloppeurs (Java, PHP, Ruby, Python) utilisant MySQL et rencontrant des problmes de performances.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Olivier Dasini a 10 ans


dexprience en tant que
consultant et formateur
certifi MySQL. Aujourdhui
expert en bases de donnes
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
ladministrateur des bases
de donnes MySQL de
Virgin Mobile. Il est certifi
MySQL 5 (dveloppement,
administration, cluster),
membre du MySQL User
Group et principal auteur
sur www.dbnewz.com

Conception : Nord Compo

La grande majorit des applications web sadossent la base de donnes MySQL et imposent
ladministrateur de base de donnes des contraintes de performances et de fiabilit.

Pascal Borghino est


architecte de bases de
donnes chez Yahoo!
International. Il est
confront au quotidien
de nombreux problmes,
tant au niveau du design,
de lextensibilit que des
performances. Il est
prsident et fondateur
du MySQL User Group
Francophone (LeMUG.fr) et
crateur du blog
www.dbnewz.com.

Proprit de Albiri Sigue <tag.tog@gmail.com>

Audit et optimisation

Les auteurs

Audit et
optimisation

MySQL 5

MySQL 5

MySQL 5

P. B o r g h i n o
O. Dasini
A. Gadal

Audit et optimisation

Bonnes pratiques
pour ladministrateur

Pascal Borghino
Olivier Dasini
Arnaud Gadal

Audit et
optimisation
MySQL 5
Bonnes pratiques
pour ladministrateur

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Chez le mme diteur


J.-M. Defrance. Premires applications web avec Ajax, jQuery et PHP.
N12672, 2010, 474 pages
J. Gabs. Nagios 3 pour la supervision et la mtrologie. Dploiement, configuration et optimisation.
N12473, 2009, 510 pages
T. Sarlandie. Programmation iPhone OS 3. Conception, ergonomie, dveloppement et publication.
N12477, 2009, 276 pages
S. Jaber. Programmation GWT 2. Dvelopper des applications RIA et Ajax avec le Google Web Toolkit.
N12569, 2010, 484 pages
P. Sultan, dirig par N. Makarvitch. Asterisk. tudes de cas. (coll. Cahiers de lAdmin).
N12434, 2010, 298 pages.
R. Rimel. Mmento MySQL.
N12720, 2e dition 2010, 14 pages.
C. Pierre de Geyer, G. Ponon. Mmento PHP 5 et SQL.
N12457, 2e dition 2009, 14 pages.
R. M. Stallman, S.Williams, C. Masutti (Framasoft). Richard Stallman et la rvolution du logiciel libre.
Une biographie autorise. N12609, 2010, 344 pages.
H. Bersini, I. Wellesz. La programmation oriente objet. Cours et exercices en UML2 avec Java5, C#2,
C++, Python et PHP5. N12441, 4e dition, 2009, 602 pages (collection Noire).
V. Messager Rota. Gestion de projet. Vers les mthodes agiles.
N12518, 2e dition 2009, 272 pages (collection Architecte logiciel).
J.-L. Bnard, L. Bossavit , R. Mdina , D. Williams. Gestion de projet eXtreme Programming.
N11561, 2002, 300 pages (collection Architecte logiciel).
A. Fernandez-Toro, prface de H. Schauer (HSC Consultants). Management de la scurit de linformation.
Implmentation ISO27001. Mise en place dun SMSI et audit de certification. N12622, 2e dition, 2009, 284 pages.
G. Ponon. Best practices PHP 5. Les meilleures pratiques de dveloppement en PHP.
N11676, 2005, 480 pages.
L. Bloch, C. Wolfhugel. Scurit informatique. Principes et mthode lusage des DSI, RSSI et administrateurs.
N12525, 2009, 292 pages.
F. Potencier et H. Hamon. Symfony. Mieux dvelopper en PHP avec Symfony 1.2 et Doctrine.
N12494, 2009, 510 pages.
G. Ponon et J. Pauli. Zend Framework.
N12392, 2008, 460 pages.

pII.indd 1

02/03/10 17:41

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Audit et
optimisation
MySQL 5
Bonnes pratiques
pour ladministrateur

Pascal Borghino
Olivier Dasini
Arnaud Gadal

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

ditions Eyrolles
61, bd Saint-Germain
75240 Paris Cedex 05
www.editions-eyrolles.com

Le code de la proprit intellectuelle du 1er juillet 1992 interdit en effet expressment la photocopie
usage collectif sans autorisation des ayants droit. Or, cette pratique sest gnralise notamment dans
les tablissements denseignement, provoquant une baisse brutale des achats de livres, au point que la
possibilit mme pour les auteurs de crer des uvres nouvelles et de les faire diter correctement est
aujourdhui menace.
En application de la loi du 11 mars 1957, il est interdit de reproduire intgralement ou partiellement le prsent
ouvrage, sur quelque support que ce soit, sans lautorisation de lditeur ou du Centre Franais dexploitation 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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Avant-propos
Un ouvrage en franais pour aller plus loin
Lide de dpart de cet ouvrage fut dcrire ce que nous-mmes aurions aim trouver
en librairie au rayon MySQL.
Le contenu que nous vous proposons aujourdhui, et qui sera dtaill dans quelques
paragraphes, est le fruit de la diversit de nos expriences respectives (un administrateur base de donnes, un expert MySQL et un architecte bases de donnes). En parcourant ce livre, vous profiterez de nos expriences acquises auprs de grands
comptes de lunivers Internet, tels que Orange Business Services, Virgin Mobile ou
encore Yahoo!
Nous souhaitions crire un livre permettant de mieux comprendre la fois MySQL
en tant que pice logicielle, mais aussi son lien avec le serveur physique sur lequel
cette base de donnes est installe. Cette subtile interaction entre logiciel et matriel
o interviennent plusieurs centaines de variables et autres paramtres, est susceptible
datteindre de hautes performances lorsque tous agissent de concert.
Cependant, il ne sagit pas uniquement de dcrire les mcanismes responsables des
multiples comportements de MySQL observs ; il faut surtout les expliquer.
Directement issu de nos vies professionnelles, cet ouvrage est un reflet condens de
nos diffrentes expriences. Ce que vous lirez ici, nous lavons vraiment vcu. Les
fortes charges, les pics daffluence, les corruptions de donnes, les requtes qui nen
finissent pas, une volumtrie qui explose, des rplications en chec, des serveurs
MySQL lagonie... nous y avons tous got !
Fort heureusement, les problmes que nous venons dvoquer ne sont pas une fatalit
et les bonnes pratiques exposes dans cet ouvrage vous permettront de les viter pour
la plupart ou, en tout cas, de les grer au mieux. Rassurez-vous, les diffrents chapitres qui vont suivre ne sont pas une suite de rcits de cataclysmes MySQL ! Au con-

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

VI

MySQL 5 Audit et optimisation

traire, il sagit plutt de prvenir ces cueils en adoptant les bonnes techniques qui
vous permettront, vous qui grez ou utilisez au quotidien des bases MySQL, de les
utiliser le mieux possible.
Le titre, MySQL 5 - Audit et optimisation, rsume le cur de louvrage. En analysant
techniquement un serveur MySQL lors de la phase daudit, nous tablissons un diagnostic qui permettra les optimisations appliques sur cette machine. Cest ainsi que
tous les chapitres apportent leur valeur ajoute cette thmatique.
Nous ne connaissions pas douvrage en franais rassemblant ltendue des thmes
voqus ici. Le livre que vous tenez entre les mains nest pas simplement du contenu
pointu en franais . Sa plus-value rside galement dans notre fort intrt pour
MySQL. Nous sommes trois passionns de cette base de donnes (bloggeurs, association LeMug.fr) et notre but tout au long du livre est de vous faire partager cette
passion tout en dcortiquant les mcanismes de MySQL de faon claire et pratique.
Encarts, schmas et exemples tayeront notre propos et vous guideront tout au long
du chemin que nous vous avons trac vers loptimisation de vos serveurs MySQL.

qui sadresse cet ouvrage ?


Cet ouvrage est particulirement destin tous ceux qui ont dj des connaissances
de base en MySQL et qui sont soumis des problmes lis une activit croissante
sur leurs bases de donnes.
Quil sagisse dune audience croissante, de donnes de plus en plus lourdes ou encore
dengranger rapidement de nouvelles connaissances pointues sans avoir parcourir
toute la blogosphre anglophone, ce livre saura vous apporter des solutions concrtes
ou vous aiguiller vers la bonne faon de faire.
De par son contenu, cet ouvrage sadresse plutt aux administrateurs de bases de
donnes, quils soient spcialistes de MySQL ou pas, quaux dveloppeurs. Cependant, les plus curieux dentre eux trouveront des informations sur loptimisation de
leurs requtes et sur les diffrences entre les moteurs de stockage, par exemple.
Pour les administrateurs MySQL, nous avons essay dapporter le maximum dinformations utiles leur mtier, notamment sur les outils que nous utilisons pour auditer
un serveur, loptimiser, mesurer ses performances, anticiper ses problmes... Vous y
trouverez donc tous nos meilleurs conseils.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Avant-propos

VII

Structure de louvrage
Louvrage est dcoup en huit chapitres quil est possible daborder indpendamment
les uns des autres. Si certains thmes sont abords dans plusieurs chapitres, nous le
signalons par des renvois appropris. De notre point de vue, seul le chapitre Grer
une situation durgence avec MySQL devait apparatre en premier, lordre de lecture des autres chapitres nayant que peu dimportance.
Si vous tes particulirement intress par la rplication, vous avez notre bndiction
pour attaquer directement par le chapitre 7.
Outre les liens entre chapitres que nous venons dvoquer et la possibilit de ne lire
que certains chapitres, cest en lisant lintgralit de louvrage que vous aurez une vue
densemble de toutes les techniques dcrites, ce qui vous rendra plus efficace.
De plus, nous navons pas multipli le nombre de chapitres artificiellement mais
choisi au contraire de restreindre notre champs dtude aux notions les plus importantes selon nous concernant laudit et loptimisation dun serveur MySQL.
Nous dbuterons donc par MySQL et lurgence (chapitre 1). Que faire quand rien
ne va plus ? Les bases de donnes sont un domaine o ne rien faire est parfois la
meilleure des solutions... dans lattente de trouver une rponse adapte ; et o
tenter quelque chose sans en analyser les consquences est potentiellement dramatique et viter. Dix minutes, une heure ou une journe, voici les trois scnarios
durgence que nous vous proposons de rsoudre dans ce premier chapitre, le tout
agrment de nos meilleurs conseils dans un tel contexte.
Le chapitre 2, Choisir son serveur MySQL , met laccent sur les impacts du matriel sur MySQL. La mmoire, les disques (RAID et cartes contrleur, SSD), les processeurs (quantit, combien de curs ?), ces lments ont une importance cruciale
pour la base de donnes. Apprenez les choisir.
InnoDB, MyISAM, Memory, Archive... une des spcificits de MySQL est de pouvoir 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 choix
dun moteur par rapport un autre. Saviez-vous par exemple que le plan dexcution
de vos requtes varie en fonction du moteur ? Comment fonctionnent les index ou
les caches selon les moteurs, quelles sont les forces et les faiblesses de chacun ?
Toutes les informations dont vous avez besoin pour choisir le moteur quil vous faut
se trouvent ici.
Le chapitre 4 vous aidera connatre ltat de sant de votre serveur MySQL.
Prendre le pouls dun serveur ncessite de comprendre le fonctionnement des variables systme et des variables de statut. Quels sont les liens qui les unissent et les
outils qui les exploitent ? Vrifier ltat de sant du moteur InnoDB lui-mme, pr-

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

VIII

MySQL 5 Audit et optimisation

voir la capacit maximale de votre systme (capacity planning) et une tude de cas
sont au programme.
Les journaux MySQL sont dtaills au chapitre 5. Ne sous-estimez pas la puissance
des logs. Bien exploits, ils seront un alli de premier ordre non seulement en cas de
coup dur mais galement au quotidien. Jugez plutt : journalisation des erreurs, logs
des requtes lentes, logs binaires pour la rplication, les logs sont partout.
Les chapitres 6 et 7 baignent dans loptimisation. Les index, les requtes, ltude du
serveur lui-mme (variables cls du fichier my.cnf), les caches en tous genres, mais
aussi les optimisations propres certains moteurs de stockage ainsi que le partitionnement sont autant de notions abordes dans ce chapitre.
La rplication se dvoile au chapitre 8. Cette fonctionnalit cruciale offerte par
MySQL y est traite avec beaucoup de dtails. quoi sert-elle, comment la mettre
en place, quelles sont les commandes cls sur le matre et lesclave ? Les diffrentes
architectures disponibles et la rsolution des problmes lis cette technologie sont
galement au programme.
Enfin, si daventure notre ouvrage vous laissait avec des questions en suspens, le
chapitre 8 indique o trouver de laide. Souhaitez-vous obtenir une aide de toute
urgence ou simplement poser une question gnrale sur un forum ou une mailing-list
adquate ? Peut-tre cherchez-vous les meilleurs blogs francophones ou anglophones
pour enrichir vos connaissances ? Vous y trouverez nos meilleures adresses.

Remerciements
Plus attendue que la gloire ternelle lie la rdaction dun ouvrage technique, lcriture de ces quelques paragraphes de remerciements fait sans doute partie dune des
motivations principales dun auteur, nous nous plions donc volontiers cette tradition.
crire ce livre plusieurs mains a t pour moi une exprience enrichissante en
grande partie grce au professionnalisme de mes co-auteurs. Je tenais donc premirement 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 et
Gal Thomas de lquipe ditoriale dEyrolles qui ont pu grer avec patience nos
lgers retards et nous ont permis de nous focaliser sur le contenu et le fond. Ce livre
naurait pas vu le jour non plus sans Vronique Loquet dALX communication, dont
la passion et la connaissance du monde de lopen source ont su nous ouvrir les portes
ncessaires. Encore merci Vronique !

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Avant-propos

IX

Je voulais aussi remercier mes managers qui ont permis mon implication dans le
monde de MySQL, dans lordre : Rmy, Bruno, Dana et Rusty... Je noublie pas non
plus mes formidables amis de la communaut MySQL elle-mme : merci Jeremy,
ric et toute la bande.
Enfin, merci mes parents Daniel et Danielle qui seront toujours la source de tous
mes accomplissements...
Pascal Borghino

Je remercie mes deux amis, co-auteurs et gourous MySQL, Arnaud et Pascal, sans
qui ce livre naurait jamais vu le jour. Je tiens galement y associer toute lquipe de
MySQL France, notamment Stphane Varoqui et Serge Frezefond pour leur savoir
infini. Merci tous les passionns du logiciel libre rencontrs au fil des annes, sur les
forums, les salons, dans les associations (LeMUG.fr, lAFUP, lApril...) et sur mon
blog (http://dasini.net/blog/).
Une tendre pense pour mes parents Jean et Jocelyne, mes surs Karen et Linda,
mon frre Floriant et Kapinou (pour ta patience).
Enfin, je ddie ce livre la mmoire de Valrie et Paul BERCHEL, ainsi que celle de
Raymond DASINI.
Olivier Dasini

Je ne crois pas au destin mais plutt au timing et un peu au hasard. Dbut 2006, je
quittais Paris pour trois ans au dtour dun job dingnieur dveloppement PHP pour
le soleil de Sophia-Antipolis. Au bout dun an, alors que je renforais srieusement
mes connaissances MySQL, deux collgues l-bas ont probablement fait basculer ma
carrire. Tout dabord Gilles Oliveri (merci), qui a remarqu que je serais peut-tre
mieux employ faire du MySQL que du PHP chez Orange, puis Cyril Scetbon
(merci) qui ma fait confiance et ma accueilli dans la cellule Bases de donnes o jai
pu apprendre, parfaire mes connaissances et surtout les mettre en pratique.
En 2008, ma passion pour MySQL ma pouss me rendre la confrence annuelle
de MySQL en Californie. L-bas, Damien Seguy (merci) ma prsent Pascal
(merci) qui ma propos de blogger pour dbnewz.com lors dun MySQL Quizz Show
alors que je lui reprochais de ne pas publier assez souvent ! Pas rancunier lanimal...
Quant Olivier (merci), jai rencontr sa bonne humeur lgendaire lors dun forum
PHP/MySQL il y a quelques annes. croire que toutes les routes mnent
MySQL...

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

MySQL 5 Audit et optimisation

Mi-2009, Pascal et Olivier mont propos dtre le troisime homme pour la rdaction de cet ouvrage. Jai accept avant de savoir que jaurais les relire... Une pure
folie... que je ne regrette pas ! Merci encore tous les deux.
toute lquipe 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 un
avant-propos est trs bon signe pour la suite.
Bonne lecture !
Arnaud Gadal

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Table des matires


CHAPITRE 1
Grer une situation durgence avec MySQL ................................ 1
chaque degr durgence sa panoplie doutils . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Temps de rsolution : dix minutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
tape 0 : informez et communiquez ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Ne restez pas seul et discutez avec dautres administrateurs . . . . . . . . . . . . . . . . 3
Consultez les informations systme : journal derreurs,
activits disques et processeur... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Tentez de vous connecter la base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
ATTENTION Prcautions prendre avec une table MyISAM corrompue . . . . . . . . . . . . . . . . 4
ASTUCE Dfilement page par page pour SHOW FULL PROCESSLIST . . . . . . . . . . . . . 5
SAVOIR viter lempilement des requtes et dcrypter le SHOW PROCESSLIST . . . . . . 5
REMARQUE Se rfrer aux chapitres concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Supprimer les requtes les plus lourdes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
PRATIQUE Supprimer des requtes rapidement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
viter que lauthentification des utilisateurs repose sur un DNS : lerreur unauthenticated user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Consulter son systme de surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Tranche de vie dune campagne marketing improvise . . . . . . . . . . . . . . . . . . . . . . . . 9
Temps de rsolution : une heure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
La chasse aux requtes lentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
LIRE Un chapitre consacr ltude des journaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Rcrire les requtes trop coteuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
ASTUCE Les tables statiques la rescousse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Les problmes de rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Temps de rsolution : une journe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
LIRE Chapitre 8 consacr la rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
PRATIQUE Un problme peut en cacher un autre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Conseils gnraux face lurgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Tirer profit du pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Anticiper les problmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
ATTENTION Modifications chaud, en production . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

XII

MySQL 5 Audit et optimisation

Lentranement lurgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Enregistrer les donnes de lincident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Ltat desprit adopter dans lurgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Trouver de laide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

CHAPITRE 2
Choisir son serveur MySQL ......................................................... 19
La mise jour matrielle, une tape ncessaire ? . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Les questions se poser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
ASTUCE Identifier les goulets dtranglements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
ASTUCE Optimiser son serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
JARGON Scaling up, scaling out et scaling back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Du 64 bits oui... mais partout ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Limites des systmes 32 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ATTENTION Ne soyez pas trop gourmands ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
RESSOURCES EN LIGNE Davantage de dtails sur ladressage mmoire . . . . . . . . . . . . . . . . . . 24
Choisir ses processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
tat des lieux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Les solutions face aux problmes de monte en charge . . . . . . . . . . . . . . . . . . 25
JARGON Architecture SMP vs NUMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
REMARQUE La comptition omniprsente entre les diffrents acteurs . . . . . . . . . . . . . . . . 26
LIRE GALEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Choisir son processeur : les critres de choix . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Quelle est lutilisation actuelle de vos processeurs ?. . . . . . . . . . . . . . . . . . . . . . . 27
SAVOIR MySQL et la gestion des threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Frquence vs nombre de curs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
JARGON OLTP, OLAP : deux catgories de systmes grer diffremment . . . . . . . . . . . 28
Benchmarks, encore et toujours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
LIRE GALEMENT Mesurer les performances de son systme . . . . . . . . . . . . . . . . . . . . . . . . 29
RAPPEL Configurer son serveur MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
ASTUCE Pour aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Choisir ses disques et son systme RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
SAVOIR Temps daccs mmoire vs temps daccs disques . . . . . . . . . . . . . . . . . . . . . . . 32
Temps daccs versus taux de transfert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
RETENIR Lecture/criture alatoire ou squentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
La technologie RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
ATTENTION La rplication et la monte en charge des critures . . . . . . . . . . . . . . . . . . . . 34
Les principaux niveaux de RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
REMARQUE Les opposants au RAID 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
RESSOURCES EN LIGNE Dautres niveaux de RAID existent . . . . . . . . . . . . . . . . . . . . . . . . . 37
Les deux implmentations du RAID : logicielle et matrielle. . . . . . . . . . . . . . . 38
REMARQUE Carte contrleur RAID, force et faiblesse la fois . . . . . . . . . . . . . . . . . . . . . 38

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Table des matires

XIII

Intrt du cache sur une carte contrleur RAID . . . . . . . . . . . . . . . . . . . . . . . . 39


. . . . . . . . . . . . . . . 40
. . . . . . . . . . . . . . . 41
Indispensable batterie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
EN PRATIQUE Dure de vie de la batterie dune carte RAID . . . . . . . . . . . . . . . . . . . . . . 42
Le cache interne des disques : une arme double tranchant . . . . . . . . . . . . . . . . 42
JARGON innodb_flush_method = O_DIRECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
LIRE GALEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Les SSD : futur hit ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
MySQL et la mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Comment MySQL utilise-t-il la mmoire ? . . . . . . . . . . . . . . . . . . . . . . . . . . 46
RAPPEL Le cache de requtes en amont de la carte RAID . . . . . . . .
BON SAVOIR Les outils pour vrifier les rglages de sa carte contrleur

CHAPITRE 3
Les moteurs de stockage ............................................................ 49
Mcanismes dun moteur de stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Installation et suppression dun moteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
ATTENTION Suppression dun moteur de stockage utilis par une table . . . . . . . . . . . . . . . . 54
Les forces en prsence : moteurs utilis par lapplication . . . . . . . . . . . . . . . . . 54
B.A.-BA Crer ses tables partir de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
CONVENTIONS TERMINOLOGIQUES Base de donnes, serveur, instance, schma . . . . . . . . . . . . . . . . 57
Les critres de choix dun moteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Moteurs disponibles : InnoDB, MyISAM, Merge, Memory, Archive . . . . . . . . 58
Le moteur InnoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
B.A-BA Les proprits ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
BON SAVOIR Le MVCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
ASTUCE Sortir une table dun tablespace partag . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
POUR ALLER PLUS LOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
MyISAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Mcanismes internes de MyISAM et formats de stockage . . . . . . . . . . . . . . . . . 67
B.A.-BA Chaud, froid ou tide ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
RAPPEL Mcanisme dune commande ALTER TABLE . . . . . . . . . . . . . . . . . . . . . . . 68
Le moteur MERGE pour agrger plusieurs tables MyISAM . . . . . . . . . . . . . 69
Le moteur MEMORY (anciennement HEAP) . . . . . . . . . . . . . . . . . . . . . . . 71
Le moteur ARCHIVE pour un archivage compress . . . . . . . . . . . . . . . . . . . 72
Autres moteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
XtraDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Falcon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Federated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Blackhole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

XIV

MySQL 5 Audit et optimisation

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

CHAPITRE 4
Surveiller son serveur MySQL..................................................... 81
O trouver les informations pertinentes ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Variables systme et variables de statut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
DFINITION Variables systme ou de statut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
ALTERNATIVE Rcuprer les variables systme ou de statut . . . . . . . . . . . . . . . . . . . . . . . . 82
Quels outils choisir ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
SAVOIR Variables systme et my.cnf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
ATTENTION Une valeur peut en cacher une autre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
SAVOIR Diffrence entre un client et un outil MySQL . . . . . . . . . . . . . . . . . . . . . . . . 84
Intrt des outils de surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.A.-BA key_buffer_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Outils et commandes fournis par MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
ATTENTION Variables globales vs variables de session . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Catgorie General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.A.-BA MySQL vs mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
ASTUCE Les jokers dans les commandes MySQL : % et _ . . . . . . . . . . . . . . . . . . . . . . . 89
LE SAVIEZ-VOUS Deux descripteurs de fichiers pour une table MyISAM . . . . . . . . . . . . . . . 89
Catgorie Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
SAVOIR Le cache de requte (Query Cache ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
RAPPEL Le cache MyISAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
RAPPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
SAVOIR Ajuster la taille du cache dindex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
ATTENTION Sortir un serveur client de la liste noire dun serveur MySQL . . . . . . . . . . . . . 99
SAVOIR Droits ncessaires aux commandes SHOW STATUS et SHOW VARIABLES . . 99
ASTUCE Optimiser et analyser une requte avec USE INDEX/IGNORE INDEX . . . . . 104
La commande SHOW ENGINE INNODB STATUS . . . . . . . . . . . . . . . . 104
SAVOIR Diffrence entre mutex et smaphores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
ASTUCE Crer un deadlock dlibr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
LIRE GALEMENT Le MVCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Table des matires

XV

INFORMATION_SCHEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Connatre et savoir exploiter les outils de surveillance . . . . . . . . . . . . . . . . . . . . 114
Quest-ce que la performance ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
LIRE Technologie du disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
LVM : la gestion des volumes logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
JARGON Transactionnel et cohrence, quelles diffrences ? . . . . . . . . . . . . . . . . . . . . . . 118
B.A.-BA Les diffrents types de sauvegardes (backups) . . . . . . . . . . . . . . . . . . . . . . . . 119
tude de cas : analyse dun serveur MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
RAPPEL write-through/write-back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Mesurer lactivit du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Les outils systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
La commande iostat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
La commande vmstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Les commandes netstat et mpstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
ALTERNATIVE oprofile, dtrace, fincore et filefrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Outils daudit : MySQLTuner et mysqlreport . . . . . . . . . . . . . . . . . . . . . . . . 127
ASTUCE Surveiller son serveur distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Outils danalyse temsp rel : mytop, mtop, innotop et maatkit . . . . . . . . . . . . 131
valuer les performances dun systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
JARGON Le smoke test, un test aux limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
MTHODE Dimensionnement : les bons tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Bien dimensionner un systme (capacity planning) . . . . . . . . . . . . . . . . . . . . 136
SAVOIR La notion de seuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
LIRE La monte en charge matrielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
LIRE Pour aller plus loin dans le domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

CHAPITRE 5
Exploiter les journaux de MySQL ............................................. 141
Le journal des erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
ASTUCE Rotation des journaux avec logrotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Identifier et rsoudre les problmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Modifier le tablespace ou les journaux dInnoDB . . . . . . . . . . . . . . . . . . . . . 143
Paramtre incorrect dans le fichier de configuration . . . . . . . . . . . . . . . . . . . 144
Erreurs lies la rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Erreurs diverses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
ATTENTION Effets de bord de loption myisam_recover . . . . . . . . . . . . . . . . . . . . . . . . . 148
Le journal des requtes lentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
ATTENTION Effets de bord de loption log_queries_not_using_indexes . . . . . . . . . . . . . . . 149
ALTERNATIVE Autres outils danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Journaliser dans une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

XVI

MySQL 5 Audit et optimisation

Le journal gnral des connexions et requtes . . . . . . . . . . . . . . . . . . . . . . . . . . 153


Exemples dutilisations de la journalisation gnrale ? . . . . . . . . . . . . . . . . . . 154
La journalisation binaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
REMARQUE Loption sync_binlog peut avoir un impact sur les performances . . . . . . . . . . 155
TRANCHE DE VIE La technique de Point In Time Recovery en pratique . . . . . . . . . . . . . . . 157
REMARQUE Taille du journal binaire en fonction du mode de journalisation . . . . . . . . . . 158
Bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

CHAPITRE 6
Optimiser sa base de donnes : du schma aux requtes ..... 163
Conception de la base de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Normalisation/dnormalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
BON SAVOIR La normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
OUTILS Logiciels de modlisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Ajouter des colonnes dans une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Cration de tables dagrgation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Cration de schmas orients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Des types de donnes ajusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
MTHODE Un type optimal un moment donn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Les jointures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Les index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Index B-tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
B.A.-BA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
BON SAVOIR Index Fulltext (Plaintext) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Index B+tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
BON SAVOIR La table de hachage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Index hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
ALTERNATIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Optimisation des requtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Connatre loptimiseur pour mieux le comprendre . . . . . . . . . . . . . . . . . . . . . 181
B.A.-BA La slectivit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
BON SAVOIR Optimiseurs base de rgles ou de cot (cost based ou rules based) . . . . . . . . 182
La commande EXPLAIN pour analyser lexcution des requtes . . . . . . . . . . 182
PRATIQUE Visualiser le plan dexcution dun DELETE ou dun UPDATE . . . . . . . . . 183
REMARQUE Attention la fonction RAND() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
OUTILS Reprsentation graphique du plan dexcution avec Maatkit . . . . . . . . . . . . . . 186
BON SAVOIR Optimisation des index et rorganisation des tables
avec ANALYSE TABLE et OPTIMIZE TABLE . . . . . . . . . . . . . . . . . . . . . . . . 187

Exemple doptimisation dun plan dexecution . . . . . . . . . . . . . . . . . . . . . . . . 187


Indexer les premiers caractres dune colonne . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Index couvrant (covering index) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Table des matires

XVII

Prfixe dindex (leftmost prefix indexes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190


. . . . . . . . . . . . . . . . . . . . . . . 190
Taille des index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Rcapitulatif des bonnes pratiques doptimisation des requtes . . . . . . . . . . . 190
Dcouper les requtes complexes en plusieurs plus simples. . . . . . . . . . . . . . . . . 191
BON SAVOIR Pas de prfixes dindex pour les index hash

CHAPITRE 7
Optimiser son serveur mySQL .................................................. 193
Tuning serveur : variables de session, variables globales, handlers . . . . . . . . . . . 193
VOCABULAIRE Cache et buffer (tampon) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Les variables de session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
read_buffer_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
read_rnd_buffer_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
sort_buffer_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
join_buffer_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
tmp_table_size et max_heap_table_size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Les variables globales au serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Le cache de table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Le cache de thread. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Table_locks_immediate et Table_locks_waited. . . . . . . . . . . . . . . . . . . . . . . . 198
Aborted_clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Aborted_connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Les handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Exemple doptimisation dune requte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Les droits des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Optimisations pour InnoDB, MyISAM et MEMORY . . . . . . . . . . . . . . . . . . 204
Optimisation InnoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Optimisation MyISAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Cache dindex multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Optimisation Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
ATTENTION Limiter la taille des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
RAPPEL Limitations du moteur Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Le cache de requtes (query cache) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Gestion du cache de requtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
ATTENTION Taille du cache de requtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Le partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Le partitionnement par RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Le partitionnement par LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Le partitionnement par HASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Le partitionnement par KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Partitionner sur diffrents disques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

XVIII

MySQL 5 Audit et optimisation

Partitionner sur diffrents disques avec MyISAM . . . . . . . . . . . . . . . . . . . . . 215


BON SAVOIR volution du partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

CHAPITRE 8
La rplication MySQL ................................................................ 217
Introduction la rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Intrt de la rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Le dimensionnement horizontal (scale out) . . . . . . . . . . . . . . . . . . . . . . . . . . 219
La sauvegarde chaud (hot backup) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Le basculement automatique (Failover) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Redondance gographique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Le cas du dcisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Tester une nouvelle version de MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
lintrieur de la rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Mise en place de la rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Configuration du matre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
ATTENTION Mot de passe en clair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
BON SAVOIR Filtrage des donnes rpliques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Configuration de lesclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
REMARQUE Mettre jour lesclave avant le matre . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
ATTENTION Ancienne mthode de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Configuration avance de lesclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Commandes de la rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Sur lesclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
ATTENTION Consquences dun RESET SLAVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
ASTUCE Comment savoir si le serveur esclave a du retard ? . . . . . . . . . . . . . . . . . . . . 230
La commande SHOW SLAVE STATUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Sur le matre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
ASTUCE Dconnexion dun serveur esclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
ATTENTION RESET MASTER peut casser la rplication . . . . . . . . . . . . . . . . . . . . . . 233
Problmes lis la rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
IO_THREAD stopp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
SQL_THREAD stopp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
DANGER Ignorer les erreurs peut provoquer des incohrences . . . . . . . . . . . . . . . . . . . . 235
BON SAVOIR Tables temporaires et rplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Architectures de rplication avances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
REMARQUE MySQL Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Dual master en actif/passif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
DANGER Une rplique nest pas une sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
OUTILS Supervision des serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Table des matires

XIX

Exemple : switchover pour une mise jour online des serveurs MySQL . . . . . 239
Rcapitulatif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
ALTERNATIVE Commencer par le matre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Dual master en actif/actif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Rcapitulatif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Rplication circulaire (nombre de rplications > 2) . . . . . . . . . . . . . . . . . . . . 244
Esclave relais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Rcapitulatif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Partitionnement adapt au dcisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Rcapitulatif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
SAVOIR Le sharding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

CHAPITRE 9
O trouver de laide ? ............................................................... 253
Trouver de laide en urgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Les ressources internes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Les ressources externes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Les moteurs de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Le support officiel MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Les organismes externes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Trouver de laide hors contexte durgence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Formations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
O poser votre question ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Lassociation LeMug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Les blogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Les forums et mailing-lists MySQL officiels . . . . . . . . . . . . . . . . . . . . . . . . . 257
Aller plus loin et enrichir ses connaissances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
La blogosphre de la communaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Les sminaires web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Outils et sources de MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
La confrence MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Les certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

1
Grer une situation durgence
avec MySQL
Problme majeur ou incident moins dramatique, lun comme lautre mritent la plus
haute attention. En effet, tous deux sont susceptibles dtre rsolus rapidement ou au
contraire dimpacter gravement la production. Voici nos conseils pour minimiser les
consquences de ces alas qui ponctuent la vie dune base de donnes.
Il serait illusoire de recenser ici lensemble des problmes et des solutions associes
que vous pourriez rencontrer sur un serveur MySQL. En revanche, il est possible de
lister quelques bonnes pratiques en fonction du temps dont vous disposez face un
incident en production. Inutile en effet de se lancer dans un audit pouss du systme
si vous navez que quelques minutes pour rtablir une situation compromise. Cependant, avec un peu plus de temps, une heure voire une journe, le mode opratoire diffre compltement. Il est alors possible de rechercher plus longuement les causes du
problme et dactiver si possible dautres ressources en interne ou en externe, par
exemple via du support. Bref, analyser le problme afin quil ne se reproduise plus.

chaque degr durgence sa panoplie doutils


Dix minutes, une heure et une journe sont les trois diffrents degrs durgence (arbitraires) que nous vous proposons dans ce chapitre. Cette distinction peut bien sr tre
discute, lide tant nanmoins de classer les problmes par ordre de priorit. bien y
rflchir, ces ordres de grandeur ne sont finalement pas si loigns de la ralit.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

MySQL 5 Audit et optimisation

Les incidents gravissimes (serveur MySQL qui ne redmarre pas, connexion la base
impossible sur un serveur en fonctionnement...) ncessitent une rponse immdiate
de votre part car ils ont une incidence directe sur la production. Un dlai de rsolution de 10 minutes est souhaitable mais laissera malgr tout des traces dans vos
tableaux de statistiques mesurant les temps de disponibilit de vos applications.
Lgrement moins urgents, les problmes que lon souhaite voir rgler dans lheure
ne sont pas prendre la lgre non plus. En effet, il peut sagir de difficults de
rplication, de droits absents ou incomplets pnalisant des utilisateurs ou des scripts,
de crash de tables, etc.
Enfin, les problmes de performance sont susceptibles dappartenir la catgorie
dincidents dont la rsolution, ou tout du moins le diagnostic, ainsi quun ventail de
solutions adaptes, relve de la journe.

Temps de rsolution : dix minutes


Bienvenue ceux qui savent grer leur temps ! Joueurs dchecs, un plus. Voici une
annonce qui sortirait srement du lot pour une entreprise souhaitant attirer dans ses
filets un administrateur de bases de donnes (DBA). En effet, tel un joueur dchecs
confront une partie ultrarapide (5 minutes), le DBA en situation de crise dispose
de trs peu de temps pour tenter de renverser la situation. En cela, dix minutes constituent la fois un laps de temps trs court lchelle dune journe, par exemple,
mais on peut galement considrer que cest amplement suffisant pour dtecter lorigine du problme. Nous parlons ici de dtection, pas encore de rsolution.

tape 0 : informez et communiquez !


Identifiez la ou les personnes auxquelles vous devez rfrer en cas de problme.
Celle-ci relayera le message si besoin. Linformatique est plus quune question de
technique : un accident grave sur les bases passe rarement inaperu et vous oblige
communiquer. Un incident, en particulier sil est majeur, sera mieux vcu si les utilisateurs concerns par cet incident sont mis au courant plutt que sils sont obligs de
contacter eux-mmes les services techniques pour tenter de comprendre pourquoi
leur application ne rpond plus. Prenez les devants et annoncez les consquences :
une rplication hors service implique au mieux un tat fig des donnes sur certaines
applications et au pire un arrt de certaines dentre elles, tout dpend de la robustesse
du code sous-jacent.
De plus, indiquer aux utilisateurs quil existe un problme leur permet dattendre
votre feu vert avant de renouveler leurs oprations plutt que de tenter des rafrachissements ou validations supplmentaires qui narrangent rien.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Grer une situation durgence avec MySQL


CHAPITRE 1

Si vous ne pouvez dores et dj annoncer un dlai de rtablissement, dites-le. Outre


le fait que les utilisateurs soient avertis au plus tt, communiquer en amont vous
permet galement de rester concentr en rduisant le nombre de personnes cherchant
se renseigner auprs de vous (tlphone, messagerie interne, de vive voix...).

Ne restez pas seul et discutez avec dautres administrateurs


En cas dextrme urgence, partager ses observations, avec un administrateur systme
par exemple, est une bonne chose. Si le DBA pense en termes de bases (rplication,
droits, tables corrompues), ladministrateur systme a souvent une vue complmentaire (place disque, rseau, connectivit aux disques, scripts programms) ; cest souvent lui qui a install, ou tout du moins particip linstallation, de la machine sur
laquelle le serveur MySQL sexcute. Ses connaissances purement techniques ajoutes la visibilit quil possde sur les machines utilises par votre dpartement en
font un alli de choix en cas de crise.

Consultez les informations systme : journal derreurs, activits disques et


processeur...
Lorsquune alerte critique lie la base de donnes est leve, une des premires
actions mener, si lon ne dispose que dinformations vagues du type systme
indisponible , est de consulter le journal derreurs de MySQL... condition de
pouvoir le faire bien sr. Si lun des disques systme nest plus accessible, lincident
bascule tout dun coup du ct des administrateurs systme. Vous tes seul et occupez
les deux fonctions ? changez votre casquette de DBA contre celle de ladministrateur systme le temps que le problme matriel et/ou systme soit rsolu.
Les journaux derreurs sont un passage absolument oblig lorsquun incident relatif
la base de donnes survient. Sa simple lecture peut faire gagner un temps prcieux !
Problme de rseau ou de rplication, arrt du serveur, table corrompue, syntaxe
incorrecte du fichier de configuration, impossibilit de dmarrer un moteur de stockage, etc., lventail couvert par le fichier derreurs est vaste et bien souvent explicite.
Si sa lecture ne vous a pas suffi, ou sil ny a aucune information pertinente lintrieur, ce qui arrive, quelques commandes systme basiques sont excuter :
Tout dabord df -kh pour sassurer quaucune de vos partitions nest pleine
100 % ; cela dit le log derreurs vous laurait signal.
iostat -dx 5 pour obtenir une vue sur lactivit des disques.
htop ou top permettent quant eux de reprer si vos processeurs, ou curs pour
tre plus prcis, sont mobiliss et dans quelle proportion.
Espace disque disponible, activit processeur et activit du systme disque sont quelques investigations qui doivent normalement contribuer vous clairer.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

MySQL 5 Audit et optimisation

ATTENTION Prcautions prendre avec une table MyISAM corrompue


Le matre mot est ici : sauvegardez ! En effet, la documentation le stipule elle-mme : il est possible que
les procdures de rparation entranent une perte de donnes :
B http://dev.mysql.com/doc/refman/5.1/en/repair-table.html
Si possible, veuillez donc sauvegarder les tables MyISAM concernes. En cas dimpossibilit de passer par
un outil tel que mysqldump ou mysqlhotcopy, copiez directement les fichiers .MYD, .MYI, et
.frm de la table concerne si le serveur est arrt. Si ce dernier est en marche, la commande FLUSH
TABLES WITH READ LOCK vous permet deffectuer lopration mais cela peut tre coteux en termes de performance.

Le plus important ici est de rcuprer le fichier qui contient la base .MYD. En effet, si
vous connaissez la dfinition de la table concerne, il sera possible de recrer un .frm
lui correspondant. Le fichier .MYI, quant lui, peut galement tre reconstruit :
REPAIR TABLE utilis avec loption USE_FRM repartira justement du .frm et les index
seront totalement crs nouveau.
Pensez galement aux logs binaires. Cette remarque est aussi valable pour un moteur
tel que InnoDB. Si la partition sur laquelle se trouvaient vos tables MyISAM est
perdue, rcuprez vos sauvegardes et les logs binaires, puis rinjectez le tout dans
MySQL et vous en serez quitte pour une bonne frayeur.
Attention toutefois exclure de vos logs binaires lventuelle instruction SQL dvastatrice responsable du carnage... ce sujet, reportez-vous au chapitre 8, consacr la
rplication.

Tentez de vous connecter la base


Au-del des outils systme, pouvez-vous vous connecter la base ? Pouvoir effectuer la
commande SHOW FULL PROCESSLIST est trs utile dans ce type de situation. Lorsque la
base est charge, il est efficace de passer par une ligne de commandes pour crire dans
un fichier texte le contenu de cette commande, exemple :
shell> mysql -uuser -ppassword -e "SHOW FULL PROCESSLIST;" > /tmp/sfp.txt

Il sera alors possible dditer facilement lensemble des requtes SQL et de les conserver pour tude, le cas chant, une fois la tempte passe.
Lutilisation de la commande SHOW FULL PROCESSLIST nest pas forcment chose
facile dans tous les cas : encore faut-il pouvoir se connecter !

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Grer une situation durgence avec MySQL


CHAPITRE 1

SAVOIR viter lempilement des requtes et dcrypter le SHOW PROCESSLIST


Chaque serveur MySQL possde une limite maximale de connexions simultanes. Celle-ci est dfinie par
la variable systme max_connections. Certains scripts ou applications ne ferment pas correctement
leur connexion MySQL une fois le rsultat de celle-ci exploit ; il en rsulte un empilement des connexions. Celles-ci arborent alors le statut sleep mais occupent malgr tout un emplacement qui ne sera
pas utilisable par dautres clients souhaitant se connecter, si la limite de max_connection est
atteinte. Pour viter cela, il est possible dajuster la variable wait_timeout. Sa valeur par dfaut est
de 8 heures, ce qui est norme. En rduisant cette valeur vous indiquerez au serveur MySQL une nouvelle
limite au-del de laquelle il coupera cette connexion si celle-ci est inactive.
Concernant les statuts des requtes issues dun SHOW PROCESSLIST (Sending data, Writing to net,
Copying to tmp table, etc.), si certains sont vocateurs, dautres le sont beaucoup moins. La documentation de MySQL en dresse une liste exhaustive :
B http://dev.mysql.com/doc/refman/5.1/en/general-thread-states.html
Cependant nous vous conseillons de consulter galement la liste, peut-tre plus lisible, de Domas Mituzas sur son blog :
B http://mituzas.lt/2009/09/27/mysql-processlist-phrase-book/
Les statuts y sont expliqus de faon beaucoup plus claire.

Si MySQL vous refuse la connexion en indiquant explicitement Too many connections, cest tout simplement que le nombre dfini par max_connections a t atteint.
Il reste une chance cependant : MySQL autorise bien max_connections seulement
se connecter simultanment, mais il existe une connexion supplmentaire, notamment en cas durgence.
Cette connexion nest disponible que pour des utilisateurs disposant du droit SUPER
ou lutilisateur root. Cet utilisateur avis pourra alors se connecter la base mme si
celle-ci a atteint son nombre maximal thorique de connexions. Rappelons quand
mme quil est dconseill de laisser une application se connecter la base sur le
compte root.
ASTUCE Dfilement page par page pour SHOW FULL PROCESSLIST
Lutilisation de la commande SHOW FULL PROCESSLIST sur un serveur charg provoque un dfilement illisible, car trop rapide, des nombreuses requtes excutes cet instant sur le serveur MySQL. Il
est possible de simuler le comportement du dfilement page par page (le | more sous Linux, par exemple) grce la commande suivante :
mysql> pager more;

Ainsi, cest vous qui ferez dfiler votre guise les requtes affiches par le SHOW
PROCESSLIST. Pour retrouver le comportement par dfaut du client MySQL, saisissez :

FULL

mysql> nopager;

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

MySQL 5 Audit et optimisation

En cas dchec de ce dernier recours, il ne vous reste plus qu redmarrer le serveur


MySQL pour rcuprer des connexions de libres afin de vous connecter. Si le flux de
connexions la base est tel que vous craignez que la situation ne se renouvelle aussitt une fois le serveur redmarr, sachez quil est possible de restreindre les connexions entrantes celles qui sont mises localement. Lajout de la commande bindaddress=127.0.0.1 dans le fichier de configuration my.cnf, permet ce type de limitation. skip-networking dsactive lcoute des connexions TCP/IP et nautorise que
les connexions via socket sous Unix.
REMARQUE Se rfrer aux chapitres concerns
Nous dtaillons le matriel au chapitre 2 et les logs MySQL au chapitre 5 ; cest pourquoi nous naborderons pas nouveau ici le fonctionnement du RAID ou du log derreurs, par exemple. Il en va de mme
pour dautres thmes voqus dans ce chapitre tels que la rplication ou la mise en place et lexploitation doutils de surveillance pour son systme.

Supprimer les requtes les plus lourdes


Que vous soyez ladministrateur des bases de donnes ou non, difficile de connatre
par cur lintgralit des utilisateurs MySQL en activit sur les diffrentes bases.
La dnomination des utilisateurs MySQL rend parfois difficile leur rle au sein du SI.
De plus, certains comptes utilisateurs sont susceptibles dtre utiliss par plusieurs projets qui nont pas forcment de liens. Il est du coup difficile de mesurer limportance
dune requte en la rapportant seulement au nom de lutilisateur MySQL qui lexcute.
En cas dextrme urgence, il est du devoir du DBA de sacrifier certaines requtes
hautement pnalisantes pour lensemble du serveur MySQL afin que le site Internet
reste disponible. Les internautes sont prservs au dtriment de scripts internes qui
devront alors tre rejous.
DANS LA VRAIE VIE
Dans un monde idal, ces deux types dactivits ne devraient pas sexcuter en mme temps ou en tout
cas pas sur le mme serveur, mais la ralit conomique lemporte parfois sur les rgles de scurit.

Aussi, possder une liste des utilisateurs dont lactivit est vitale pour lentreprise et
ne couper sous aucun prtexte (facturation, livraison...) vous permettra de trier le
moment venu. Fort de cette liste dintouchables, les requtes susceptibles dtre supprimes pour soulager le serveur seront plus facilement identifiables.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Grer une situation durgence avec MySQL


CHAPITRE 1

PRATIQUE Supprimer des requtes rapidement


En cas durgence, exploiter laffichage de la commande SHOW FULL PROCESSLIST en ligne de commandes via un terminal de type putty peut savrer dlicat. Si le serveur est charg votre terminal sera
submerg de requtes pour la plupart peu lisibles. Un outil tel que mytop permet notamment dafficher
les requtes par couleur afin de diffrencier leur temps dexcution. Il est galement possible, partir de
linterface de cet outil, de supprimer les requtes de votre choix en indiquant leur identifiant.
MySQL Administrator est une alternative ce type de script. Son interface graphique permet de naviguer
facilement sur lensemble des requtes excutes sur le serveur. Un tri par utilisateurs MySQL est possible, le nombre doccurrences du mme utilisateur est galement indiqu et un bouton permet de supprimer simplement la requte de votre choix ou toutes celles appartenant un utilisateur.
Si vous nutilisez pas MySQL Administrator, une alternative est de gnrer vous-mme le fichier des identifiants 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 gnre ainsi un fichier comportant une ligne par requte appartenant lutilisateur vis, comme :
KILL 272;
KILL 284;
[]

Il ne reste plus qu lexcuter :


mysql> source /tmp/req2del.txt;

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

noter : mme dtruite, une requte peut prendre un long moment avant de rendre la main. En effet, un
ROLLBACK dune grosse opration sous InnoDB peut tre trs long, il ny a pas de solution idale dans
ce cas l... Si vous redmarrez le serveur vous vous exposez une rcupration de crash dInnoDB qui
peut galement prendre un certain temps.
Autre solution extrme rserver de gros SELECT bloquants sous MyISAM, par exemple : rcuprer
lidentifiant du thread correspondant la connexion qui excute la requte et effectuer un kill -9.
vous de mesurer les consquences dune telle coupure ; avec MyISAM, il ny a pas de notions de transactions et la cohrence de la base est donc peut-tre compromise ce niveau.
Encore une fois, testez ces outils par vous-mme avant quune situation durgence ne se dclare. Nos
conseils sur la surveillance de vos serveurs occupent le chapitre 4.

Il suffit parfois de supprimer une requte pour dbloquer un empilement de connexions prjudiciable pour le serveur MySQL. Cest le cas si cette requte nest pas
optimise et gnre un trop grand nombre de verrous, crant ainsi une file dattente
importante. MyISAM et son verrouillage par table est plus impact quInnoDB mais
aucun de ces moteurs de stockage nest labri de tels phnomnes.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

MySQL 5 Audit et optimisation

viter que lauthentification des utilisateurs repose sur un DNS : lerreur


unauthenticated user
Difficile de supprimer toutes les requtes dun utilisateur particulier si mme MySQL
ne sait pas lidentifier... Ce type de message unauthenticated user est visible en cas
de serveur MySQL trs charg ou en proie un problme de DNS. Nous vous recommandons de ne pas les utiliser lorsque vous dfinissez un utilisateur MySQL.
Dfinition dun utilisateur MySQL bas sur un DNS
mysql> GRANT SELECT on *.* TO 'me_dns'@'dev.example.org' IDENTIFIED BY
'password';

Le mme exemple sans lutilisation de DNS


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

En cas de problme du serveur DNS, MySQL ne pourrait identifier le premier utilisateur 'me_dns', le qualifiant de unauthenticated user. Si vous rencontrez ce problme, il est probable que vous en veniez bout en effectuant ces deux actions :
bannir les DNS de la dfinition de vos utilisateurs ;
dmarrer le serveur avec loption --skip-name-resolve (nous vous conseillons
dactiver cette option).

Consulter son systme de surveillance


Une situation durgence ? Voici le bon moment pour capitaliser sur vos efforts prcdents et consulter vos logs ou graphiques dactivit lis la base.
Un graphique est souvent bien plus explicite que diffrentes mtriques analyser. De
plus, selon le degr dhistorisation que vous utilisez, il est srement possible de
remonter (pourquoi pas) lheure dorigine du problme. Cette dernire information
est cruciale pour incriminer un script programm dont les impacts ne sont pas forcment simultans avec son heure de lancement. Pensez par exemple au rsultat dune
jointure complexe qui serait stock par le langage de script afin de gnrer une boucle
de mises jour mal optimise, le tout sur une table trs volumineuse... Leffet diffr
est garanti et potentiellement dramatique.
Afin de dterminer si le problme rencontr sur le serveur provient dune requte
ponctuelle passe directement via un client MySQL en production (gestion des
droits revoir !) ou est issu dun script programm, un ordonnanceur permet didentifier rapidement quel script tourne quelle heure. Son utilisation est moins fastidieuse que le parcours des crontab mais encore faut-il en possder un. Une fois dter-

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Grer une situation durgence avec MySQL


CHAPITRE 1

mine lheure probable de lorigine du problme, comparez celle-ci avec celles


prsentes par lordonnanceur.
Figure 11

Possder un historique sur


lactivit des bases est dune
grande utilit, exemple avec
MySQL Enterprise Manager.

Tranche de vie dune campagne marketing improvise


Votre systme de surveillance est en alerte, les diodes rouges remplacent frntiquement leurs paisibles anctres de couleur verte bien plus rassurant. Pourquoi ? Les
tches programmes ne sont pas incrimines : les crontab ont t passes au peigne
fin. Les dveloppeurs vous jurent quils ny sont pour rien. Finalement, une fois la
tempte passe, quelquun a dclench le lancement dune campagne marketing
reposant sur des pop-ups dynamiques aux requtes non optimises. Outre le problme de communication entre les dpartements technique et marketing, lincident
rvle quun seul et mme utilisateur peut lui seul occuper 100 % des connexions
disponibles sur votre serveur MySQL.
Afin dempcher quun seul utilisateur consomme toutes les ressources, il est possible
dajouter certaines restrictions par heure cet utilisateur. Ainsi, le nombre de requtes, de mises jour ou de connexions, sont des limites quon peut fixer. De plus, le
nombre maximal de connexions simultanes pour un utilisateur est lui aussi configurable.
Restriction 200 connexions simultanes 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 user_pub@192.168.200.20: GRANT SELECT ON *.* TO
'user_pub'@'192.168.200.20' IDENTIFIED BY PASSWORD
'*1270C0C06DEE42FD1618BB99005ADCA2EC9D1E19'
WITH MAX_USER_CONNECTIONS 200

Une augmentation brutale du nombre de requtes peut provenir dun problme du


cache : soit celui-ci a t brutalement dsactiv ou invalid (query cache) soit votre
systme bas sur memcached est dfectueux.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

10

MySQL 5 Audit et optimisation

Temps de rsolution : une heure


Estimer que lon a au moins une heure devant soi signifie probablement que le problme ou ses consquences est en partie identifi. Cest souvent le cas dune surcharge soudaine sur le serveur MySQL. Attribue un script programm, il est possible de retrouver une situation normale en coupant le programme concern. Le but
est ici de ne pas couper brutalement le responsable mais plutt de loptimiser.
Si nous disposons dune heure pour rsoudre le problme, cela laisse le temps doptimiser une requte complexe et coteuse, de diffuser le correctif aux quipes concernes et dassister peut-tre une mise en production dans lheure si le problme survient en heures ouvrables.

La chasse aux requtes lentes


Dans lhypothse o notre problme soit issu dune ou plusieurs requtes trop coteuses, le but est tout dabord de les identifier rapidement puis de les analyser afin de
les optimiser. Si votre outil de surveillance prfr (MySQL Administrator, mytop,
etc.) est suffisant pour reprer les requtes les plus lourdes sexcutant en temps rel
sur le serveur, ils ne sont daucune utilit pour analyser le pass.
En effet, afin de retrouver les requtes qui ont pu impacter votre serveur et qui sont
dsormais peut-tre termines (mais appeles sexcuter de nouveau), des logs sont
ncessaires. MySQL possde un fichier de logs ddis aux requtes lentes : il sagit
du slow query log. Celui-ci peut par exemple tre exploit par mysqldumpslow ou
mysqlsla.
Ne recherchez pas uniquement les requtes les plus lentes mais galement les plus
frquentes. En effet, votre charge MySQL est susceptible de provenir dune grande
quantit de petites requtes napparaissant pas dans les logs de requtes lentes selon
le critre utilis le plus souvent : le temps dexcution. 100 000 requtes de
0,9 seconde chacune napparaissent pas si le long_query_time est dfini une
seconde ; pourtant, celles-ci sont peut-tre responsables dune surcharge serveur.
LIRE Un chapitre consacr ltude des journaux
Au sujet des logs, lire ou relire notre chapitre 5 consacr aux logs MySQL. Il est possible dagir sur la
faon dont le serveur MySQL gnre les journaux des erreurs, de requtes lentes ou gnraux.
Il est prcieux, tout particulirement en situation durgence, de connatre leur fonctionnement.

Rcrire les requtes trop coteuses


Une heure, cela laisse le temps dagir sur un nombre restreint de requtes un peu trop
gourmandes. Cependant le temps passe vite : certaines requtes ncessitent elles

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Grer une situation durgence avec MySQL


CHAPITRE 1

11

seules ce laps de temps pour amliorer les choses. Il est parfois difficile danalyser le
bien-fond fonctionnel dune requte complexe multipliant les jointures et les sousrequtes. Aussi, si cela est possible, proposez au dveloppeur de se joindre vous pour
une premire analyse de celles-ci. Les critres de jointures sont-ils toujours pertinents ?
Certains dveloppeurs sont capables de crer du code SQL complexe et valide mais cest
galement ladministrateur de bases de donnes de leur signaler le fonctionnement
interne de MySQL et dvoquer certaines faiblesses propres la branche 5.x : sousrequtes imbriques et/ou corrles aux requtes externes. Dsormais au courant de
nouvelles bonnes pratiques, le dveloppeur est susceptible de corriger lui-mme certaines des requtes remontes lors de votre recherche de requtes lentes, vous laissant
ainsi du temps disponible pour en corriger dautres. Une fois la correction du dveloppeur effectue, comparez les EXPLAIN avant et aprs et classez laffaire si tout va bien.
Nous attirons votre attention sur le fait que mettre en production une requte sans
passer par une phase de test conforme celle que vous effectuez dhabitude est une
source de rgression potentielle. Une situation urgente autorise certains raccourcis
susceptibles de vous sortir daffaire, mais il nest pas pour autant conseill doublier
toute prudence ; ayez au moins lesprit le risque li cette pratique.
Nos conseils pour optimiser vos requtes se situent dans le chapitre 6, consacr
loptimisation de la base de donnes.
ASTUCE Les tables statiques la rescousse
Si vous estimez quil est impossible en une heure de venir bout de toutes les requtes corriger, pensez
aux tables statiques ou summarized tables. Cela ne fonctionne pas dans tous les cas mais cette technique est trs efficace si elle convient. Lide est de gnrer une fois pour toutes les rsultats dune requte
complte et de les insrer dans une autre table. Plutt que dexcuter n fois une requte complexe et
lente, elle est joue une seule fois et ses rsultats archivs. Linconvnient, bien sr, est que le contenu de
la table statique ne sera pas mis jour. vous donc de dfinir ventuellement la priodicit de cette opration (vidage de la table et nouvelles insertions partir de la requte complexe), un script programm
(cron) peut sen charger. Il est galement possible dutiliser les event au sein mme de MySQL, vous
en trouverez une description sur lun de nos blogs :
B http://dasini.net/blog/2009/06/16/
Cette technique a un sens lorsquune requte ne peut tre mise en cache trs longtemps (rsultats invalids par MySQL si par exemple lune des tables impliques par la requte est mise jour). Il est galement ncessaire que cette fameuse requte complexe ne soit pas contextuelle la session dun internaute. Dans ce dernier cas, les tables temporaires peuvent constituer une bonne solution condition que
leur taille maximale ne soit pas un problme (il sagit de la plus petite valeur entre ces deux variables
systme : max_heap_table_size et tmp_table_size). Dans ce cas la mise en cache dans une
table statique naurait pas de sens, le contenu doit servir au plus grand nombre. Il peut donc sagir dun
contenu dynamique dont on peut se permettre une frquence de rafrachissement infrieure au temps
rel. Un exemple : statistiques et calculs autour des points dun championnat quelconque. Les rsultats
ne seront pas obsoltes avant la prochaine preuve.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

12

MySQL 5 Audit et optimisation

Les problmes de rplication


Le chapitre 8, consacr la rplication, dtaille les mcanismes, la configuration et
les commandes ncessaires pour grer la rplication MySQL. Il est important que
son fonctionnement soit bien compris.
En consquence, nous nexpliquerons pas ici nouveau les arcanes de la rplication.
En revanche, le conseil retenir dans le cadre dune situation durgence concernant
une rplication est de ne pas agir la lgre. En effet, en cas derreur de votre part,
par exemple lors du redmarrage dune rplication arrte, vous pouvez rendre
lesclave inutilisable avec pour seule issue de recharger compltement les donnes
quil contient. Limportance dun tel incident (esclave hors service) est inversement
proportionnelle au nombre desclaves possds. Cest une situation dramatique si
vous nen possdez quun seul (faire pointer les applications vers le matre si celui-ci
tient la charge...) mais moins grave si vous en possdez un grand nombre. Lincident
pourrait passer inaperu si votre systme est correctement dimensionn avec une
bonne rpartition de charge.
Les messages derreurs lis la rplication sont assez varis. Ne pas comprendre lorigine du problme vous expose de graves difficults. Il serait inconsidr dappliquer
la lgre le fameux SET GLOBAL sql_slave_skip_counter=1 indiquant lesclave
de passer outre le problme qui a gnr lerreur et de sauter linstruction suivante
du relay-log. Le risque de dsynchronisation entre lesclave et le matre serait alors
important et dautres erreurs analogues ne manqueraient pas de se produire plus ou
moins courte chance.
Pire encore, ignorer systmatiquement un certain type derreurs (slave-skip-errors)
sans matriser rellement les consquences de ce rglage, est une grosse erreur.
Selon le type de moteur de stockage que vous utilisez (MyISAM ou InnoDB), et le
type de rplication (row based ou statement based) une requte stoppe manuellement sur le matre peut avoir des consquences diffrentes sur lesclave. Avec
MyISAM et en mode statement based, par exemple, une requte interrompue sur le
matre provoque :
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;

Lesclave dtecte que la requte a t interrompue sur le matre (cette information circule dans le log binaire) et dcide de stopper lui aussi la rplication. vous de vrifier
que la ou les tables concernes sur le matre et lesclave sont bien symtriques : il ny a

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Grer une situation durgence avec MySQL


CHAPITRE 1

13

pas de ROLLBACK sur MyISAM. Si cest le cas, vous pouvez alors utiliser le conseil prodigu par le message derreur SET GLOBAL... et redmarrer la rplication.
La rplication MySQL est asynchrone : une information enregistre sur le matre
nest pas immdiatement disponible pour linstruction suivante sur tous les esclaves.
En consquence, certaines applications ou scripts rencontrent des problmes. Cest le
cas typique cit prcdemment : une insertion est joue sur le matre et le script
recherche immdiatement son identifiant correspondant sur lesclave ; sil ne le
trouve pas, son comportement peut sen trouver perturb.
Une faon simple de grer ce souci est deffectuer les requtes de ce type (rcupration dune cl lie linsertion dun enregistrement) sur le matre.

Temps de rsolution : une journe


lchelle de la journe nous sommes pour ainsi dire sortis de lurgence. La survie de la
base nest plus une question de minutes mais plutt de jours. Cependant, le scnario
que nous suivons (rappelez-vous du dcoupage arbitraire en trois parties) implique que
la situation est proccupante et demande des restructurations parfois importantes.
Une journe ne reprsente que quelques heures durant lesquelles il va falloir trouver
des solutions. ce stade le problme est en effet dtect et il sagit probablement des
prmisses dune monte en charge difficile. Peut-tre rencontrez-vous de faon
rcurrente des ralentissements horaires rguliers, des requtes de plus en plus
lentes, des tables sur lesquelles il est difficile deffectuer des oprations de maintenance sans bloquer la production.
LIRE Chapitre 8 consacr la rplication
Les indisponibilits de la base lies aux changements de structures ALTER, DROP, ou de versions peuvent tre rsolus en partie grce la rplication.

Bref, il est temps de prendre le problme bras-le-corps et dy consacrer du temps


lavenir puisque cest finalement cela dont il sagit : anticiper les problmes de
demain.
Face des problmatiques dune telle envergure, les rponses techniques ne sont pas
forcment immdiates, tout du moins pas applicables en pleine journe. Certaines
phases sont en effet bloquantes : modification de tables (ALTER TABLE), refonte dune
partie de lapplication (phase de mise en production), remaniement des crons... tout
cela mrite quelques tests. Cependant si une opration coup de poing est dcrte sur
un thme prcis, comme rsoudre les problmes rcurrents de performance du serveur xxx, il sagit dagir vite et bien. Toutes les difficults ne seront probablement pas

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

14

MySQL 5 Audit et optimisation

rgles le soir mme mais les solutions appliquer et les premiers correctifs sont
applicables pour le lendemain (les premiers scripts correctifs sont susceptibles de
sexcuter pendant la nuit si votre activit sy prte).
PRATIQUE Un problme peut en cacher un autre
Sur une telle opration, il est souhaitable dimpliquer les utilisateurs concerns par les modifications de
base. Il est frquent quen discutant dun problme de performance les utilisateurs fassent part au DBA
quils ont par ailleurs des retours de blocage intermittents diffrents horaires, des pertes de connexion
(MySQL Server has gone away), etc. Plutt que deffectuer plusieurs runions pour diffrents
problmes sur un mme serveur, autant tous les voquer au moins une fois et tenter de les rsoudre en
mme temps, si possible. Un passage en InnoDB peut rsoudre les problmes de verrous voqus par les
utilisateurs ; un index contribuera acclrer certaines requtes ainsi que le partitionnement dune table
volumineuse. De plus, si la runion nest pas purement oriente bases de donnes, un administrateur systme ou rseau sera le bienvenu pour rgler certains problmes de connexion ou de perte de paquets,
constats ventuellement sur certaines machines.

Afin de dessiner une solution face une monte en charge avre ou venir, un passage par le chapitre 4, consacr la surveillance de votre serveur, est tout indiqu. En
fonction des conclusions de cet audit, il sera possible dmettre un planning et de
classer les actions effectuer par priorit ou faisabilit.
Voici un chancier tel que ladministrateur de bases de donnes pourrait lcrire
lissue dune telle runion :
lundi :
mise jour matrielle ncessaire (+8 Go RAM et 2 quad-curs, attente des
composants) ;
optimisation des requtes facturation ;
partitionnement de la table factures sur l'environnement de
dveloppement ;
benchmarks de la version partitionne (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.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Grer une situation durgence avec MySQL


CHAPITRE 1

15

Conseils gnraux face lurgence


Tirer profit du pass
Documenter les commandes ou procdures cls appliquer en cas de problme au
travers dun wiki, dun fichier texte, etc., permet le jour J, quelle que soit lheure,
dtre oprationnel. Pensez votre tat de fracheur si lon vous rveille lors dune
astreinte 3h du matin... Ne pas perdre de temps se rappeler comment teindre ou
rallumer certains services importants en plus des procdures lies lactivit MySQL
nest pas ngligeable dans pareilles situations.
Si ce nest pour vous, faites-le pour les personnes susceptibles de prendre le relais en
votre absence. Ce document doit tre enrichi rgulirement, au fil des problmes
rencontrs, des changements de serveurs, de DNS, etc.

Anticiper les problmes


Cest vident mais tellement vrai : mieux vaut prvenir que gurir. Lorsque les problmes surviennent il est parfois dj trop tard. Outre les urgences quotidiennes,
ladministrateur de bases de donnes doit veiller se mnager du temps, chaque jour
dans lidal, pour amliorer lexistant, effectuer quelques oprations de maintenance
(OPTIMIZE TABLE, ANALYZE TABLE, CHECK TABLE ou sa version client bien pratique
mysqlcheck), reprer les tables volumineuses susceptibles de poser problme (partitionnement ncessaire ?), suivre de prs les serveurs du moment, ceux dont lactivit
est particulirement forte ou importante un instant prcis.
ATTENTION Modifications chaud, en production
Soyez extrmement vigilant lgard des modifications qui sont susceptibles dtre excutes chaud
sur les machines de production. Certaines variables systme sont en effet modifiables sans redmarrage
du serveur MySQL. Il est important den mesurer tous les impacts possibles en termes de performance et
de stabilit du systme. Il est possible de mettre un serveur plat en modifiant une seule ligne dans un
fichier de configuration my.cnf ; par exemple, passer sync_binlog de 0 1 peut entraner une
chute dramatique des performances de tout le systme disque (au sujet de cette variable, lire galement
le chapitre 8, consacr la rplication, et le 2, ddi au matriel). De manire gnrale, il faut reporter
dans le fichier de configuration de MySQL toute modification effectue (et valide) chaud. Sans cela,
cette nouvelle valeur serait perdue au prochain redmarrage du serveur.
Quelques bonnes pratiques pour terminer :
1. archivez dans un document toute modification effectue ainsi, afin quen cas de problme vous puissiez 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 effectues. Lquipe dastreinte ou les administrateurs systme pourront ainsi ventuellement mettre en relation un problme et votre modification,
acclrant la rsolution du cas.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

16

MySQL 5 Audit et optimisation

Lentranement lurgence
Il ne suffit pas dinstaller un matre et deux esclaves pour se croire labri de tout
problme... Que se passe-t-il en cas de perte du master ? Dans un autre registre, les
sauvegardes sont-elles fiables ? On lit souvent quil faut tester ses sauvegardes, cest-dire les recharger sur un serveur et sassurer que les donnes soient bien prsentes
et correctes ; mais combien dentre nous leffectuons rellement ? Si cela devait se
produire en production, en combien de temps seriez-vous capable de tout remonter ?
Ces types de scnarios catastrophes se produiront un jour ou lautre et il faut y tre
prpar. Si les machines vous manquent pour tester tout cela, il est possible dutiliser
des solutions telles que MySQL Sandbox pour se construire une configuration analogue celle de la production moindre cot. Autre test intressant effectuer sur
des serveurs de test : dbrancher physiquement le courant et rallumer le tout. O en
est la rplication ? Des tables sont-elles corrompues ? En combien de temps le serveur MySQL redmarre-t-il ? Difficile de le deviner : il faut tester. Lutilisation de
machines virtuelles permet galement de se constituer un parc de machines avec lesquelles sentraner.

Enregistrer les donnes de lincident


Quel que soit le degr durgence dans lequel vous vous trouvez, des fins immdiates
ou pour plus tard, tentez de sauvegarder des informations concernant ltat du serveur au moment de lincident. Le chapitre 4, consacr aux solutions de surveillance,
est un bon point dentre.
En quelques mots, archiver les rsultats de commandes systmes telles que :
iostat -dx 5
vmstat 1 10
top -b -n 1
cat /proc/meminfo

et du ct de MySQL (si cela est possible) :


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

Ltat desprit adopter dans lurgence


Terminons ce chapitre sur quelques rgles lmentaires en cas de coup dur.
Ne paniquez pas, restez concentr.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Grer une situation durgence avec MySQL


CHAPITRE 1

17

Tentez de mesurer rapidement limpact du problme sur le reste du systme/des

applications.
Attention aux conclusions htives.
Soyez mthodique.
Connatre le fonctionnement des applications est un plus. Sans autres ressources
humaines que vous (en pleine nuit par exemple), vous pourrez agir sur certains
scripts ou identifier plus rapidement la source du problme.
Dans lurgence, allez au plus simple.
Si possible, effectuez une sauvegarde de ce que vous manipulez, un service
dgrad vaut mieux que pas de service du tout.

Trouver de laide
Vous tes dpass par le problme ? Cela arrive. Dans lintrt de tous, ne restez pas seul tenter de
rsoudre laffaire si vous ny arrivez pas et navez aucune piste. Si aucune aide nest disponible en interne
et que vous tournez en rond, il est temps de solliciter une aide extrieure. Lisez le chapitre 8 consacr
ce sujet. Il existe des services de support joignables par Internet ou par tlphone.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

2
Choisir son serveur MySQL

Investissement initial ou mise jour matrielle, le choix des composants dun serveur
MySQL est une tape cruciale. Tout composant doit tre choisi avec soin, tant le
systme disques, que la mmoire, ou le processeur.
Regrouper les meilleurs composants du march dans chaque domaine (disque,
mmoire, processeur), en plus dtre une dmarche trs onreuse, ne suffit pas
sassurer que lon atteindra les performances souhaites. En effet, le serveur MySQL
lui-mme et les moteurs de stockage dont il dispose, ont leurs points forts mais galement leurs points faibles. Si PBXT rime avec SSD (ce moteur inclut des mcanismes ddis ce type de support), InnoDB est trs sensible la prsence dun contrleur RAID BBWC (Battery-Back Write Cache)...
La configuration idale correspondant tous les besoins nexiste pas ; il est en
revanche ncessaire de choisir son matriel en fonction du but recherch.
Peut-tre avez-vous identifi le dual core comme le goulet dtranglement principal de votre application ?
Passer 8 curs, est-ce une bonne ide ?
linverse, vous saturez peut-tre en I/O disque et la technologie RAID vous
semble intressante ? RAID 0, 1, 5 ou 10 ?
Quid de la mmoire ?

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

20

MySQL 5 Audit et optimisation

Ce chapitre vous prsente les critres que vous devez connatre lors dune mise jour
matrielle ou lorsque le choix dun nouveau serveur MySQL se pose.

La mise jour matrielle, une tape ncessaire ?


Il peut paratre tonnant de se poser la question au dbut dun chapitre consacr au
matriel et pourtant...
Avez-vous clairement identifi la mise jour matrielle prvue, achats de nouveaux
serveurs ou mise jour des machines existantes, comme la solution vos problmes
ventuels ? Sagit-il dabsorber un pic de charge ou de rpondre un problme rcurrent, comme une saturation des disques ?
Vous tes peut-tre dj conscient que la configuration actuelle de votre serveur
MySQL nest pas optimale mais vous navez tout simplement pas le temps dauditer
vos centaines de tables pour optimiser les choses.
Quelles que soient les raisons lorigine dune mise jour matrielle prochaine ou simplement envisage, nous vous conseillons de parcourir les quelques rappels ci-dessous
avant de remplir vos bons de commandes. Obtenir une remise sur le prix catalogue est
chose courante mais nest pas une raison suffisante pour foncer tte baisse...

Les questions se poser


Interrogez-vous sur les raisons qui vous font envisager une mise jour matrielle.
Commenons par les goulets dtranglements actuels : sont-ils identifis ? Ce sont
eux qui vous guideront vers le type de composants amliorer ou renouveler (systme
disques, RAM, processeur, carte contrleur RAID...).
ASTUCE Identifier les goulets dtranglements
Pour identifier les goulets dtranglement, vous pouvez consulter le chapitre consacr la surveillance de
votre serveur MySQL ainsi que celui traitant des logs MySQL.

Par ailleurs, avez-vous effectu ne serait-ce quun rapide audit sur les bases concernes par cette mise jour ? Dans ce cadre, des index efficacement poss sur les tables
peuvent gnrer, dans certains cas, des gains normes en temps de traitement.
Gagnez du temps en parcourant le slow queries log et analysez dans la foule les plans
dexcution de vos requtes les plus coteuses. Si cela ne suffit pas, prenez le temps
de revoir vos schmas.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

21

Optimisez vos efforts sur les index en identifiant les tables les plus volumineuses et
assurez-vous que les champs qui les composent soient correctement ajusts (gain en
mmoire vive, en place disque) ; vous faciliterez ainsi le travail du serveur MySQL.
Voici deux requtes qui peuvent vous y aider.
Obtenir la taille en Mo des tables les plus importantes
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. row
table_name: t
table_schema: test
totsize: 325.70312500
*************************** 2. row
table_name: SAV
table_schema: test
totsize: 93.60937500

La commande PROCEDURE ANALYSE fournit des statistiques sur lutilisation des champs de vos tables
mysql> SELECT ref_code FROM clients PROCEDURE ANALYSE(10, 2000)\G
*************************** 13. row ***************************
Field_name: test.clients.ref_code
Min_value: 6175
Max_value: 6664
Min_length: 4
Max_length: 4
Empties_or_zeros: 0
Nulls: 30
Avg_value_or_avg_length: 6442.5226
Std: 6075.9587
Optimal_fieldtype: SMALLINT(4) UNSIGNED

Les tches programmes constituent une autre source potentielle dennuis analyser.
Si des points bloquants apparaissent quotidiennement horaires fixes, avez-vous
tent de rsoudre les verrous potentiels en dcalant dventuels traitements
automatiques ? Vrifiez si ces tches ne sont pas en concurrence avec dautres traitements lourds sexcutant en mme temps (enregistrez par exemple le rsultat dun
SHOW FULL PROCESSLIST toutes les minutes). Mfiez-vous des sauvegardes et des verrous quelles posent.
ASTUCE Optimiser son serveur
Avez-vous lu le chapitre consacr loptimisation de la configuration du serveur MySQL ?

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

22

MySQL 5 Audit et optimisation

Si les prcdents conseils sont dj appliqus, ne capitulez pas pour autant : examinez le partitionnement des plus grosses tables et la rplication.
Enfin, si vous navez pas suffisamment de ressources en interne pour effectuer ce travail daudit ou doptimisation, songez confier cette tche un consultant externe
qui valuera la pertinence de la future mise jour matrielle. Selon ltendue de votre
systme dinformation, cet audit peut savrer bien meilleur march que dimportants
achats matriels. De plus, il est probable que ce point de vue extrieur sur votre
architecture vous procure des conseils ou pistes supplmentaires que vous naviez pas
forcment envisags.
JARGON Scaling up, scaling out et scaling back
Scaling up se dit dune mise jour matrielle verticale : on remplace certains composants dun serveur pour tirer les performances vers le haut. La machine concerne reoit un meilleur processeur, davantage de mmoire, de meilleurs disques...
Le terme scaling out semploie lorsquon augmente les capacits de son systme en ajoutant une
machine. Cest le cas dune architecture de rplication laquelle on ajoute un serveur esclave identique
ceux dj existants ; la charge est alors rpartie sur davantage de machines sans toucher aux spcifications des prcdentes.
Enfin, scaling back est un terme que lon rencontre un peu plus rarement mais que nous devrions tous
pourtant appliquer plus souvent. Il sagit darchiver, dextraire des tables les donnes devenues inutiles
pour les oprations courantes. Il peut sagir soit de purges, on supprime alors certains enregistrements
devenus inutiles, soit dun transfert vers une autre table disposant pourquoi pas dun autre moteur de
stockage, comme ARCHIVE.
Cette bonne pratique permet de ne conserver que les donnes utiles pour les travaux en cours et contribue conserver des temps de traitements acceptables (ordres DDL et DML plus rapides, sauvegardes
moins pnalisantes, verrous plus courts...).

Du 64 bits oui... mais partout !


Que ce soit pour lamlioration dun serveur existant (scaling up) ou lachat dune
toute nouvelle machine, surtout prenez garde respecter une homognit en
64 bits. Du processeur au systme dexploitation en passant bien sr par lutilisation
dune distribution 64 bits, le serveur MySQL ne profitera pleinement des bienfaits
de la technologie 64 bits que si cette chane est respecte.
Les processeurs x86 fonctionnent avec 64 bits depuis plusieurs annes : le risque est
donc faible du ct des processeurs. Mfiez-vous cependant des systmes dexploitation, particulirement si vous ne les installez pas en personne. Certains hbergeurs
non spcialiss en solutions MySQL sont susceptibles dinstaller un systme
dexploitation 32 bits classique afin de faciliter, par exemple, linstallation de bibliothques ou scripts posant problme sur 64 bits.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

23

Limites des systmes 32 bits


Installer 16 Go sur une machine sur laquelle est install un OS 32 bits dans lespoir
de soulager votre serveur MySQL est une dmarche voue lchec. Le serveur
MySQL repose en effet sur un processus (mysqld) dont la limite dadressage
mmoire thorique sur un OS 32 bits est de 4 Go. En ralit cette limite varie entre
1,5 Go et 3 Go environ. Le surplus de mmoire disponible ne pourra tre utilis par
le processus mysqld.
Sur un systme 32 bits, plus encore quen 64 bits, il est important de conserver une
valeur raisonnable pour la variable max_connections afin de ne pas autoriser plus de
connexions simultanes que ne peut en grer votre serveur. En effet, chaque connexion au serveur MySQL se traduit par la cration dun thread auquel est associe
une quantit de mmoire.
ATTENTION Ne soyez pas trop gourmands !
Nattribuez pas non plus de valeurs trop importantes aux variables dont la taille mmoire maximale ne sera
consomme quen cas de besoin par chaque thread. Par exemple, la variable sort_buffer_size a
pour valeur 2 Mo par dfaut ; si vous la passez 8 Mo, cela reprsente 6 Mo potentiels de plus par connexion... Avec une valeur de max_connections 400, par exemple, limpact dune telle modification
induit 2,4 Go de mmoire consomme supplmentaire ! Il faudrait cependant que les 400 connexions
soient actives et effectuent un tri, ce qui rduit lventualit dun tel vnement.

En cas de rglages un peu trop ambitieux, MySQL, tout particulirement sous


Solaris, se rappellera peut-tre vous un peu brusquement ; Linux est un peu moins
strict. Sous Solaris, quantit de mmoire gale et en utilisant le mme fichier de
configuration my.cnf, le serveur MySQL peut refuser de dmarrer sil estime que les
rglages sont trop optimistes en terme de consommation mmoire. Un message
derreur plutt explicite apparat dans ce cas (ici, un exemple sous Solaris sur une
machine dote de 32 Go de mmoire) :
Manque de mmoire au dmarrage dun serveur sous Solaris
090922 12:41:38 InnoDB: Error: cannot allocate 2039978216 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 17660053448 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

24

MySQL 5 Audit et optimisation

090922 12:43:51 InnoDB: We now intentionally generate a seg fault so that


InnoDB: 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 binary
or 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 diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=4294967296
read_buffer_size=2097152
max_used_connections=0
max_threads=151%)
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6979054
Kbytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Le message derreur MySQL propose de calculer la somme maximale de mmoire


alloue par les threads si tous taient connects en mme temps en utilisant la fois
des tris et des recherches squentielles. Se rajoute cela le buffer key_buffer_size
(espace allou aux index pour MyISAM uniquement) qui lui est global, donc indpendant du nombre de threads connects.
Concernant key_buffer_size, la documentation stipule justement la diffrence dallocation possible entre un systme 32 bits et un autre en 64 bits, autre preuve de lintrt
de possder un systme 64 bits permettant de saffranchir de certaines limites.
En conclusion, si vous disposez dun matriel 64 bits, veillez ce que le systme
dexploitation soit galement une version en 64 bits. Cela vous permettra dallouer
plus de 3 Go au processus mysqld et de limiter lventualit dun arrt de MySQL en
cas de problme dadressage.
Relisez le chapitre concernant les outils de surveillance : il fournit une liste dutilitaires permettant de visualiser rapidement les caractristiques dun systme.
RESSOURCES EN LIGNE Davantage de dtails sur ladressage mmoire
Vous trouverez des informations sur ladressage mmoire dans la documentation elle-mme mais galement dans un excellent billet de Mark Robson :
B http://dev.mysql.com/doc/refman/5.0/en/memory-use.html
B http://marksverbiage.blogspot.com/2008/01/mysql-address-space.html

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

25

Choisir ses processeurs


tat des lieux
Chez les fondeurs, la multiplication des curs (ou cores) au sein des processeurs a le
vent en poupe. Sans pour autant ngliger laugmentation de la frquence de leurs
puces, les fabricants vantent de plus en plus les mrites de leurs solutions multicurs
en soulignant lventail des possibilits offertes par la paralllisation.
En ralit, si le systme dexploitation nest pas adapt, ou bien si lapplication ellemme na pas t conue totalement pour ce type darchitecture, la hausse de performance nest hlas pas proportionnelle au nombre de curs.
MySQL nchappe pas ces problmes de monte en charge. Par le pass plusieurs
benchmarks ont prouv quune perte de performance tait possible avec 8 curs
plutt que 4.
Sils ne sont pas totalement rsolus aujourdhui, ces problmes tendent cependant
sestomper grce la communaut. Celle-ci sorganise et publie des rsultats encourageants dans plusieurs domaines.

Les solutions face aux problmes de monte en charge


La dmocratisation des systmes bass sur des architectures multicurs et lutilisation massive dInnoDB a mis en vidence des problmes de monte en charge avec ce
moteur. Depuis quelques annes, blogs, confrences et benchmarks se sont succds
et ont prouv, graphiques lappui, que le passage de 4 8 curs napportait quune
faible valeur ajoute voire des pertes de performance.
JARGON Architecture SMP vs NUMA
Une architecture SMP (Symmetric multiprocessing) dsigne un ensemble de processeurs (ou curs) qui
partagent le mme bus mmoire ; cest le cas de la plupart des systmes multicurs aujourdhui.
Les curs se partageant le mme espace mmoire, la rpartition des tches est cense tre facilite si le
systme dexploitation est tudi pour. Vous retrouverez le terme SMP dans les correctifs Google pour
MySQL, comme dans Patch to improve SMP performance au sein des google-mysql-tools :
B http://code.google.com/p/google-mysql-tools/wiki/Mysql5Patches
On parle darchitecture NUMA (Non-Uniform Memory Access) lorsque chaque cur/processeur dispose
de sa propre mmoire en local. Celle-ci sera exploite plus rapidement quune mmoire distante (cas du
SMP) ; cependant la rpartition de charge entre les processeurs est plus coteuse.
B Plus de dtails sur Wikipedia : http://en.wikipedia.org/wiki/Symmetric_multiprocessing

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

26

MySQL 5 Audit et optimisation

Les coupables ont depuis t identifis. De multiples mutex (reportez-vous au


chapitre 4 Surveiller son moteur MySQL pour une dfinition), ces verrous logiciels, zones de contention ncessaires au sein du code pour empcher plusieurs
threads daccder simultanment des structures internes partages, posent problme. Ces mutex sont prsents sur le adaptive hash index ou encore sur le transaction
log... InnoDB souffre dun problme qui remonte au temps o les serveurs taient
mono-processeur et dots dun seul disque. La situation est videmment bien diffrente aujourdhui : 4, 8, 16 ou 32 curs rattachs plusieurs dizaines de disques ne
sont plus des cas isols, sans parler de la quantit de mmoire disponible de nos jours
sur un serveur MySQL : 8 Go, 16 Go, 32 Go, sont des valeurs courantes.
Depuis 2007 environ, la communaut a acclr la cadence et sest attaque ces problmes. Google, qui utilise massivement MySQL, a tir la premire avec mysql-tools ;
le correctif v1 fut dailleurs publi cette priode. Les correctifs de Google ne concernent pas uniquement les problmes de monte en charge sur les systmes multicurs
mais enrichissent galement dautres fonctionnalits de MySQL, telle la rplication.
Aujourdhui, Google continue publier des correctifs. Le dernier, le v3, date de mi2009. Dautres acteurs majeurs de la scne MySQL se sont joints ces efforts afin de
rendre MySQL toujours plus rapide. Il est intressant de noter que malgr la comptition sous-jacente entre ces acteurs (Percona, ProvenScaling, MySQL, InnoDB...),
les efforts ne sont pas cloisonns et la communication entre ces groupes existe.
On retrouve ainsi certaines innovations de Percona dans le dernier plug-in
dInnoDB. De son ct, Google sinspire galement des meilleures pratiques disponibles quelles soient issues de recherches internes ou externes partir dides de Percona ou ProvenScaling, par exemple.
REMARQUE La comptition omniprsente entre les diffrents acteurs
Les quipes ddies la performance chez MySQL ont elles aussi effectu un gros travail. La publication
de la version 5.4 lors de la dernire confrence annuelle MySQL Santa Clara mi-avril 2009, au moment
mme du rachat de Sun par Oracle, en est la preuve. Cette version, toujours en bta lheure o nous
crivons ces lignes, est rsolument tourne vers les performances, la monte en charge et une meilleure
exploitation des systmes multicurs.
Dans le mme temps Percona publiait XtraDB un moteur driv dInnoDB avec des patches propritaires
destins comme toujours amliorer les performances.
Les fruits de ces efforts, disponibles gratuitement pour qui installe ces versions amliores, contribuent
augmenter la visibilit de leurs auteurs et ont donc une influence indirecte sur leur chiffre daffaires. Percona renforce ainsi son rayonnement en tant quexpert et consultant MySQL grce leur fameux blog ou
par le biais de leurs patches. Mais MySQL nest pas en reste non plus puisqueux-mmes proposent diffrentes formes de consulting.
B http://www.mysqlperformanceblog.com

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

27

lire galement
Retrouvez davantage dinformations ce sujet dans le chapitre 8 O trouver de laide ?

Enfin, des socits telles que Yahoo!, Craigslist, Facebook, Google... font parler
delles et de leur matrise des dernires avances technologiques en publiant amliorations et patches ou en permettant leurs experts internes de donner des confrences sur des sujets pointus.

Choisir son processeur : les critres de choix


Quelle est lutilisation actuelle de vos processeurs ?
Le premier rflexe est didentifier vos goulets dtranglement (consultez le chapitre 4
Surveiller son serveur MySQL ce sujet) afin de dterminer dans quelle mesure
une mise jour de vos processeurs peut vous aider. Si ces derniers sont inactifs la plupart du temps, rajouter un quadricur votre systme ne servira pas grand-chose...
Cependant, si vous avez la chance de disposer de lintgralit de vos donnes en
mmoire, votre systme est alors plus susceptible de connatre un goulet dtranglement d au processeur (CPU bond). Il en va de mme si ce sont vos disques qui fournissent au processeur les donnes dont il a besoin suffisamment rapidement ; ce
pourrait tre le cas dun parcours squentiel total (full scan) o chaque enregistrement
serait lobjet dun traitement mathmatique ou statistique important.
SAVOIR MySQL et la gestion des threads
Pour MySQL une requte provient dun thread et est attribue un cur. Deux curs ou plus ne peuvent
pas mettre en commun leur puissance respective pour rsoudre une requte issue dun seul thread. En
revanche, sur un quadricur, par exemple, un traitement qui ne ncessite pas de srialisation particulire
et dont les actions concernent diffrentes tables si vous utilisez MyISAM, peut tre dcoup en quatre, et
lanc en autant dinstances diffrentes. Cette astuce est envisageable pour optimiser lutilisation de processeurs multicurs. Attention aux points de contention potentiels avec MyISAM : verrouillage total
dune table si un UPDATE est effectu, contention sur le key_buffer_size global toutes les
tables (en revanche pas de problme sur un parcours squentiel total). De manire gnrale, prfrez
InnoDB et son design tourn vers la concurrence (verrouillage par ligne notamment) plutt que MyISAM
si vous traitez des requtes mixtes de lecture et dcriture.

Utilisez les utilitaires top et htop afin de dtecter la faon dont se comportent les
curs du processeur. Une charge bien rpartie entre les diffrents curs est un bon
signe ; si au contraire vous observez constamment une utilisation maximale de 50 %
sur un bicur ou 25 % sur un quadricur, il est fort probable que vous nutilisiez

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

28

MySQL 5 Audit et optimisation

quun cur sur les deux ou quatre dont vous disposez ! Si cette sous-exploitation du
matriel pose un problme de performance, plutt que dacheter de nouveaux curs,
tentez plutt de diviser le traitement en deux ou quatre instances afin de maximiser
lutilisation des processeurs dont vous disposez.
Lorsquun tel dcoupage de votre programme ou script nest pas possible ou bien
quil ne porte pas ses fruits du fait des problmes voqus ci-dessus, il est probablement plus judicieux dchanger un quadricur utilis 25 % (puisque seul un cur
est utilis dans cet exemple) contre un bicur plus rapide mme si celui-ci sera galement sous-exploit (50 % dutilisation).
Figure 21

Lun des deux curs


na pas dactivit

Figure 22

Une rpartition plutt


homogne sur ces huit curs

Frquence vs nombre de curs


Selon le type dactivit (OLTP, OLAP...) soumise MySQL, les besoins du serveur
sont diffrents.
JARGON OLTP, OLAP : deux catgories de systmes grer diffremment
Un systme OLTP (Online Transaction Processing) est caractristique dun site Internet. Une base de donnes transactionnelle est soumise un grand nombre dutilisateurs concurrents. Les requtes sont nombreuses et normalement trs courtes. Elles mettent jour la base continuellement.
linverse, un systme OLAP (Online Analytic Processing), typique dun data warehouse par exemple,
repose sur un nombre dutilisateurs beaucoup plus restreint mais dont les requtes soumises une base
dcisionnelle sont beaucoup plus lourdes. Ce type de base contient en gnral beaucoup moins de tables
quune base transactionnelle mais elles sont volumineuses. Les mises jour sont moins frquentes que
dans un environnement OLTP.

Les serveurs OLTP reoivent en gnral une multitude de petites requtes qui peuvent tre joues chacune sur un cur diffrent, do lintrt de possder de nom-

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

29

breux curs. En revanche, au sein dun environnement OLAP, les requtes sont
moins nombreuses mais plus lourdes en termes de cot processeur (davantage de calculs mathmatiques quune requte Internet classique) et le temps dexcution est
donc fortement corrl la frquence du processeur. La cadence du processeur prend
alors plus de poids que son nombre de curs.
En consquence, privilgiez une frquence leve pour :
La rplication. Celle-ci est pour le moment toujours monothread.
Les applications OLAP lourdes en calculs mathmatiques.
Prfrez la technologie multicur pour :
Les environnements haute concurrence (OLTP).
Les traitements susceptibles dtre dcoups et dont les requtes ne sont pas en
concurrence les unes avec les autres. InnoDB est donc ici un alli de choix, mme
si des problmes de verrous ne sont pas exclus.
Le meilleur des deux mondes serait actuellement :
Deux bicurs frquence leve sont plus polyvalents quun quadricur frquence plus modeste.
Dans le cadre de la rplication, le matre peut tourner sur un quadricur et
lesclave sur un deux bicurs. Noubliez pas que lesclave, en plus de rpliquer
(assimiler les mmes critures que le master), doit galement grer les requtes en
lecture qui lui sont soumises ; il doit donc au moins tre aussi puissant que le master, le tout avec le handicap de rpliquer les critures partir dun seul thread.

Benchmarks, encore et toujours


Il est difficile de prvoir les ractions dun systme lors dune mise jour comme le
passage de 4 8 curs. Des benchmarks sont dans ce cas fortement conseills. De
mme, ne prenez pas pour argent comptant ce que vous lisez sur diffrents blogs spcialiss... moins davoir vraiment mesur le pour et le contre, fait le tour de la question et observ un certain consensus parmi les commentaires de larticle en question.
LIRE GALEMENT Mesurer les performances de son systme
Les benchmarks sont tudis dans le chapitre ddi la surveillance dun serveur MySQL. Considrs
comme un luxe ils sont assez chronophages. Ils sont cependant invitables si lon souhaite vraiment
mesurer la raction dun systme face une forte charge.

Prenons le cas controvers de la variable innodb_thread_concurrency. Certains articles conseillent de la passer 0 et dautres de conserver la valeur par dfaut... Qui a
raison, qui a tort ? Rponse : les deux ou personne, selon le contexte ! Dsactiver

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

30

MySQL 5 Audit et optimisation

cette limitation peut aussi bien dboucher sur de grandes amliorations tout comme
provoquer linverse de leffet recherch. Tout dpend de votre architecture et du type
dactivit soumis MySQL.
Il existe bien une formule couramment reprise pour le calcul de cette variable :
innodb_thread_concurrency = nombre de curs * nombre de disques * 2

Mais celle-ci est considrer avec prcaution. Sa valeur par dfaut a dailleurs vari
entre diffrentes versions de MySQL, passant de 500 (signifiant pas de limite
lpoque) 0, puis 8... Si vous voulez mesurer limpact de cette variable, commencez par excuter plusieurs benchmarks en conservant votre valeur actuelle, notez
les temps de rponse puis passez par exemple 0 (signifiant pas de limite sur les versions actuelles) et observez les changements.
RAPPEL Configurer son serveur MySQL
Pour en savoir plus sur ce type de variables, rendez-vous au chapitre 6 Optimiser son serveur MySQL .

Il convient donc, quel que soit le conseil reu, de tester si possible sur ses propres systmes les amliorations proposes. Sachez ce titre que les grands constructeurs permettent souvent, si vous avez rellement lintention dacqurir du matriel, de tester
leurs systmes dans votre centre de traitement. Vous aurez alors tout loisir de faire subir
au matriel prt les benchmarks qui vous correspondent avant de signer le chque.
Ainsi, si vous venez dacqurir un systme multicur susceptible de poser des problmes de concurrence InnoDB (disons partir de huit curs), commencez si possible par tester diffrentes versions de MySQL afin de dterminer laquelle est susceptible de lever dventuels problmes de mutex. Par exemple, activez tout dabord
le plug-in InnoDB contenu partir de la version 5.1.38 de MySQL ou ajoutez-le sur
une version plus ancienne. Testez ventuellement la version 5.4 (encore en bta
lheure actuelle) et le moteur XtraDB de Percona.
Outre les moteurs de stockage (InnoDB/XtraDB) et les versions de MySQL, la gestion des threads par le systme dexploitation a galement son rle jouer, les processeurs multicurs tant plus ou moins bien exploits. Solaris a une trs bonne rputation dans ce domaine (kernel threads) tandis que sous Linux limplmentation NPTL
(Native POSIX Thread Library) a supplant lancienne librairie nomme
LinuxThreads et offre dsormais de bien meilleures performances dans la cration et
destruction des threads que par le pass.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

31

En conclusion de cette section sur les processeurs, retenez les points suivants :
MySQL apprcie en gnral les processeurs rapides, plus encore quun nombre
lev de curs.
Des points de contention existent au niveau du serveur MySQL lui-mme (rplication mono-thread...), du systme dexploitation (gestion des threads), mais galement au sein des moteurs de stockage, tout cela expliquant que les performances
ne progressent pas au rythme de lajout de nouveaux curs.
La gestion des systmes multicurs est en constante amlioration grce aux avances logicielles du serveur MySQL lui-mme et des moteurs de stockage, comme
InnoDB (le plus utilis dans un environnement haute concurrence) mais galement PBXT, qui semble bien parti.
Il nexiste pas de processeur idal pour tous les besoins : un site Internet (OLTP)
et un data warehouse (OLAP) ne sont pas soumis aux mmes charges de travail.
Il est parfois trs difficile de prdire prcisment les amliorations potentielles
apportes par lajout de plusieurs curs un systme existant ; des benchmarks
sont ncessaires (ajustements du my.cnf, comparaisons entre moteurs et versions
de MySQL). Modifiez un seul paramtre et testez.
ASTUCE Pour aller plus loin
Voici deux liens susceptibles de vous intresser, lactualit du moteur de stockage InnoDB et un blog consacr des benchmarks :
B http://blogs.innodb.com/
B http://dimitrik.free.fr/blog/
Retrouvez galement dautres liens dintrt dans les ressources disponibles en ligne de cet ouvrage :
B http://www.editions-eyrolles.com

Choisir ses disques et son systme RAID


Classiques goulets dtranglement, les disques sont bien souvent le talon dAchille de
MySQL.
Indispensables actuellement, les disques subissent la concurrence des puces mmoire,
que celles-ci soient constitues de cellules volatiles (mmoire vive) ou persistantes
(Flash/SSD). Il est en effet primordial de faire son possible pour en rduire lutilisation. ce sujet, consultez le chapitre consacr la configuration du serveur MySQL
afin de dfinir au mieux la taille des caches les plus importants pour MySQL selon le
contexte : key_buffer_size, innodb_buffer_pool_size, cache de requtes...

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

32

MySQL 5 Audit et optimisation

SAVOIR Temps daccs mmoire vs temps daccs disques


Cet article (http://www.dbnewz.com/2008/11/20/), tir de lun de nos blogs, relate limportance de la
mise en cache lorsquelle concerne un parcours bas sur des lectures alatoires. Entre un parcours
squentiel sur disque (full scan table) et le mme parcours en mmoire, il existe un facteur 10, comparer avec un facteur 2 500 (!) pour une lecture alatoire entre son temps de parcours en mmoire et celui
correspondant sur disque. Ces chiffres sont mettre au crdit de Percona (MySQL High Performance 2nd
Edition). Les lectures alatoires (random read) sont les plus coteuses et donc les plus intressantes
mettre en cache.

Ceci tant dit, et puisquil est indispensable de sauvegarder un moment ou un


autre les mises jour de la base (logs binaires, logs des transactions, donnes ellesmmes...), analysons les problmatiques que posent les disques actuels et tudions
comment on peut tenter dobtenir les meilleures performances possibles grce une
configuration matrielle adapte.

Temps daccs versus taux de transfert


Temps daccs, taux de transfert, rotations par minute... Quels critres retenir en
priorit pour un disque destin MySQL ?
Pour bien comprendre les enjeux, rsumons le mcanisme dune lecture sur disque
par cette simple formule :
lecture sur disque = temps d'accs + taux de transfert

Le temps daccs (seek time) est le temps que met la tte de lecture se placer sur la
bonne piste de lun des plateaux du disque. Une fois en place, il faut encore attendre
que la donne recherche sur cette piste passe sous la tte de lecture. Avec de la
chance, la tte peut tomber exactement dessus, sinon il faut patienter un tour complet... Ce temps dattente est galement appel rotational latency. Enfin, une fois la
tte de lecture positionne sur le bloc secteur recherch, il faut attendre que les donnes soient lues au rythme de la rotation du disque puis transfres au systme.
En termes de temps, le placement de la tte de lecture au bon endroit sur le disque
influence lourdement le temps global ncessaire pour une lecture. En consquence,
nhsitez pas dpenser un peu plus pour les disques dont les temps daccs sont les
plus faibles : le retour sur investissement est garanti. Les meilleurs temps daccs se
situent actuellement autour de 4 millisecondes. Pour vous en persuader pourquoi ne
pas suivre les procdures de test tudies au chapitre 4 Surveiller son serveur
MySQL et les appliquer deux catgories de disques aux temps daccs diffrents ?

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

33

Figure 23

Les principaux lments


constituant un disque dur

RETENIR Lecture/criture alatoire ou squentielle


On parle de lectures ou critures alatoires (mais le terme anglais est bien plus utilis : random read/
write) lorsque celles-ci se succdent des endroits diffrents du disque, do le terme alatoire. A contrario, on parle de lectures/critures squentielles lorsquelles sont effectues les unes la suite des
autres sur le disque.
Nous venons dvoquer le cot en termes de temps ncessaire une tte de lecture pour se positionner
au bon endroit du disque. Par dfinition, les lectures ou critures dites alatoires sont donc beaucoup
plus coteuses que leurs homologues squentielles, qui elles ne ncessitent pas de rechercher nouveau
la bonne position o lire/crire.
Les lectures alatoires sont particulirement coteuses pour un disque dur classique du fait des multiples
positionnements successifs de la tte de lecture. Les SSD (Solid-State Drive), puces mmoire persistantes,
abordes plus tard dans ce chapitre, offrent en revanche de bien meilleures performances pour ce type de
lecture du fait de labsence de dplacement de pices mcaniques.

Dans le cadre de lactivit dun site Internet (forte concurrence, traitements lgers ),
la base est soumise une multitude de requtes diffrentes, de lectures et de mises
jour. La majorit dentre elles appartiennent la catgorie des lectures alatoires, les
ttes de lecture pointant l o sont stockes les donnes. Celles-ci pouvant tre positionnes nimporte o sur le disque, le terme alatoire nest encore une fois pas usurp.
En consquence, pour un environnement OLTP, le temps daccs dun disque dur est
le critre de choix placer en premire position. En regard de linfluence du dplacement de la tte de lecture vers la position lire ou crire, le taux de transfert passe en
effet en seconde position. Cela est dautant plus vrai que la quantit de donnes
rapatrier, dans le cadre dune requte Internet typique, sera faible.
En revanche, au sein dun environnement OLAP, o les quantits de donnes rapatrier sont beaucoup plus importantes, les index moins nombreux et les lectures
squentielles plus prsentes, le taux de transfert reprend de limportance.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

34

MySQL 5 Audit et optimisation

Enfin, la vitesse de rotation des disques nest pas la donne principale retenir pour
le choix dun disque. Cela dit, la vitesse de rotation contribue la fois au temps
daccs (souvenez-vous du temps de latence lie la rotation du plateau une fois la
piste dtermine mais pas encore le bloc secteur) et au temps de transfert, puisquelle
influence la vitesse laquelle seront lues les informations par la tte de lecture.

La technologie RAID
Lacronyme RAID Redundant Array of Inexpensive Disks, se dfinit galement parfois
par Redundant Array of Independent Disks du fait de la notion toute relative du caractre Inexpensive, cest--dire bon march, de ces disques.
Cette technologie recense en fait plusieurs configurations possible et dsigne selon le
niveau de RAID choisi un systme capable dapporter, par exemple, une meilleure
tolrance aux dfaillances matrielles, grce notamment la redondance des disques
ou au contrle de parit, mais galement susceptible de supplanter un disque classique face une monte en charge constitue de lectures ou dcritures.
ATTENTION La rplication et la monte en charge des critures
Concernant la monte en charge des lectures, une des techniques les plus rpandues avec MySQL consiste utiliser la rplication afin de dcharger le matre des lectures et de reporter cette tche sur un ou
plusieurs esclaves. La tche est plus difficile ds lors quil sagit dabsorber davantage dcritures. Dans
ce cadre, par exemple, la rplication matre-matre est un faux ami puisque chacun des matres doit
reporter sur lui-mme les mises jour reues par lautre.

Ainsi, lune des promesses du RAID est de parallliser les critures.


Quelle configuration RAID est susceptible de correspondre votre activit ? Sans
entrer dans le niveau de dtails dun ouvrage ddi cette technologie, voici les principaux niveaux de RAID et nos recommandations vis--vis de MySQL.

Les principaux niveaux de RAID


Le schma suivant dtaille les niveaux et les architectures RAID les plus souvent rencontrs dans un environnement li aux bases de donnes.
RAID 0 (ou volume agrg par bande/stripping )
Chaque disque de lensemble ne stocke quune partie des donnes. Celles-ci sont
divises en blocs et disperses sur lensemble des disques. Les requtes de type
random read apprcient la paralllisation offerte par le RAID 0 : plusieurs disques
peuvent en effet contribuer simultanment retrouver les donnes recherches.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

35

Figure 24

Synthse des niveaux de RAID


abords

Le gros inconvnient de ce niveau de RAID concerne la fiabilit de lensemble. Si un seul


des disques tombe en panne (ce qui statistiquement est plus probable avec plusieurs disques quavec un seul), toutes les donnes sont perdues ; il ny a pas de redondance.
En consquence, ce niveau de RAID est rserver aux environnements de tests ou
susceptibles dtre remonts rapidement par dautres moyens.
Le RAID 0 est la moins chre des implmentations de type RAID et la plus efficace,
si on rapporte les performances au nombre de disques impliqus, mais galement la
plus dangereuse.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

36

MySQL 5 Audit et optimisation

RAID 1 (ou mirroring)


Chaque criture applique un disque particulier est automatiquement reporte sur
les autres disques de lensemble. Toutes les donnes sont dupliques sur tous les disques. Cette redondance sobtient au prix dune pnalit au niveau des critures par
rapport au RAID 0. Contrairement aux critures qui sont appliques sur tous les disques, les lectures sont paralllisables. Cette configuration est particulirement efficace en cas de parcours squentiel total dune table (full table scan) puisque toutes les
donnes se trouveront sur un mme disque.
Linconvnient de ce niveau de RAID est le surcot en disques.
RAID 5 (ou volume agrg par bande parit rpartie)
Trs rpandu, le RAID 5 permet daccder une certaine redondance en conservant
de bonnes performances. Ce niveau de RAID est semblable au RAID 0 premire
vue : les donnes crire sont rparties sur diffrents disques. La diffrence rside en
fait dans lapparition sur chaque bande dun disque ddi la parit. Ce bloc de
parit est stock circulairement sur les diffrents disques.
Les critures seffectuent au prix dun lger surcot : en effet, en plus du bloc crire,
les blocs des autres disques de la mme bande doivent tre lus afin de calculer la
parit. Dans le cas o plusieurs processus mettent jour la mme bande de donnes
(cest le pire cas), ils devront attendre que le verrou pos sur le bloc de parit lors de
son criture soit lev.
REMARQUE Les opposants au RAID 5
Toute technologie a ses dtracteurs... le RAID 5 ne fait pas exception. Rassembls sous le terme BAARF
(Battle Against Any Raid Five), ces opposants au RAID 5 publient sur ce site leurs critiques relatives ce
niveau de RAID. Retour dexprience, comparaisons avec dautres niveaux de RAID, les dbats sont techniques et soulignent notamment les performances en criture jusqu 50 % moins leves que sur du
RAID 0 ainsi que les risques de propagation derreurs entre diffrents disques en cas de lecture dun disque dfectueux mais pas (encore) dtect comme tel.
B http://www.miracleas.com/BAARF/
Attention tout de mme : ces diverses discussions ne sont pas toutes dates et sont relativiser au
regard des amliorations rgulirement apportes aux drivers des cartes contrleur notamment. Le
RAID 5 tant une des implmentations de RAID les plus rpandues, les efforts des constructeurs permettent parfois de nuancer certains dfauts attribus ce niveau de RAID. lire nanmoins.

La technologie RAID 5 est redondante condition de ne perdre quun seul disque


la fois. Lorsquun disque de remplacement (spare) est prsent, il sera automatiquement reconstruit partir des autres blocs. Pendant la dure de reconstruction,
comptez deux heures pour 300 Go environ, les performances de lensemble seront

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

37

dgrades. Plus la taille des disques restaurer est grande, plus le risque de perdre un
autre disque pendant la reconstruction est fort. Partant du principe que les disques
dun ensemble RAID sont souvent de la mme gnration et du mme type, ils sont
susceptibles de connatre des dfaillances similaires dans des priodes rapproches.
RAID 10 (1+0)
Comme son nom lindique, le RAID 10 combine les bienfaits du RAID 0 (rpartition des donnes sur plusieurs disques) tout en annulant sa faiblesse : le manque de
redondance. Avec du RAID 10, les blocs de donnes sont en effet galement dupliqus (mirroring). Le RAID 10 est trs performant mais galement coteux puisque
la 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 reconstruction dun disque moins pnalisante que sur du RAID 5 (ici seule la grappe concerne est impacte), et une fiabilit accrue (pas de perte de donnes tant que tous les
disques dune grappe ne sont pas dfaillants).
Si votre budget est limit et que votre systme opre peu dcritures, le RAID 5 est
suffisant ; sinon prfrez toujours du RAID 10.
En quelques mots, voici les mots-cls retenir propres chaque niveau de RAID
que nous avons abord :
Tableau 21 Caractristiques principales des diffrents niveaux de RAID

Niveau
de RAID

Caractristiques

Avantages : cot, performances en lecture/criture.


Inconvnients : pas de redondance, rserver aux environnements non critiques ou remplaables rapidement.

Avantages : simple, fiable, performances en lecture.


Inconvnients : pas de gain sur les critures, cot rapport la taille disque disponible.

Avantages : meilleur rapport prix/espace disque disponible, performances en lecture.


Inconvnients : ne supporte la perte que dun seul disque, intgrit des disques surveiller.

10

Avantages : performances en lecture/criture, fiabilit.


Inconvnients : cot.

RESSOURCES EN LIGNE Dautres niveaux de RAID existent


Retrouvez en ligne de la documentation concernant le RAID ; la page de Wikipedia consacre cette
technologie est un bon point de dpart. Vous y dcouvrirez notamment dautres niveaux de RAID.
B http://fr.wikipedia.org/wiki/RAID_(informatique)

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

38

MySQL 5 Audit et optimisation

Les deux implmentations du RAID : logicielle et matrielle


La technologie RAID existe sous forme matrielle par le biais dune carte contrleur,
ou sous forme logicielle, le systme dexploitation se chargeant de grer les disques
selon le niveau de RAID choisi (sil est disponible).
Les deux mthodes possdent leurs avantages et inconvnients. Comme souvent il y
a de nombreux dbats et pas de rponse unique.
Le RAID logiciel est videmment moins cher. De plus, sil mane dun systme
dexploitation Open Source, on peut compter sur le fait que la communaut puisse
dtecter puis corriger un bug plus rapidement que sous une solution propritaire.
Dsavantage, limplmentation RAID logicielle ajoute une surcouche logique votre
application. noter que le serveur MySQL lui-mme proposait dans sa version 4 un
attribut RAID_TYPE ajouter dans la syntaxe dun CREATE TABLE pour une table
MyISAM, option abandonne depuis la version 5.
En ce qui concerne la configuration dune telle solution RAID logicielle, tout
dpend de lexprience de vos quipes ; les versions matrielles du RAID ont la rputation dtre plus simples grer... condition que les drivers des cartes contrleurs
RAID ne soient pas rcalcitrants, ce qui peut constituer une faiblesse pour ces solutions propritaires, chaque fournisseur (Adaptec, Dell, HP...) disposant en effet de
son propre applicatif pour grer son contrleur. Cette dpendance semble ne pas
plaire Google, par exemple : ils utilisent principalement du RAID logiciel afin de
ne pas tre dpendants des fabricants de matriel.
REMARQUE Carte contrleur RAID, force et faiblesse la fois
Les configurations bases sur une implmentation RAID possdent une carte contrleur permettant de
grer les disques et leur ventuelle redondance. Outre les caractristiques dj voques pour de tels systmes, il faut galement souligner que cette carte peut galement constituer une faiblesse et devenir
son tour, tout comme un disque, un lment critique de dfaillance. SPOF (Single Point Of Failure) est le
nom donn ce type dlment critique dans la langue de Shakespeare. En effet, si la carte elle-mme
nest pas redondante, en cas de problme matriel, les disques ne sont plus accessibles.
Selon les constructeurs et les modles, il est possible de faire fonctionner deux cartes de concert ou en
dfinir une comme le secours de lautre. Noublions pas les TBBU (Transportable Battery Backup Unit) :
celles-ci permettent dextraire littralement le cache et sa batterie dune carte contrleur dfectueuse
(grille lors dune surtension lectrique, par exemple) et de les rinstaller sur une nouvelle carte.

Le RAID matriel est plus onreux mais dcharge le systme dexploitation de la


gestion des disques. Les cartes contrleurs RAID les plus intressantes pour les bases
sont celles qui proposent une certaine quantit de cache (512 Mo de RAM par
exemple) afin doffrir performance et fiabilit. Ce dernier avantage ne concerne que
les modles dits BBWC, Battery-Back Write Cache. En cas de coupure de courant, le

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

39

cache (volatil par dfaut) est alors conserv grce la batterie pendant quelques jours
(72 h est une valeur courante). Attention, une application utilisant le cache dune
carte contrleur RAID non seconde par une batterie sexpose des pertes de donnes en cas de coupure de courant.
Si vous en avez les moyens, nous vous conseillons une implmentation matrielle
base sur une carte contrleur RAID disposant de cache et de type BBWC.

Intrt du cache sur une carte contrleur RAID


Pour un serveur bas sur une solution RAID matrielle, la carte contrleur est un
point de passage oblig pour les donnes lors de leur transit entre les disques et le
systme dexploitation sur lequel repose MySQL.
chaque tape traverse (MySQL, OS, carte contrleur, disques) les donnes sont
en effet susceptibles dtre stockes dans un cache.
Figure 25

Les diffrents trajets du buffer


pool vers le disque
et inversement

Il est possible de configurer le cache de la carte contrleur afin quil soit utilis en lecture, en criture ou bien les deux la fois. Ce sont surtout les deux modes les plus
rpandus.
En mode lecture, on cherche lire un enregistrement partir de la base de donnes.
Configurer le cache de la carte contrleur en lecture revient dire quon estime que la
quantit de cache disponible va permettre dy retrouver une donne, ce qui viterait
daller interroger les disques. En regard de la quantit de mmoire disponible sur ce
type de carte, cest en gnral une mauvaise utilisation du cache. En effet, la quantit
de mmoire disponible par ailleurs est beaucoup plus importante et plus mme de
contenir la donne recherche que ce petit tampon.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

40

MySQL 5 Audit et optimisation

RAPPEL Le cache de requtes en amont de la carte RAID


Souvenez-vous quavant mme dinterroger ventuellement le cache de la carte contrleur (si celui-ci est dfini
en cache lecture), le serveur MySQL vrifiera dabord si la requte et son rsultat associ ne sont pas dj dans
le query cache (en gnral de taille infrieure celle du cache de la carte contrleur), dans le buffer_pool
dInnoDB (qui se compte en Go), mais galement dans le key_buffer_size de MyISAM, si la donne
recherche est contenue dans un index (covering index, par exemple). En conclusion, il y a peu de
chance que le cache dune carte contrleur RAID configur en lecture soit utile dans ce contexte.

Il en va de mme pour les lectures dites read-ahead. Il sagit ici de donnes stockes
en avance car elles correspondent, selon lalgorithme du driver de la carte contrleur,
des enregistrements susceptibles dtre lus prochainement. L encore, la taille du
cache est trop faible pour esprer un taux de succs (hit) suffisant dans cette configuration, alors que InnoDB effectue dj par ailleurs ce type de prdictions.
En mode criture, on souhaite stocker un enregistrement dans la base de donnes.
Pour un serveur MySQL, une carte contrleur RAID a beaucoup plus dintrt dans
un contexte dcritures ; nous allons voir pourquoi. Le cache de la carte contrleur
peut tre dfini en write-through ou en write-back.
En mode write-through, les donnes provenant de la base traversent la carte sans y
tre stockes et ont pour destination les disques. Ce sont eux qui renverront un
acquittement la fonction systme (fsync() par exemple) qui a initi lcriture, une
fois les donnes durablement stockes.
Face la mme demande dcriture sur disque que prcdemment (appele flush), le
mode write-back autorise la carte contrleur court-circuiter les disques, stocker les
donnes dans le cache et rpondre positivement au systme dexploitation qui peut
alors initier une autre demande normalement bloquante (synchronous write) plus rapidement. Selon la configuration de la carte contrleur, le cache sera ensuite plus ou
moins rapidement envoy vers les disques afin dy tre stock durablement. Cet envoi
group permet de rduire le nombre dcritures ncessaires.
Ce type doptimisation est particulirement utile pour InnoDB lors de lcriture sur
disque du log_buffer. Rappelons que la frquence de cette criture dpend de la
valeur de la variable systme innodb_flush_log_at_trx_commit. Lorsque celle-ci
prend la valeur 1, la plus sre, le log_buffer est crit sur disque chaque COMMIT
ainsi qu chaque checkpoint (environ 1 fois par seconde pour InnoDB).
Ce rglage, conseill, a nanmoins un fort impact sur les performances. Il en va de
mme pour la variable sync_binlog lorsquelle prend la valeur 1. Dans ce cas, MySQL
veille ce que soit crit sur disque le log binaire modifi par la dernire transaction.
Ces deux activits bnficient trs largement de la prsence dun cache sur la carte
contrleur.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

41

Figure 26

Parcours dune transaction au


sein dInnoDB, en mmoire puis
sur disque

BON SAVOIR Les outils pour vrifier les rglages de sa carte contrleur
chaque fabricant son outil ; voici une liste susceptible de vous aider grer la configuration de votre
carte contrleur :
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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

42

MySQL 5 Audit et optimisation

Indispensable batterie
Si vous dcidez dutiliser le cache de la carte contrleur RAID en mode write-back,
celui-ci doit absolument tre second par une batterie. Les modes lecture ou writethrough nen ont pas besoin.
Le problme est bien sr relatif lalimentation lectrique. En cas de problme de ce
type, toutes les donnes stockes dans le cache et donc considres par le systme
dexploitation et MySQL comme stockes durablement ne le sont pas encore rellement. Une batterie permet donc de diffrer cette criture au moment o les disques
seront aliments de nouveau. Cette criture se produit soit avant que les disques ne
soient nouveau considrs comme disponibles, soit immdiatement si les disques
sont relis un onduleur.
EN PRATIQUE Dure de vie de la batterie dune carte RAID
Certaines batteries ont la capacit de durer 72 h, ce qui permet de survivre une coupure lectrique le
temps dun week-end. Cela peut savrer trs utile si jamais la machine concerne nest pas surveille
24 h/24 h par une quipe dastreinte et peut supporter une telle coupure (cas dun serveur en interne de
moindre importance par exemple).

Les systmes RAID dots dun cache en criture second par une batterie sont dit
BBWC. On dit galement quils disposent dune BBU, Battery Backed Unit.

Le cache interne des disques : une arme double tranchant


Ne pas disposer dune carte contrleur BBWC est une chose, mais il y a pire encore :
subir des pertes de donnes dues un cache disque non matris.
Reprenons lexemple de la mise jour dun enregistrement prsent en mmoire, dans
le buffer pool dInnoDB. Une fois la trace de la transaction enregistre dans le
log_buffer (toujours en mmoire), celui-ci trouve sa place dans un fichier de log
ddi aux transactions, sur disque. Le but est ensuite bien sr de traduire cette transaction en impact rel dans les donnes.
Si le disque contenant les logs de transaction nest pas ddi cette activit, plusieurs
lectures ou critures seffectueront entre deux critures de logs ce qui empche les critures de se drouler de faon squentielle. En effet, la tte de lecture naura pas conserv
la position de la prcdente criture. la cl, de coteux dplacements de la tte de lecture lors de chaque COMMIT (avec innodb_flush_trx_commit = 1). Le principe est le
mme avec les logs binaires et le rglage sync_binlog = 1.
Le cache au niveau de la carte contrleur en mode write-back est alors tout indiqu
pour viter de transformer chaque COMMIT en coteuse critures alatoires.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

43

Pourtant, le cache de la carte contrleur, mme configur en write-back et protg par


une batterie, ne suffit pas considrer que les mcanismes dcriture sur disques soient
dsormais fiables et optimiss (mme si un grand pas a t effectu dans ce sens).
Concernant le volet de loptimisation, lanalyse de la variable innodb_flush_method
et notamment de la valeur O_DIRECTquelle est susceptible de prendre, pourrait encore
vous procurer quelques gains.
JARGON innodb_flush_method = O_DIRECT
Il sagit ici dindiquer au systme dexploitation de ne pas mettre en cache les donnes candidates un
flush disque, par exemple. On estime en effet que le cache InnoDB est suffisant et quil est inutile de perdre du temps et de lespace mmoire en remplissant le cache systme. Avec O_DIRECT la fonctionnalit
read-ahead potentiellement offerte par lOS est galement dsactive. InnoDB sait galement effectuer
cette opration lui-mme grce aux modes sequential et randomread-ahead. En mode squentiel,
InnoDB est capable de dtecter que pour certaines parties du tablespace laccs est squentiel ; le
moteur envoie alors une demande de lectures correspondant la suite logique de ce qui a dj t lu. Le
mode random permet InnoDB de dtecter quelle partie du tablespace sera probablement lue compltement partir du buffer_pool et danticiper ces lectures :
B http://dev.mysql.com/doc/refman/5.1/en/innodb-disk-io.html
Notez que lutilisation de cette variable peut impacter les performances de votre systme, souvent dans
le bon sens. Nous vous conseillons cependant de la tester sur un environnement de recette avant de la
tenter en production (cette variable nest de toute faon pas modifiable chaud).
Lutilisation de cette option fait dbat depuis longtemps, le site ci-dessous est un bon exemple de discussion sur le sujet. Si Linus Torvald lui-mme est un opposant de la mthode O_DIRECT, Peter Zaitsev
(Percona) a un avis oppos. lire.
B http://kerneltrap.org/node/7563

La fiabilit de vos donnes, notamment en cas de coupure lectrique, est encore plus
cruciale que loptimisation. InnoDB dispose dun systme de rcupration perfectionn en cas de crash mais il lui est parfois impossible de rcuprer ce qui tait pourtant considr comme durablement stock.
Il est en effet possible que lors dun enregistrement, au-del de ltape de la carte
contrleur (dont le cache est comme il se doit protg par une batterie), lorsque
celle-ci envoie le contenu de son cache vers les disques, ces derniers mentent : ils sont
eux aussi capables de renvoyer un acquittement alors que lcriture nest pas encore
effectue. Ce mcanisme, orient performance et bas sur un buffer en critures prsent sur les disques, est trs dangereux en cas de coupure de courant. Les donnes
sont dans ce cas perdues avant davoir rellement t crites sur les disques, rendant
inutile la prsence dune batterie sur la carte contrleur.
Conscient que la commande fsync() ne garantit pas que les donnes soient rellement
crites sur le priphrique, Mac OS X, par exemple, tient compte de ce problme et

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

44

MySQL 5 Audit et optimisation

permet dutiliser une autre fonction (F_FULLFSYNC), celle-ci permettant de contrler le


cache du disque et de demander son criture relle. Cependant, ce serait trop simple :
certains disques FireWire sont connus pour ne pas effectuer laction demande...
Rsultat des courses, seuls des scnarios de test base de coupures de courant brutales programmes par vos soins pourront vous certifier que les donnes sont correctement crites, y compris dans un contexte exceptionnel.
lire galement
Un outil de Brad Fitgerald longuement dbattu sur Slashdot traite prcisment de ce problme li la
mise en cache de certains disques et permet de les dtecter.
B http://brad.livejournal.com/2116715.html
B http://hardware.slashdot.org/article.pl?sid=05/05/13/0529252

Les SSD : futur hit ?


Toujours davantage de curs au sein des processeurs, encore plus de mmoire vive et la
dmocratisation des SSD (Solid State Drive), voil ce qui nous attend peut-tre dans un
avenir trs proche.
Les SSD sont un des types de matriels qui voluent le plus. Encore chers compars
leurs anctres dots de pices mcaniques, leur prix chute rgulirement malgr
quelques hausses passagres dues des pnuries de composants mmoire. Une
rcente tude de iSuppli indique quen 2008 1,4 millions dunits ont trouv preneur... comparer avec les 5,8 millions dunits qui scouleront pour 2009 et les 65
millions dunits prvues pour 2013 !
Trop chers pour tre un march de masse, ce sont aujourdhui les centres de donnes
qui se ruent sur les SSD : faible consommation lectrique et encombrement rduit
sont deux arguments qui font mouche dans le cadre de cette activit.
Plus proches de la RAM que dun disque dur o sactivent plateaux et ttes de lectures, les SSD sont des puces mmoire persistantes (de type Flash), un peu comme
nos cls USB.
Les inconvnients relatifs cette technologie sont en ce moment les suivants (mais
les SSD voluent trs vite !) :
les performances en random-write : les puces mmoire Flash utilises par les SSD
ncessitent deffacer une grande zone mmoire avant lcriture, ce qui pnalise les
performances. Cependant des modles rcents ont affich de trs gros progrs sur
ce sujet. Il semble donc que les jours de cet inconvnient soient compts ;
la dure de vie du support : les cellules mmoire susent en fonction du nombre
dcritures reues. Diffrents algorithmes sont dj luvre afin doptimiser cette

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

45

dure de vie et de marquer comme dfectueuses certaines cellules le cas chant.


Les contrleurs de ces puces sont en constante amlioration et l aussi cette dure
de vie autrefois considre comme problmatique semble en passe dtre rsolue ;
prix rapport au Go ;
faible capacit (Go) par unit.
Au chapitre des avantages :
temps daccs extrmement faibles (quelques centimes de ms contre 4 ms environ pour un disque performant : un facteur 10 !) ;
excellentes performances en lectures alatoires (random read) ;
adapte aux environnements OLTP (majorit de lectures) ;
consommation nergtique rduite.
Des solutions matrielles se montent autour de cette technologie : Shooner information Technology, Virident, Fusion-io sont quelques-uns des noms que vous pouvez
tudier si le sujet vous intresse.
Les moteurs de stockage tentent galement de se mettre la page. Tandis que PBXT
contient des mcanismes ddis ce type de matriel, un moteur mergent tel que
RethinkDB est entirement tourn sur cette technologie.
Nous vous conseillons de parcourir les liens fournis pour cette section dans le contenu en ligne ddi cet ouvrage afin de profiter de nos liens relatifs aux SSD. Seul
Internet peut fournir des informations jour sur un sujet aussi brlant...

MySQL et la mmoire
Les besoins en mmoire de MySQL sont trs variables. Ainsi des valeurs courantes
telles que 8 Go, 16 Go ou 32 Go peuvent savrer amplement suffisantes ou trop faibles selon la quantit de donnes avec laquelle vous travaillez.
Un manque de mmoire constitue un goulet dtranglement important pour MySQL
puisque cette dficience en RAM crera une tension par ailleurs, notamment au niveau
des disques, MySQL devant rcuprer partir des disques ce qui na pas pu tre stock
en RAM. De l peuvent dcouler trs probablement des lenteurs, des verrous et une
accumulation de requtes impactant processeurs et disponibilit de votre application.
Le manque de ressources mmoire a un potentiel tout fait destructeur.
Rappelons ici quelques chiffres dj cits lorsque nous voquions les disques en dbut
de chapitre : pour une lecture, un parcours squentiel en mmoire est environ dix fois
plus rapide que sur disque mais deux mille cinq cents fois plus rapide ds lors quil
sagit dun parcours alatoire.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

46

MySQL 5 Audit et optimisation

Comment MySQL utilise-t-il la mmoire ?


Le serveur MySQL utilise la mmoire diffrentes occasions. Tout dabord le cache
dindex pour MyISAM (key_buffer_size) et le buffer pool pour InnoDB
(innodb_buffer_pool_size) sont les caches les plus gourmands en mmoire. Ces
deux caches sont les plus importants et se comptent en Go voire en plusieurs dizaines
de Go pour le buffer pool.
On compte ensuite diffrents caches, de tailles plus modestes :
Le cache de requtes (query cache), dont la taille maximale conseille varie entre
128 et 256 Mo. Ce type de cache est tudi en dtail au chapitre 6.
Chaque connexion au serveur MySQL est un thread qui le serveur alloue une
quantit de mmoire variable, selon la faon dont sont configurs les buffers propres chaque session dans le fichier my.cnf. Une fois le thread termin, la
mmoire est soit libre sil est dtruit compltement, soit conserve si le thread
est gard dans le cache qui lui est ddi. Ce mcanisme permet dviter une perte
de temps la cration dun nouveau thread.
Les tables MEMORY utilises en interne par MySQL, lors doprations de tri par
exemple. Leur taille maximale est dfinie par la plus petite valeur entre
tmp_table_size et max_heap_table_size.
Les tables lies aux privilges de chaque utilisateur MySQL vrifient pour chaque
requte si un utilisateur possde les droits suffisants. Pour des raisons de performance, ces tables sont charges en mmoire.
Le table_cache : cache des handlers de fichiers lis aux tables ouvertes par
MySQL.
Une fois vos tests effectus, si vous manquez de mmoire (caches dindex MyISAM
trop faibles, faible efficacit du buffer pool sous InnoDB alors quil est impossible
dajouter ces diffrents buffers davantage de RAM sans mettre en pril le reste du
systme), il est temps dacheter de nouvelles barrettes.
Ajouter de la mmoire vive est un des moyens les plus simples, rapides et bon march
daugmenter de faon importante les performances de votre serveur MySQL. Lajout
de mmoire soulage les disques (les random I/O cotent trs cher), vite MySQL
et au systme dexploitation dincessants allers-retours entre mmoire vive et disques
trs coteux. Une quantit de mmoire vive suffisante contribue galement rduire
lutilisation du swap.
La diffrence peut vraiment tre spectaculaire si votre activit est particulirement
oriente lectures. En revanche, si celle-ci est fortement sollicite au niveau des critures, il est peut-tre plus sage dinvestir dans un systme disque plus performant.
Pensez notamment aux cartes contrleur BBWC tudies prcdemment.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Choisir son serveur MySQL


CHAPITRE 2

47

Figure 27

Les allers-retours entre disques


et mmoire vives sont coteux.

Un outil tel que mysqlreport vous aide visualiser concrtement le pourcentage de


lectures/critures en cours sur votre systme.
linstar des SSD, la mmoire vive permet galement certains constructeurs de
proposer du matriel destin prendre place au sein de vos centres de donnes sous la
forme de botiers 2U ou 3U. Violin ou Texas Memory Systems proposent des botiers (onreux) capables de contenir jusqu 500 Go de RAM environ. Vous trouverez
davantage dinformations sur les sites respectifs de ces constructeurs ou dans notre
rubrique liens en ligne concernant ce chapitre.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

3
Les moteurs de stockage
Le moteur de stockage (storage engine) est le composant qui, au sein de larchitecture
du serveur MySQL, est responsable du stockage des informations sur disque ou en
mmoire.
Nous allons prsenter les moteurs les plus utiliss sous MySQL, tels que MyISAM
et InnoDB, mais galement ceux de la nouvelle gnration mergeant de la communaut MySQL.

Mcanismes dun moteur de stockage


Chaque moteur possde ses spcificits ainsi que ses propres paramtres de configuration. Depuis la version 5.1 de MySQL, on dit quun moteur de stockage se branche
(pluggable). En effet, il est dsormais inutile de compiler MySQL pour ajouter un
moteur : il suffit de copier une bibliothque dans le rpertoire prvu cet effet et de
la charger chaud. Il est nanmoins ncessaire que cette bibliothque soit disponible
pour votre systme.
MySQL supporte plusieurs types de moteur de stockage. Dans la pratique, vous
pouvez crire votre propre moteur. Pour cela, il faudra dfinir les interfaces ncessaires et disposer de bonnes connaissances en langage C. Avant de vous lancer dans
pareille aventure, nous vous conseillons de bien tudier lexistant afin de ne pas rinventer la roue... Peut-tre trouverez-vous celui qui convient votre application.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

50

MySQL 5 Audit et optimisation

Figure 31

Les tapes entre un client


MySQL et le moteur
de stockage

Comme on le voit sur ce schma, les tapes sont les suivantes :


1 Vrification de la prsence du SELECT dans le cache ;
2 si oui, on renvoie le rsultat de la requte (resultset) ;
3 sinon, on parse le SQL, pour en vrifier la validit (dictionary check) ;
4 loptimiseur calcule le query plan ;
5 on interroge lAPI pour rcuprer les blocs ;
6 lAPI va chercher les blocs dans le moteur de stockage ;
7 on assemble le rsultat ;
8 on le renvoie au client ;
9 on le met en cache (selon la configuration).
Avant de commencer lanalyse en dtail du schma et des requtes dans une optique
doptimisation, il est intressant de connatre quels sont les moteurs notre disposition.
mysql> SELECT engine, support FROM information_schema.engines\G
*************************** 1. row ***************************
engine: InnoDB
support: YES

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3
***************************
engine: MRG_MYISAM
support: YES
***************************
engine: BLACKHOLE
support: YES
***************************
engine: CSV
support: YES
***************************
engine: MEMORY
support: YES
***************************
engine: FEDERATED
support: NO
***************************
engine: ARCHIVE
support: YES
***************************
engine: MyISAM
support: DEFAULT

51

2. row ***************************

3. row ***************************

4. row ***************************

5. row ***************************

6. row ***************************

7. row ***************************

8. row ***************************

Dans les versions prcdentes de MySQL, il faut examiner les variables (par exemple
have_innodb).
mysql> SHOW ENGINES\G
*************************** 1. row ***************************
Engine: InnoDB
Support: NO
Comment: Supports transactions, row-level locking, and foreign keys
Transactions: NULL
XA: NULL
Savepoints: NULL
*************************** 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
[...]

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

52

MySQL 5 Audit et optimisation

Linterface de gestion des plug-ins est le successeur de lancienne interface UDF


(User Defined Function) qui permettait aux utilisateurs de crer leurs propres fonctions pour MySQL. La modification a eu pour but, entre autres, daugmenter la
scurit, damliorer la gestion des versions...
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
|
+-------------+----------------+---------------+

Vous constatez que les moteurs sont bien affichs comme des plug-ins. Le champ
status indique si le moteur est activ, ce qui signifie que la librairie a t charge en
mmoire.
Pour avoir plus de dtails sur lAPI :
B http://forge.mysql.com/wiki/MySQL_Internals_Custom_Engine

Installation et suppression dun moteur


Prenons XtraDB comme exemple, afin de dcrire la manipulation ncessaire pour
installer un moteur sur un serveur MySQL.
La premire tape consiste rcuprer le plug-in sur le site de ses auteurs :
B http://www.percona.com/mysql/xtradb/5.1.39-8/RPM/rhel4/

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

53

Pour cette installation, nous choisissons le plug-in pour MySQL 5.1.39 compil sur
RHEL 4.
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

Ce paquetage rpm comprend les diffrents fichiers dont nous avons besoin : bibliothques et scripts dinstallation.
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

Il est ncessaire de vrifier que les bibliothques sont bien installes au bon endroit :
mysql> SHOW VARIABLES LIKE"%plugin%";
+---------------+-----------------------------+
| Variable_name | Value
|
+---------------+-----------------------------+
| plugin_dir
| /usr/lib64/mysql/plugin/
|
+---------------+-----------------------------+

Dans cet exemple, le rpertoire o doivent se trouver les plug-ins est bien identique.
Si ce nest pas le cas, vous devrez soit changer la configuration, soit copier les bibliothques au bon endroit. Une fois ceci effectu, il faut dmarrer MySQL et charger
les bibliothques. Le script install_innodb_plugins.sql est conu cet effet. Il
excute les commandes suivantes :
INSTALL
INSTALL
INSTALL
INSTALL
INSTALL
INSTALL
INSTALL
INSTALL
INSTALL
INSTALL
INSTALL
INSTALL
INSTALL

PLUGIN
PLUGIN
PLUGIN
PLUGIN
PLUGIN
PLUGIN
PLUGIN
PLUGIN
PLUGIN
PLUGIN
PLUGIN
PLUGIN
PLUGIN

innodb SONAME 'ha_innodb.so';


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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

54

MySQL 5 Audit et optimisation

Il est possible de supprimer le plug-in de faon analogue :


UNINSTALL PLUGIN ;

ATTENTION Suppression dun moteur de stockage utilis par une table


Si vous supprimez un moteur de stockage utilis par une ou plusieurs tables, les donnes seront toujours
prsentes mais vous ne pourrez plus y accder. Linstallation dun nouveau moteur doit tre ralise par
le DBA. Cette opration ncessite en effet des droits spcifiques pour tre excute correctement. Il
sagit ici notamment du droit dcriture dans la table mysql.plugin.

Les forces en prsence : moteurs utilis par lapplication


Nous connaissons maintenant les moteurs disponibles sur le serveur ; il nous reste
alors vrifier lesquels sont utiliss par lapplication.
mysql> SHOW PLUGINS;
***************************
Name: binlog
Status: ACTIVE
Type: STORAGE ENGINE
Library: NULL
License: GPL
***************************
Name: partition
Status: ACTIVE
Type: STORAGE ENGINE
Library: NULL
License: GPL
***************************
Name: ARCHIVE
Status: ACTIVE
Type: STORAGE ENGINE
Library: NULL
License: GPL
***************************
Name: BLACKHOLE
Status: ACTIVE
Type: STORAGE ENGINE
Library: NULL
License: GPL

1. row ***************************

2. row ***************************

3. row ***************************

4. row ***************************

Dans une base de donnes MySQL chaque table possde un seul moteur de stockage. Si vous ne spcifiez pas la valeur ENGINE dans la DDL (Data Definition Language), MySQL utilisera le moteur de stockage par dfaut dfini par la variable

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3
storage_engine.

55

Si celle-ci nest pas dfinie, la table prendra pour dfaut le type

MyISAM.
mysql> SHOW VARIABLES LIKE 'storage_engine'\G
*************************** 1. row ***************************
Variable_name: storage_engine
Value: InnoDB
1 row in set (0.00 sec)

Avec une telle configuration, chaque nouvelle table cre sera du type InnoDB si
aucune instruction spcifique nindique un autre moteur. En voici la preuve :
mysql> CREATE TABLE i (i int);
Query OK, 0 rows affected (0.13 sec)
mysql> show create table i\G
*************************** 1. row *******************
Table: i
Create Table: CREATE TABLE `i` (
`i` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Le type de la table est bien InnoDB.


B.A.-BA Crer ses tables partir de lexistant
Voici deux commandes similaires aux rsultats diffrents :
CREATE TABLE T_cible LIKE T_source

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

copie les donnes, les colonnes mais pas les index ni le moteur (cest--dire le moteur par dfaut, sauf si
on le spcifie 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
Query OK, 4076 rows affected (0.07 sec)
Records: 4076 Duplicates: 0 Warnings: 0

City;

Il est conseill dviter de mixer plusieurs moteurs au sein dune mme base de
donnes : ce nest gnralement pas une bonne pratique. Il est en effet beaucoup plus

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

56

MySQL 5 Audit et optimisation

dlicat de configurer correctement un serveur qui hberge des tables de plusieurs


types quun serveur ddi des tables dun mme moteur. Mlanger les moteurs peut
entraner des problmes de performance ou de cohrence, mme si techniquement
cela reste ralisable. Il faut noter que des tables cres via des commandes telles que
CREATE TABLE t SELECT seront galement du type du moteur par dfaut. Dans le
doute, il est prfrable de laisser la valeur par dfaut MyISAM.
Il existe plusieurs mthodes pour vrifier quels sont les moteurs utiliss :
utiliser les mtadonnes ;
mysql> SELECT table_schema, table_name, table_type, engine FROM tables;

regarder les DDL de chacune des tables ;


mysql> SHOW CREATE TABLE maTable;

examiner le statut (status) des tables ;


mysql> SHOW TABLE STATUS;

ou
SHOW TABLE STATUS LIKE 'matable'\G

ou
SHOW TABLE STATUS FROM mabase LIKE 'matable' \G

consulter dans larborescence des fichiers les extensions des fichiers de donnes.
shell> ls -lah /var/mysql/data/monSchema/

Nous vous conseillons la premire mthode, car les autres sont plus contraignantes.
Senqurir du statut de toutes les tables est susceptible daltrer les performances de
votre systme selon le moteur utilis. En effet, alors que la commande SHOW TABLE
STATUS pour des tables en MyISAM na aucun impact, elle peut tre dramatique pour
InnoDB. Notez galement que ce moteur se base sur des estimations pour ce type de
commandes. Ne soyez donc pas surpris que dune excution lautre le rsultat varie ;
InnoDB ne parcourt pas toute la table car le cot serait trop important. Contrairement MyISAM, par exemple, le nombre total denregistrements nest pas conserv
par InnoDB. ce titre, un count(*) inconditionnel obligerait InnoDB parcourir
toute la table alors que la mme commande est instantane avec MyISAM. Si vous

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

57

avez un doute sur le nombre denregistrements de vos tables InnoDB et que votre
systme nest pas surcharg, vous pouvez malgr tout pour vous rassurer lancer un
SELECT COUNT(*) FROM...

CONVENTIONS TERMINOLOGIQUES Base de donnes, serveur, instance, schma


Jusqu la version 5.0, MySQL voquait la notion de base de donnes et non de schma pour dsigner
lendroit o les donnes sont stockes. Il est ncessaire de prciser ces diffrentes notions afin dtre
bien compris par son interlocuteur. Une convention de nommage peut tre ncessaire. En effet, plusieurs
termes peuvent dfinir le mme concept.
Une base de donnes MySQL est ainsi susceptible de reprsenter un serveur, une instance ou encore un
schma selon linterlocuteur auquel on sadresse. Voici des conventions que nous utilisons :
Serveur : machine physique o sont installs les binaires de MySQL.
Instance : processus de MySQL qui coute sur un port (par dfaut 3306).
Schma : ensemble dobjets (table, vue, vnement, procdures stockes...). Par schma, on pense au
schma conceptuel ou schma relationnel qui est une reprsentation graphique permettant de dcrire
le fonctionnement dune base de donnes. Il prsente les objets de la base, leurs caractristiques et
leurs relations.
Par abus de langage, MySQL appelait base de donnes un schma. Cela importe peu tant que vous
avez les mmes conventions que vos collgues.

Pour illustrer la suite de notre propos, nommons le schma monSchema ; il contient la


table maTable.

Les critres de choix dun moteur


Quels sont les critres de choix qui soffrent vous ? Les paramtres prendre en
considration reposent essentiellement sur les caractristiques de vos applications.
Chaque moteur a ses avantages et ses inconvnients.
Un moteur qui supporte les transactions va, par exemple :
tre plus rsistant aux pannes (matrielles) ;
avoir une meilleure concurrence ;
offrir davantage de flexibilit (commit, rollback) ;
ncessiter davantage de ressources : le moteur a, par exemple, besoin dun systme
disque plus puissant pour supporter les nombreuses critures.
Au contraire, un moteur qui ne prend pas en charge les transactions peut tre plus
rapide. Ce nest pas une certitude puisque les performances dpendent du type de
requtes, des index et de lapplication elle-mme.
Dans tous les cas, un moteur non transactionnel :
ncessitera moins despace disque ;

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

58

MySQL 5 Audit et optimisation

sera moins gourmand en mmoire ;


mais sera moins rsistant aux pannes.

Les principaux critres pour choisir son moteur sont les suivants :
le support des transactions ;
la concurrence : lorsquun nombre consquent de clients accdent aux mmes
tables ou donnes, la faon dont le moteur gre les verrous a une grande influence
sur la concurrence du moteur ;
les contraintes dintgrit (cls trangres) : une contrainte dintgrit renforce lintgrit des donnes en base. Prenons comme exemple un modle relationnel classique
1-N et partons du principe quune personne possde une et une seule adresse. La contrainte dintgrit va sassurer que chaque nouvelle adresse est bien associe une personne prsente dans la base. Le dveloppeur choisit o il doit implmenter sa
contrainte : soit au niveau de lapplicatif soit au niveau de la base de donnes ;
le stockage physique sur le disque dur, la taille des blocs...
les types dindex supports (B-tree, fulltext, hash...). Retenez pour le moment
quune bonne gestion des index est cruciale pour obtenir de bonnes performances
de la part de la base de donnes. Nous verrons de plus que chaque moteur implmente les index sa faon. Nous tudierons leurs points communs et diffrences,
en examinant, notamment entre MyISAM et InnoDB :
la gestion de la mmoire ;
les performances ;
les proprits spcifiques.

Moteurs disponibles : InnoDB, MyISAM, Merge,


Memory, Archive
Le moteur InnoDB
Support des cls trangres, transactionnel, fiable, mais aussi complexe, InnoDB est
un moteur qui ne se laisse pas dompter en quelques heures. Cependant, avec un peu
dentranement, quelques essais et avec laide de cet ouvrage, vous apprendrez tirer
le meilleur parti de ce moteur phare dans lunivers des moteurs de stockage disponibles aujourdhui sous MySQL. Les plus grands comptes Internet ne sy sont
dailleurs pas tromps : InnoDB est le moteur le plus utilis parmi les sites Internet
forte audience motoriss par MySQL.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

59

Figure 32

Quelques lments cls


du moteur InnoDB

Avant dentrer davantage dans le dtail du fonctionnement dInnoDB, revenons plus


prcisment sur quelques-unes de ses caractristiques principales qui le distinguent
notamment de MyISAM, le moteur par dfaut de MySQL. Une fois les grandes
lignes dessines, vous serez mme de dcider si InnoDB est le moteur quil vous
faut et mrite donc les efforts que vous consacrerez sa comprhension !
InnoDB est un des moteurs historiques de MySQL, le premier supporter les transactions ACID (atomicit, cohrence, isolation ou cloisonnement, durabilit ou conservation). Depuis 2008, le moteur InnoDB est disponible sous deux formats :
livr avec MySQL ;
sous la forme dun plug-in.
Il appartient InnoBase/Oracle. Depuis la version 5.1.38, le plug-in est livr par
dfaut. Cest de nos jours le moteur le plus utilis. La version plug-in a permis
InnoBase de ne plus tre dpendant des versions de MySQL.
Le mode plug-in apporte galement beaucoup de nouvelles fonctionnalits :
meilleures performances grce lamlioration du systme de verrou et de la
monte en charge pour les plates-formes multicurs ;
cration dindex plus performante ;
compression des donnes.
tant donn que le choix ventuel du transactionnel est un paramtre essentiel dun
moteur de stockage, nous prfrons prciser ce quest une transaction et le concept de
transaction ACID.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

60

MySQL 5 Audit et optimisation

B.A-BA Les proprits ACID


Une base de donnes transactionnelle doit respecter le modle ACID :
Atomicit : une transaction est soit compltement valide soit compltement annule.
Cohrence : une transaction ne doit pas laisser la base dans un tat incohrent.
Isolation : une transaction ne peut voir aucune autre transaction en cours dexcution.
Durabilit : lorsque le client est inform du succs de la transaction, les rsultats de
celle-ci sont conservs durablement.

BON SAVOIR Le MVCC


Un des atouts dInnoDB pour supporter de fortes charges repose sur le systme MVCC
(Multi Version Concurrency Control). Dans un environnement multiutilisateur, plusieurs
threads accdent aux ressources de faon concurrente. Afin que ces oprations
seffectuent dans les meilleures conditions possibles, un systme de contrle et de
partage des ressources est ncessaire. Il sagit du MVCC.
Pour une base de donnes, ce systme doit sassurer que :
Les transactions concurrentes respectent lintgrit de cette base.
Toutes les oprations peuvent tre srialises et rejoues.
Si une transaction est perdue le systme nest pas affect.
Si une transaction est annule (ROLLBACK), les modifications apportes seront supprimes.
Il existe plusieurs catgories de systmes permettant le contrle de la concurrence.
Les principaux sont :
Optimiste : la synchronisation de la transaction est retarde pour viter un blocage
des lectures/critures. Les transactions qui violent les rgles de synchronisation sont
annules.
Pessimiste : les transactions susceptibles de poser des problmes sont bloques ds
le dbut.
Plusieurs mthodes existent :
2PL, blocage en 2 tapes (Two-Phase Locking) ;
classement des transactions dans le temps ;
classement des transactions par commit ;
contrle de la concurrence des index ;
MVCC, plusieurs versions.
La mthode MVCC est utilise par la plupart des moteurs de stockages transactionnels tels que InnoDB, Falcon, PBXT... Cette mthode permet chaque utilisateur de
visualiser une version indpendante (un clich) de la base de donnes. Les modifications effectues par une personne (transaction concurrente) ne sont vues par les
autres utilisateurs quune fois quelles sont valides (COMMIT).
MVCC parvient rendre les transactions srialisables grce la date et des identifiants de transaction. Ainsi, celles-ci nont jamais attendre quun objet soit disponible car le moteur (dans ce cas InnoDB) maintient plusieurs versions du mme objet.
Voici une liste non exhaustive de SGBD implmentant galement le MVCC : Berkeley
DB, InterBase, Microsoft SQL Server, Oracle, PostgreSQL, Sybase...

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

61

Contrairement MyISAM, InnoDB est un moteur transactionnel. Il permet donc


au dveloppeur de grouper dun point de vue logique plusieurs instructions en une
seule. Le groupe dinstructions sera valid si le COMMIT est effectu ; dans le cas contraire un ROLLBACK annulera lensemble des modifications.
Un autre avantage dInnoDB est la concurrence, cest--dire la facult dun serveur
MySQL (par lintermdiaire de son moteur de stockage) servir davantage de
requtes dans le mme temps. En effet, contrairement MyISAM qui verrouille
lintgralit dune table le temps que celle-ci soit mise jour lors dun UPDATE ou dun
DELETE (les INSERT sont un cas part ; voir MyISAM et la variable systme
concurrent_insert tudie dans ce chapitre), InnoDB propose un verrouillage par
ligne beaucoup moins bloquant pour les accs concurrents. Cependant, y regarder
de plus prs, InnoDB utilise lui aussi en interne des systmes de verrouillage (notamment des index). Lensemble est malgr tout moins pnalisant que le systme de verrouillage par table employ par MyISAM. En cela, InnoDB est beaucoup plus
appropri un environnement mixte de lectures/critures que MyISAM.
Figure 33

La vie dune transaction dbute


en mmoire et se termine sur
disque si elle est valide.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

62

MySQL 5 Audit et optimisation

Figure 34

Le buffer pool et le tablespace


reprsents au sein
des structures principales
dInnoDB

Au niveau de sa structure, InnoDB utilise trois types de fichiers particuliers dans les
rpertoires suivants :
ibdata/ibdata1 tablespace partag ;
iblog/ib_logfileX fichiers qui vont stocker toutes les transactions qui sont
commites ;
data/monSchema/mytable.frm qui stocke comme pour MyISAM la structure de
la table utilise par MySQL pour valider les SQL.
Par dfaut toutes vos tables sont cres dans le tablespace partag. Il contient plusieurs informations :
le dictionnaire structure des tables, un peu comme MySQL et les fichiers .frm ;
les donnes et index ;
les logs dannulation (undo logs) qui vont permettre de faire des ROLLBACK des
transactions et de revenir ainsi ltat original.
Vous avez la possibilit de forcer InnoDB crer un tablespace par table
(innodb_file_per_table). Si vous activez cette option toutes les nouvelles tables
possderont leur propre tablespace, maTable.idb, contenant donnes et index. Le
tablespace partag ne disparat pas pour autant puisquil demeure indispensable pour
le fonctionnement du dictionnaire et pour les undo logs.
Pour des raisons de performance, InnoDB tente de mettre en cache le plus souvent
possible ses oprations dcriture. Lorsquun enregistrement est insr (ou modifi),
une page mmoire est alloue dans une mmoire tampon appele le buffer pool.
InnoDB conserve ces pages dans ce buffer tant quil le peut afin de ne pas avoir les
crire sur le disque. Les informations contenues y sont volatiles et seront donc perdues si le serveur est redmarr. Dans un tel cas, InnoDB tire parti de son journal des

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

63

transactions (ib_logfileX) et dtecte que des donnes contenues dans ce journal


nont pas t rpercutes sur le disque. Les transactions manquantes sont alors
rejoues. Ce mcanisme est appel mode de rcupration ou recovery mode. Notez
quune fois dans ce mode, le serveur est considr en maintenance et quaucune connexion nest possible.
ASTUCE Sortir une table dun tablespace partag
Si vous choisissez dutiliser innodb_file_per_table, les tables ventuellement dj prsentes
dans le tablespace commun ne seront pas transformes : ce paramtre sapplique en effet sur les nouvelles tables. Cependant, excuter un ALTER sur une table se trouvant lintrieur du tablespace partag
en provoquera la sortie. En effet, la commande ALTER cre une nouvelle table.
Dernier dtail : cette nouvelle table disposera de son propre tablespace mais lespace correspondant ne sera
pas libr dans le tablespace commun. La seule faon de rduire la taille dun tablespace commun est :
1. dexporter les donnes (backup logique),
2. de couper le serveur MySQL,
3. de supprimer le tablespace et les fichiers de log,
4. puis de redmarrer le serveur et recharger les tables exportes avec innodb_file_per_table.
Une opration coteuse...
La taille du tablespace dInnoDB est surveiller : elle crot ds que le moteur a besoin de place. Ceci est
valable y compris avec le rglage innodb_file_per_table, mais dans une moindre mesure bien sr.

Lorsque le buffer pool est purg, les donnes sont crites sur le disque. Ce flush se
produit quand le buffer pool atteint son seuil maximal de pages modifies ou bien si
un checkpoint est atteint (le journal de transactions ib_logfile1 est plein et les critures seffectuent dsormais sur le second : ib_logfile2). InnoDB spcifie alors dans
son journal de transactions que le buffer pool a t vid.
POUR ALLER PLUS LOIN
Vous trouverez plus dinformations sur InnoDB dans le chapitre consacr au paramtrage du serveur.
Deux adresses pour aller plus loin :
B http://dev.mysql.com/doc/refman/5.1/en/innodb.html
B http://www.innodb.com/.

MyISAM
MyISAM (http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html) est le moteur par
dfaut de MySQL depuis la version 3.23. Il nest pas fourni sous la forme dune
bibliothque, il est donc impossible de le supprimer. Toutes les tables systme lutilisent. Il est toujours trs employ du fait de sa simplicit. Il sappuie sur ISAM, un
des premiers moteurs, auquel on a ajout quelques fonctionnalits. Les informations

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

64

MySQL 5 Audit et optimisation

dune table MyISAM sont stockes dans trois types de fichiers diffrents qui sont
situs par dfaut dans le rpertoire /var/data/mysql/monSchema/ :
maTable.frm qui contient la structure de la table.
maTable.MYD qui contient les donnes.
maTable.MYI qui contient les index.
Mme si vous utilisez un moteur diffrent de MyISAM, vous trouverez toujours un
fichier .frm pour vos tables : MySQL en a besoin pour valider les requtes SQL.
Figure 35

Principaux lments du moteur


MyISAM sur disque et en
mmoire

MyISAM se sert dun systme de verrou bas sur le fichier : pour accder un enregistrement, MySQL dpose un verrou en lecture. En revanche, pour crire un enregistrement, MySQL applique un verrou en criture. Seul ce dernier est exclusif. Il est donc
possible dexcuter plusieurs requtes simultanes en lecture mais une seule en criture.
Ce mcanisme est lorigine dune des faiblesses du moteur MyISAM : une contention au niveau des tables. En effet, si votre application gnre une grande quantit
dcritures en parallle, elle va devoir attendre que la table MyISAM soit disponible.
Les critures seront donc srialises (effectues les unes aprs les autres). En gnral
MyISAM est conseill pour les applications qui demandent beaucoup plus de lectures que dcritures, jusqu un certain point.
Un autre aspect qui ne penche pas en la faveur de ce moteur est celui de la corruption
potentielle des fichiers. Une table soudainement illisible reprsente bien souvent le
symptme dune corruption de fichier. Pas de panique, vous navez encore rien perdu,
mais que sest-il pass ? Les raisons sont varies et MySQL a pour le moment sim-

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

65

plement dtect une incohrence. Il est alors ncessaire de rparer la table corrompue
avec la commande REPAIR TABLE (ou les programmes myisamchk/mysqlcheck).
Effectuez une sauvegarde pralable si possible, avec mysqlhotcopy, par exemple.
Par dfaut MyISAM supporte les insertions concurrentes pour rduire au maximum
les contentions au niveau des lectures. Si votre fichier nest pas fragment (absence de
trous car vous navez effac aucun enregistrement), une insertion peut seffectuer en
fin de fichier pendant quune autre requte lit la table. De mme, si plusieurs insertions surviennent en mme temps, elles sont regroupes (mises en buffer, action
paramtrable en ajustant delay_key_write) et excutes en squence sans pour
autant bloquer les lectures.
ce sujet, concurrent_insert est une variable systme retenir. Grce elle, il est
possible de contrler plus finement les mcanismes dinsertion.
Les trois valeurs quelle peut prendre sont 0, 1 et 2 :
0 : les INSERT sont considres comme les autres requtes dcritures et sont donc
verrouilles par les SELECT.
1 : (par dfaut) les INSERT ne sont pas bloques, les SELECT non plus sil ny 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 verrouilles par les SELECT : tout est donc plac en fin
de fichier.
Figure 36

La fragmentation en image

Si votre application gnre un grand nombre de DELETE, les fichiers de donnes


seront fractionns ce qui a un impact important sur les performances. Nous vous
conseillons de dfragmenter rgulirement vos tables MyISAM. La commande suivante permet de mener cette opration :
mysql>OPTIMIZE TABLE MaTable;

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

66

MySQL 5 Audit et optimisation

MyISAM fournit galement des outils comme myisamchk quil faut veiller ne pas
utiliser sur une base en activit ! Vous devez soit stopper votre serveur MySQL, soit
poser un verrou en lecture pour tre certain que personne ne modifiera les donnes.
En effet, si deux programmes accdent aux donnes en parallle vous avez de grandes
chances de les corrompre.
fonctionne de la faon suivante :
1 Dtecte si la table est fragmente et la compacte.
2 Trie les index si ncessaire.
3 Met jour les statistiques (cette action peut galement tre effectue indpendamment avec la commande ANALYZE TABLE).

OPTIMIZE TABLE

Les statistiques sont utilises par loptimiseur de MySQL pour calculer la meilleure
faon dexcuter une requte SQL.
Pour les tables InnoDB, la commande OPTIMIZE TABLE revient excuter un ALTER
TABLE qui recre la table, les index et les statistiques tout en librant les espaces inutiliss.
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 |

Quoi quil en soit, si votre table contient beaucoup de donnes, une commande telle
que REPAIR ou OPTIMIZE est susceptible de durer jusqu quelques heures pour des
tables de plusieurs Go. Laccs la table concerne est alors bloqu en criture.
Revenons un instant sur la commande ANALYZE

TABLE

que nous venons dvoquer :

mysql> ANALYZE TABLE MaTable;

Cette commande analyse et stocke la distribution des cls, en dautres mots, calcule
les statistiques. Pendant cette action, la table est verrouille avec un READ LOCK pour
MyISAM et un WRITE LOCK en InnoDB. Pour une table MyISAM, cela quivaut
myisamchk --analyze.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

67

Tableau 31 Contexte pour analyze, repair et optimize sous MyISAM et InnoDB

MyISAM

InnoDB

ANALYZE

tide

chaud

REPAIR

oui

n/a

OPTIMIZE

tide

tide ALTER + ANALYZE

B.A.-BA Chaud, froid ou tide ?


Voici un petit lexique concernant les diffrents tats dun serveur MySQL. Celui-ci peut-tre dfini comme
froid (cold), tide (warm) ou chaud (hot).
Serveur

Verrou

Commande

cold (froid)

teint

n/a

aucune

warm (tide)

dmarr

criture/lecture

possibilit de se connecter, requtes en attente

hot (chaud)

dmarr

aucun

possibilit de se connecter, requtes excutes

Contentions, corruptions... Nallez pas croire que le moteur MyISAM na que des
inconvnients !
Outre sa rapidit, lorsquil est correctement employ et configur, ce moteur apporte
des fonctionnalits intressantes comme :
les index FULLTEXT ;
la possibilit de prfixer les index pour les champs de type texte (CHAR, VARCHAR,
TEXT) ou BLOB ;
la compression ;
les index spatiaux GIS ;
le dplacement facile des fichiers dun serveur un autre.

Mcanismes internes de MyISAM et formats de stockage


MyISAM supporte trois formats de stockage :
Statique : cest le cas dune table qui ne contient pas de colonne taille variable
(VARCHAR, VARBINARY, BLOB ou TEXT). Ce format est le plus simple et le plus scuris (vis--vis de la corruption) mais galement le plus rapide.
Dynamique : format utilis par les tables ayant des colonnes taille variable. Il
occupe moins de place sur le disque.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

68

MySQL 5 Audit et optimisation

Compress : ce format transforme la table en lecture seule et comme son nom

lindique compresse au maximum les donnes pour prendre le moins de place possible sur le disque (commande myisampack).
Les limites en termes de nombre de lignes sont dfinies par votre systme (taille sur
le disque, serveur 32/64 bits...). Le pointeur daccs aux donnes est par dfaut de
6 octets (4 prcdemment) ce qui correspond 256 To de donnes. Si ncessaire, il
est possible de passer ce pointeur 8 octets.
Si vous utilisez MySQL depuis les versions 3.23, vous avez certainement dj rencontr une erreur sur une table volumineuse, indiquant que vous avez atteint le
nombre maximal de lignes. La solution consiste alors modifier les paramtres
MAX_ROWS et AVG_ROW_LENGTH pour changer ainsi la taille du pointeur. videmment,
cette opration ncessite lutilisation de la commande ALTER TABLE qui bloquera la
table en criture le temps de lopration.
RAPPEL Mcanisme dune commande ALTER TABLE
Voil les tapes suivies lors de la modification de la structure dune table T par la commande ALTER
TABLE T :
1. validation si besoin de la transaction ouverte sur la table (COMMIT) ;
2. rcupration dun verrou en lecture ;
3. cration dune table temporaire (TT1) ayant la mme 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. libration du verrou.

Le serveur MySQL lui-mme utilise MyISAM et offre deux exemple de tables ayant
des formats statique et dynamique respectivement.
La base mysql, qui contient les informations relatives MySQL, utilise elle-mme le
moteur de stockage MyISAM :
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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3
Avg_row_length:
Data_length:
Max_data_length:
Index_length:
Data_free:
Auto_increment:
Create_time:
Update_time:
Check_time:
Collation:
Checksum:
Create_options:
Comment:

69

440
3080
123848989752688639
5120
0
NULL
2008-08-09 11:36:46
2009-07-17 16:12:21
2008-08-09 11:36:53
utf8_bin
NULL
Database privileges

mysql> SHOW TABLE STATUS LIKE 'event' \G


*************************** 1. row ***************************
Name: event
Engine: MyISAM
Version: 10
Row_format: Dynamic
Rows: 2
Avg_row_length: 190
Data_length: 380
Max_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

Vous constatez que ces deux tables nont pas le mme format (Row_format).
Notez le champ Data_free susceptible le cas chant dindiquer que la table a besoin
dtre optimise (ici 0 signifiant quil nest pas besoin dxcuter la commande
OPTIMIZE TABLE).

Le moteur MERGE pour agrger plusieurs tables MyISAM


Il ny a pas si longtemps, MySQL ne supportait pas encore le partitionnement. Pour
remdier cela, il tait possible (et a lest toujours) de simuler celui-ci manuellement
avec une table MERGE compose de plusieurs tables MyISAM de structures identiques.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

70

MySQL 5 Audit et optimisation

Lapplication ne voit alors que la table T, alors que par ailleurs elle pourrait accder
directement aux tables T1, T2... composant T. La table T utilise en effet le moteur
MERGE alors que physiquement les tables sous-jacentes, par exemple les tables T1,
T2 et T3 sont toutes en MyISAM.
Figure 37

La table T utilise le moteur


MERGE, T1, T2 et T3
sont en MyISAM.

Il existe quelques limitations ce mcanisme. Tout dabord, toutes les tables doivent
possder une structure identique.
Linsertion dans une table MERGE est soumise la condition davoir pralablement
dfini la table dans laquelle insrer les donnes. La marge de manuvre cet gard
est faible puisque seule la premire ou la dernire table de lensemble peuvent tre
choisies (INSERT_METHOD=LAST ou INSERT_METHOD=FIRST).
Dun point de vue logique il est possible de se reprsenter une table MERGE comme
une vue dans laquelle nous pourrions crire. tant bases sur le moteur MyISAM,
les tables MERGE ont les mmes avantages et inconvnients. Concernant la corruption ventuelle dun fichier, la corruption dune table sous-jacente entrane par dfinition celle de la table MERGE.
Le moteur MERGE reprend le concept des partitions qui peut tre utilis pour
sparer une table volumineuse en plusieurs plus petites, facilitant ainsi ladministration de la base. En effet, considrons par exemple un systme de logs remplissant une
table par jour ( T1 T7 )... Une table MERGE T permettrait ici dobtenir une vue sur
la semaine. Il serait alors possible chaque jour deffacer les donnes de la semaine

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

71

prcdente beaucoup plus rapidement. La commande DELETE est en effet potentiellement trs lente sur de trs grosses tables, la suppression dune table complte tant
beaucoup plus rapide.
Larrive du partitionnement depuis la version 5.1 de MySQL sonne-t-elle le glas
des tables MERGE ? Nous pensons que non. Si certains systmes utilisant MERGE
vont certainement profiter des avantages du partitionnement (les requtes utilisant la
cl de partitionnement peuvent accder directement la partition voulue), le bnfice nest pas automatique. Il sagit dcrire :
mysql>TRUNCATE T1;

au lieu de :
mysql> DELETE FROM t WHERE jour = 1;

De grands comptes utilisent toujours le moteur MERGE pour stocker des chiffres
daudience sur 2 jours.

Le moteur MEMORY (anciennement HEAP)


Anciennement connu sous le nom de HEAP, toutes les donnes et les index sont
stocks en mmoire vive. Laccs aux donnes est alors trs rapide du fait de labsence
daccs disques. Attention cependant, lintgralit des donnes tant stocke en
mmoire, celles-ci seront perdues en cas de redmarrage du serveur. Seule la structure de la table, matrialise sous la forme du fichier frm, subsistera.
Les verrous poss par le moteur MEMORY seffectuent, tout comme avec
MyISAM, au niveau de la table toute entire.
Un des dangers du moteur MEMORY est quil risque de consommer davantage de
mmoire que le systme nen dispose rellement. Dans un tel cas le serveur est alors
forc dutiliser sa mmoire de swap, cest--dire sur disque, entranant une chute des
performances.
Un autre point important est que ce moteur ne supporte que les types de donnes
dits fixes. Ainsi, un champ VARCHAR(100) sera automatiquement transform en
CHAR(100), ce qui a pour effet de gaspiller de la mmoire si vous ne stockez que 10
caractres.
Le moteur MEMORY est parfois utilis dans le cadre doptimisations. Prenons
lexemple dun site Internet dont la table LOGIN stocke les utilisateurs actuellement
prsents sur le site. Utiliser le moteur MEMORY pour cette fonctionnalit est peu
risqu (en cas de darrt brutal les utilisateurs devront nanmoins se reconnecter).

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

72

MySQL 5 Audit et optimisation

Pour prendre un raccourci, il est possible dimaginer une table MEMORY comme
une table MyISAM en mmoire.
La plupart des moteurs de stockage ne grent que des algorithmes dindex de type B-tree.
MEMORY quant lui supporte galement les index de type HASH. Une table de
hachage est alors utilise. Lorsque MySQL doit crer une table temporaire afin de
rsoudre une requte (en gnral dans le cas de jointures ou de tris), le serveur utilise des
tables MEMORY si la taille ne dpasse pas une certaine limite. Dans le cas contraire (il
sagit de la plus faible valeur entre les variables systme tmp_table_size et
max_heap_table_size), MySQL se rabat sur une table MyISAM. Un index de type
HASH est le type par dfaut pour une table MEMORY. Ce type dindex est trs rapide
pour des requtes dgalit (WHERE champ = X) mais ne fonctionne pas pour une
recherche de type WHERE champ > X.
Si vous avez besoin de ces deux types de requtes, nhsitez pas rajouter un index de
type B-tree.

Le moteur ARCHIVE pour un archivage compress


Ce moteur stocke les donnes sous une forme compresse. Les seuls types de
requtes gres sont SELECT et INSERT et les index ne sont pas accepts. En contrepartie de ces restrictions, le gain de place sur disque est considrable ce qui fait
dARCHIVE un moteur idal pour archiver des donnes. Les taux de compression
varient autour de 70 %. Les mcanismes de compression et dcompression utiliss
par le moteur ARCHIVE consomment du CPU mais cest ce prix que lespace
disque est prserv. Les performances sont susceptibles daugmenter en lecture
puisque les nombres de blocs disque parcourir sont moins nombreux du fait de la
compression des donnes.
Vous trouverez davantage dinformations sur http://dev.mysql.com/doc/refman/5.1/en/archivestorage-engine.html.

Autres moteurs
XtraDB
Impossible dvoquer les moteurs de stockage InnoDB sans parler dun des meilleurs
moteurs du moment : XtraDB de Percona. Cest un moteur hybride car reposant sur
une volution du plug-in InnoDB. Percona est une socit de conseil dont lactivit
principale repose sur MySQL avec une spcialisation oriente vers la performance.
Ses consultants sont principalement confronts des problmes de montes en
charge autour de MySQL et dInnoDB. Ces derniers ont ajout des fonctionnalits

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

73

et des correctifs pour leurs clients, les Google patches, qui permettent de contourner
certaines contentions au niveau serveur.
B http://www.percona.com/

Falcon
Il tait possible de tester le moteur Falcon avec la version 6.0 de MySQL (en bta).
Cette version a depuis t retire mais pourrait rapparatre. Ce moteur a t cr par
MySQL AB en vue de supporter les transactions et avec pour objectif de monter en
charge linairement. Depuis le rachat par Oracle, beaucoup dinterrogations subsistent quant son devenir. Que faire en effet de deux moteurs concurrents sachant
quOracle investit dj dans InnoDB ? De plus, mme si celui-ci prsente des fonctionnalits intressantes, les premiers rsultats ne sont pas encore trs prometteurs.
B http://dev.mysql.com/doc/falcon/en/index.html

Federated
Le moteur Federated permet daccder des donnes situes sur un serveur distant.
Les performances sont assez limites surtout pour des requtes traitant beaucoup de
donnes. Il est possible de se connecter une base PostgreSQL. La maintenance de
tables distantes peut galement poser problme sans parler des ventuels inconvnients de connexion entre les diffrents serveurs MySQL.
B http://dev.mysql.com/doc/refman/5.1/en/federated-storage-engine.html

Example
Le moteur Example ne fait rien. Il sert dexemple aux dveloppeurs pour implmenter leur propre moteur de stockage.
B http://dev.mysql.com/doc/refman/5.1/en/example-storage-engine.html

Blackhole
Une table utilisant le moteur Blackhole ou trou noir ne stocke absolument rien. Il y a
deux types dapplications pour ce moteur :
validation des requtes SQL ;

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

74

MySQL 5 Audit et optimisation

distribution des donnes sur diffrents serveurs grce un filtrage opr au travers

de la rplication (nous parlons dans ce cas de binlog proxy).


En effet, puisque la rplication ne contrle pas le format des tables, il est possible dimaginer un master avec deux tables en InnoDB, T1 et T2, et un esclave sur lequel seraient
installes T1 en MyISAM et T2 en Blackhole. Les requtes affectant T2 seraient rejoues
par le thread SQL sur lesclave sans pour autant stocker les donnes sur disque. Vous
trouverez plus de dtails ce sujet au chapitre 8 consacr la rplication.
B http://dev.mysql.com/doc/refman/5.1/en/blackhole-storage-engine.html

CSV
Le moteur CSV permet de stocker les informations sous la forme CSV (Comma
Separated Value). Il sagit dun fichier texte o les valeurs sont spares par une virgule
qui permet de faciliter les changes vers dautres applications.
B http://dev.mysql.com/doc/refman/5.1/en/csv-storage-engine.html

IBMDB2I
Le moteur IBM DB2I permet dutiliser MySQL et de stocker des donnes dans une
base de donnes IBM DB2 tournant sur un serveur IBM i. Lide est de partager les
donnes entre des applications MySQL et des applications DB2 pour i. Cest une
utilisation de MySQL assez peu rpandue.
B http://dev.mysql.com/doc/refman/5.1/en/se-db2.html

NDB (Network Database)


Le moteur NDB est utilis par MySQL Cluster, la solution haute disponibilit de
MySQL (MySQL HA) et ne peut donc pas tre employ sparment. Il a t achet
Sony Ericsson en 2003. Vous trouverez plus dinformations sur NDB dans le chapitre
traitant de la rplication.
B http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-overview.html

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

75

Moteurs communautaires et autres


Linterface fournie par MySQL permet chacun de dvelopper son propre moteur
de stockage avec comme prrequis une bonne connaissance en C. Dautres moteurs
sont disponibles sur Internet, quils soient Open Source ou propritaires, communautaires ou pas. Ces moteurs ne sont pas officiellement grs par MySQL et sont
donc utiliser vos risques et prils. Lorganisme dveloppant le moteur soccupe du
support, de la documentation et des bogues. La plupart des moteurs sont rfrencs
sur la forge MySQL :
B http://forge.mysql.com/

Maria
lorigine MARIA devait tre une volution de MyISAM corrigeant les problmes
de corruptions qui apparaissent assez souvent aprs un arrt accidentel. Puisque dans
le pass ISAM a laiss sa place MyISAM, nous nous attendions ce que MARIA
remplace MyISAM. Si vous suivez lactualit de MySQL, vous savez que MARIA
est dsormais le moteur par dfaut du projet MariaDB, une version alternative de
MySQL. MARIA gre les transactions en utilisant MVCC et pose des verrous au
niveau des lignes. La plupart des moteurs acceptant les transactions dans le monde
MySQL emploient le mme algorithme. Sur MariaDB les tables systme sont au
format Maria. noter que derrire Maria et MariaDB se trouvent entre autres
Monty (Widenius), un des fondateurs de MySQL.
Maria fonctionne en deux modes :
1 amlioration de MyISAM ;
2 transactionnel, MVCC.
B http://askmonty.org/wiki/index.php/MariaDB

PBXT
Un des moteurs les plus en vue en ce moment est PrimeBase XT. Il a t conu pour
les environnements web forte concurrence et utilise une architecture base sur
lcriture de fichiers de logs. Il a t crit lorigine par Paul McCullagh pour contourner des problmes rencontrs dans le domaine de ldition avec de gros volumes
dinformation stocks dans des BLOB. Il contient des algorithmes capables de tirer
parti des disques SSD.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

76

MySQL 5 Audit et optimisation

Figure 38

Architecture gnrale du
moteur PBXT

Vous trouverez davantage dinformations sur http://www.primebase.com/xt/download/pbxt-uc2008.pdf et http://www.linux-mag.com/cache/7462/1.html.


B http://www.primebase.org

BLOB Streaming Engine (MyBS)


MyBS devait tre lorigine une volution de PBXT. Les deux moteurs taient dvelopps en parallle par Primebase. Larchitecture de MyBS a t modifi et transforme
dsormais MySQL en un serveur de mdias capable de diffuser (streaming) images,
films, mp3... et autres objets binaires (BLOBS) partir de la base ou vers la base. Le
principe consiste stocker les mtadonnes sur votre serveur MySQL et les donnes
sur le Cloud. La dernire version utilise Amazon S3. Le client demande au serveur une
donne et est redirig sur lenregistrement stock sur S3.
B http://blobstreaming.org/

Mdbtools
Le moteur Mdbtools permet de lire dans MySQL des donnes stockes sous MS
Access.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

77

SolidDB pour MySQL est un moteur fourni par Solid, qui a t rachet par IBM, et
bas sur leur propre base de donnes SoliDB. lorigine, solidDB fonctionne selon
deux modes :
1 base de donnes en mmoire ;
2 base de donnes relationnelle.
Historiquement, il tait utilis comme base de donnes embarque dans des quipements de communication. Vous trouverez davantage dinformations sur http://www01.ibm.com/software/data/soliddb/ et http://sourceforge.net/projects/soliddb/.
B http://sourceforge.net/projects/mdbtools/

Kickfire
Kickfire propose plus quun moteur de stockage. En effet, elle fournit galement le
serveur sur lequel va tourner leur moteur. Il est orient datawarehouse.
B http://www.kickfire.com/

TokuDB
TokuDB est un nouveau venu qui incorpore la technologie fractale de Tokutek. Les
performances affiches sont assez tonnantes. Cest un moteur suivre.
B http://tokutek.com

Spider
Spider est lun des derniers venus surveiller de trs prs. Ce moteur est bas sur le
code de partitionnement des tables. Au lieu de stocker les donnes sur la machine,
Spider permet de rfrencer les serveurs o se trouvent linformation recherche. Il
excute ensuite la requte sur le serveur distant et retourne le rsultat. Il reste tester
la stabilit dune telle solution qui pourrait tre utile selon les applications.
B http://launchpad.net/spiderformysql

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

78

MySQL 5 Audit et optimisation

Rethinkdb
Rethinkdb vient tout juste de sortir et se trouve encore en version pr-alpha. Il est cens
tre optimis pour les disques SSD. Mme sil vaut la peine dtre mentionn, il est
encore trop jeune pour en tirer des conclusions pertinentes.
B http://www.rethinkdb.com/

Le monde des moteurs de stockage est assez vaste, mme si au final, le modle MVCC
est assez rcurrent. Perfectionnez-vous dans le moteur que vous utilisez actuellement
pour tre certain den avoir atteint les limites avant de choisir une alternative.
Les rachats successifs de MySQL par Sun puis de Sun par Oracle ont boucl la
boucle : MySQL et InnoDB se retrouvent dsormais dans la mme entreprise. Le
monde des moteurs na pas fini dvoluer et lavenir est plein de promesses ce sujet !
Tableau 32 Rcapitulatif des moteurs MySQL

Socit

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

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

MySQL AB

Example

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

MySQL AB

Blackhole

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

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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Les moteurs de stockage


CHAPITRE 3

79

Tableau 32 Rcapitulatif des moteurs MySQL (suite)

Socit

Moteur

Verrou

Transaction

Site

MySQL AB

NDB

ligne

oui

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

Monty Program Maria


Ab

ligne

oui/non, dpend http://askmonty.org/wiki/index.php/


du mode
MariaDB

PrimeBase
PBXT Systems GmbH PrimeBase XT

ligne

oui

http://www.primebase.org

PrimeBase
PBMS - Blob
Systems GmbH Streaming

ligne

oui

http://www.blobstreaming.org/

Brian Burns
(lauteur)

Mdbtools

table

non

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

IBM/Solid

SolidDB

ligne

oui

http://www-01.ibm.com/software/
data/soliddb/

Kickfire

Kickfire

http://www.kickfire.com/

Tokutek

TokuDB

http://www.tokutek.com

ST Global

Spider

http://www.spiderformysql.com

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

4
Surveiller son serveur MySQL

Un serveur MySQL utilise plusieurs centaines de variables dites systme ou de


statut. Elles refltent respectivement la configuration et ltat du serveur. Ce chapitre
dcrypte les variables de statut et prsente les diffrents outils de surveillance qui les
exploitent.
Quil soit dans lurgence ou non, un administrateur de bases de donnes doit tre
capable de prendre rapidement le pouls de la situation sur un serveur donn. En
effet, lorsquun serveur MySQL rencontre un incident (surcharge, arrt brutal, ralentissements, perte de connexion...), le DBA doit comprendre ce qui sest pass, quil
ait lui-mme vcu le problme en direct ou pas. Cette enqute dbute bien souvent
grce aux logs gnrs par le serveur MySQL et/ou le systme dexploitation.
Ces logs existent sous diffrentes formes : crits sur disque en simples fichiers texte,
insrs dans une table de la base, ou encore matrialiss en compteurs indiquant la
survenue de tel ou tel vnement.
Ce chapitre permet, dune part, de comprendre quels types de variables le serveur
MySQL utilise et comment il les emploie. Il prsente, dautre part, une slection des
diffrents outils de surveillance, quils soient conus par MySQL ou pas.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

82

MySQL 5 Audit et optimisation

O trouver les informations pertinentes ?


Le comportement dun serveur MySQL se dessine avant mme son dmarrage au
travers de son fichier de configuration couramment nomm my.cnf. Une fois en
marche, il est possible de contrler ltat du serveur grce la consultation de ses
variables dites de statut.
Cette consultation peut seffectuer de faon brute en accdant manuellement aux
valeurs de ces variables laide dun client MySQL ou de faon assiste par le biais
doutils ou de scripts permettant une lecture plus rapide et ordonne de ces centaines
de valeurs.

Variables systme et variables de statut


DFINITION Variables systme ou de statut
On appelle variables systme les valeurs retournes par la commande
mysql > SHOW GLOBAL VARIABLES;

Les variables de statut sobtiennent via


mysql > SHOW GLOBAL STATUS;

Les variables systme sont en lecture seule, on ne peut pas les modifier.
Elles sont plusieurs centaines dans chaque catgorie (entre 200 et 300 occurrences).

Les variables de statut sont lhonneur dans ce chapitre. Elles constituent la source
principale dinformation des outils de surveillance que nous allons voquer, quils
soient fournis par MySQL ou soient le fruit de dveloppements extrieurs.
Nanmoins, impossible dvoquer ce type de variables sans revenir rgulirement aux
variables systme. Ces dernires ont en effet bien souvent une influence sur les premires.
Un exemple : les performances des tables InnoDB sont trs influences par le paramtre innodb_buffer_pool_size. Sa valeur agit sur une multitude de variables de
statut relatives InnoDB ou au serveur en gnral.
ALTERNATIVE Rcuprer les variables systme ou de statut
Si vous prfrez obtenir les informations issues de la commande mysql > SHOW GLOBAL
VARIABLES; sans lancer le client MySQL vous pouvez arriver vos fins en une seule ligne en saisissant
directement 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;.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

83

Les variables systme sont dtailles dans le chapitre 8 consacr loptimisation du


serveur MySQL. Nous nous concentrons ici sur la faon de contrler le bon fonctionnement dun serveur.

Quels outils choisir ?


Il existe une multitude doutils permettant de contrler ltat dun serveur MySQL.
Nous pouvons les diviser en trois grandes catgories.
Les outils ou commandes fournis par MySQL, comme : SHOW INNODB STATUS,
mysqladmin... Vous tes, dans ce cas, certain de pouvoir en disposer sur toutes les
installations.
Les outils systme : iostat, vmstat, top... Ces outils non spcifiques MySQL
sont soit inclus dans le systme dexploitation, soit trs couramment dploys.
Leur comportement est peu prs le mme selon les systmes dexploitation. Ils
permettent de mesurer limpact de MySQL sur le serveur : utilisation des disques,
des processeurs...
Les outils externes : mysqlreport, la suite Maatkit, mytop, innotop... Ce sont
souvent des scripts Perl quil est ncessaire de tlcharger sur les sites de leurs
auteurs sans oublier les ventuelles librairies (Perl) manquantes. Il ny a aucune
garantie que ces scripts soient dploys sur vos machines de production : ce point
est donc vrifier avant de compter dessus le jour J.
SAVOIR Variables systme et my.cnf
Les variables systme dterminent le comportement de votre serveur MySQL. Suivez ce lien pour une liste
exhaustive (http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html). La porte (session
seulement ou tout le serveur) et le caractre modifiable chaud de chaque variable systme sont indiqus. Cest un lien conserver en bonne place dans vos favoris MySQL. Il existe le mme pour les variables de statut...
Toutes les variables systme possdent une valeur par dfaut charge au dmarrage du serveur MySQL.
Ces valeurs prdfinies seront conserves par les variables sauf si ces valeurs sont redfinies dans un
fichier de configuration tel que le fameux my.cnf lors du dmarrage du serveur. Une fois celui-ci
dmarr, toutes les variables qui ne sont pas en lecture seule peuvent tre modifies soit au niveau global (pour tout le serveur), soit au niveau de la session initie par le client MySQL.

Hormis les outils systme dont la vocation est plutt de surveiller diffrentes mtriques du systme lui-mme, les outils de surveillance spcifiques MySQL reposent
sur ses variables de statut. Ds lors, il est important de distinguer parmi les centaines
de variables disponibles, quelles sont les grandes familles de ces variables les plus
mme de vous clairer sur la situation dun serveur.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

84

MySQL 5 Audit et optimisation

Pouvoir lire de faon brute quelques variables cls permet dj de se faire une ide de
ce qui se passe sur un serveur. Il est ensuite plus ais de comprendre le compte-rendu
gnr par un script ou programme de surveillance. Cela permet en effet daffiner les
rsultats, de les relativiser : une valeur peut paratre critique aux yeux dun script de
surveillance alors que cest peut-tre tout simplement le DBA (vous ?) qui avez
dsactiv la mise en cache sur certaines requtes, par exemple.
ATTENTION Une valeur peut en cacher une autre
Il ne suffit pas de lire les valeurs dfinies dans le fichier my.cnf dun serveur MySQL pour tre certain
du contenu dune variable systme.
il y a deux raisons cela :
condition de dtenir le privilge SUPER, certaines variables sont redfinissables chaud via la commande SET GLOBAL, et peuvent donc avoir t modifies depuis leur valeur initiale dfinie dans
my.cnf. Par exemple :
SET GLOBAL sort_buffer_size=1000000 modifie chaud pour lensemble du serveur la
variable sort_buffer_size.
En ce qui concerne les variables dites read-only, autrement dit non modifiables chaud, leurs valeurs
sont dfinies lors de la lecture initiale de my.cnf. Celui-ci a donc trs bien pu voluer depuis le
(re)dmarrage du serveur et ne plus reflter la vritable valeur dune variable (cas dune valeur modifie
dans my.cnf en prvision dun redmarrage ultrieur).
En consquence, 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 dinclure des fichiers externes my.cnf grce la fonction include ; noubliez
pas de prendre en compte ce paramtre lors de la lecture dun fichier de configuration :
!include /home/mydir/myopt.cnf

SAVOIR Diffrence entre un client et un outil MySQL


Ne pas confondre un client MySQL tel que mysql, mysqladmin... et un script/programme comme myisamchk
par exemple. Ce dernier vrifie et rpare les tables MyISAM mais sans se connecter au serveur ; ce nest
donc pas un client. Concernant myisamchk, il est conseill de sauvegarder les tables concernes avant de
lutiliser. De mme un verrouillage de celles-ci ou une coupure du serveur MySQL pendant lopration est
fortement recommand afin de ne pas corrompre les donnes.

Intrt des outils de surveillance


Rapidit et automatisation sont les deux avantages des outils de surveillance.
Prenons un exemple trs simple. Comment calculer lefficacit du rglage de la
variable key_buffer_size ?

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

85

B.A.-BA key_buffer_size
key_buffer_size est lune des variables serveur les plus importantes pour le moteur MyISAM. Il
sagit de la taille du cache des index. Notez quil est possible sous ce moteur de crer des caches dindex
ddis pour une table.

La formule est la suivante :


efficacit = 1 - taux dchec

le taux dchec se mesurant de la sorte : key_reads / key_read_requests.


Autrement dit, on effectue le rapport entre le nombre de lectures disque dun bloc
dindex sur le nombre de demandes de lectures du bloc dindex partir du cache. Si
tous les blocs demands se trouvent dj dans le cache, on obtient 0 et une efficacit
de 1 (cas idal thorique).
La liste des variables de statut est longue : http://dev.mysql.com/doc/refman/5.1/en/server-statusPour vous y retrouver, vous pourriez apprendre par cur les 300 lignes,
ou les croiser manuellement entre elles afin de donner du sens certaines. Tout cela
est effectivement possible manuellement mais serait extrmement fastidieux.

variables.html.

Lutilit de loutil ou du script de surveillance qui vous convient est dobtenir rapidement une photographie de ltat de votre serveur MySQL. Il est en effet hors de
question deffectuer des oprations manuelles que lon soit en situation durgence ou
non (un DBA na pas de temps perdre).
Il existe de nombreux outils de diagnostic ou de surveillance dans la galaxie MySQL.
Les plus efficaces sont ceux... que lon connat le mieux !
Nhsitez pas en tester plusieurs et retenez ceux avec lesquels vous tes le plus laise.

Outils et commandes fournis par MySQL


De tous les scripts de surveillance ou outils que nous passerons en revue ultrieurement, la commande SHOW GLOBAL STATUS; est une des sources les plus importantes
de remonte dinformations dun serveur MySQL.
Cette commande, tout comme mysql
systme, renvoie prs de 300 lignes !

> SHOW GLOBAL VARIABLES;

pour les variables

mysql> SHOW GLOBAL STATUS\G


*************************** 1. row
Variable_name: Aborted_clients
Value: 5629

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

86

MySQL 5 Audit et optimisation

*************************** 2. row
Variable_name: Aborted_connects
Value: 3004375
*************************** 3. row
Variable_name: Binlog_cache_disk_use
Value: 3994
[...]

Lexemple du paragraphe prcdent prend alors tout son sens : si on multiplie les
mmes mcanismes de calcul pour toutes les autres variables cls surveiller, le DBA
y passerait ses journes !
ATTENTION Variables globales vs variables de session
mysql> SHOW GLOBAL STATUS affiche les variables de statut pour lintgralit du serveur MySQL.
mysql> SHOW [LOCAL, SESSION] STATUS affiche les variables de statut lies la connexion.

Prenez garde, certaines valeurs dont la porte est uniquement globale seront galement prsentes
(Bytes_received, Bytes_sent, Connections...).
Charges au dmarrage du serveur, les variables globales disposent toutes dune valeur par dfaut et
sont redfinies via les options passes en ligne de commandes mysqld ou lors du chargement du fichier
de configuration my.cnf
Les variables de session sont propres aux connexions des clients. Le serveur gre donc la fois des variables globales, mais galement des versions propres chaque connexion dun client.
Le fichier de configuration my.cnf marque galement cette distinction : il existe une section nomme
[mysql] ddie aux paramtres que lon souhaite charger au dmarrage du serveur pour les clients
mysql.
Par exemple, si votre moteur de stockage par dfaut est MyISAM sur le serveur MySQL, sans autre prcision de votre part, les tables seront cres sous ce moteur. Vous pouvez cependant dfinir dans votre session un autre moteur de stockage :
set SESSION storage_engine = InnoDB;

Toutes les tables cres lors de votre session seront dsormais des tables InnoDB (sauf prcision ultrieure de type CREATE TABLE... ENGINE=nom_du_moteur.
Attention, il est dconseill de ne pas spcifier explicitement le moteur de stockage lors de la cration
des tables et donc de se fier la valeur de la variable storage_engine. En cas de changement de
cette dernire, votre code peut ne plus fonctionner aussi bien comme le montre Mark Callaghan dans ce
billet : http://mysqlha.blogspot.com/2009/06/what-could-possibly-go-wrong.html

Nanmoins, les grandes familles de variables listes par la commande SHOW GLOBAL
STATUS permettent dune part de comprendre do ces outils de surveillance tirent
leurs informations, dautre part dtre mme dvaluer le fonctionnement dun serveur en labsence de ces outils.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

87

Sans reprendre les centaines de variables issues de la documentation, voici les


grandes lignes retenir produites par SHOW GLOBAL STATUS. Ce dcoupage sinspire
de celui effectu par MySQL dans son outil MySQL Administrator.
B http://dev.mysql.com/downloads/gui-tools/5.0.html

Figure 41

Larborescence des catgories


que nous allons tudier est
issue de loutil MySQL
Administrator.

Nous vous invitons tlcharger cet outil gratuitement. Mme sil nest pas exempt
de dfauts (impossible de trier des requtes dans la vue server connections notamment), il est gratuit et peut savrer pratique. La partie que nous allons analyser contient la dfinition de chaque variable systme ou de statut. Sans dtailler les lignes de
chaque catgorie, voici les variables de statut les plus importantes.

Catgorie General
On retrouve dans cette catgorie des variables telles que :
uptime : peut confirmer le cas chant quun serveur MySQL a redmarr rcemment.
open_tables, opened_tables et open_files : ces variables indiquent respectivement le nombre de tables actuellement ouvertes, le nombre de tables ouvertes
depuis le dmarrage du serveur et enfin le nombre de fichiers actuellement
ouverts par MySQL.
est surveiller : plutt que la valeur elle-mme, cest lvolution de
celle-ci quil faut observer. Une augmentation trop rapide est souvent caractristique
dun cache de table trop petit. Le premier rflexe est alors daccrotre le cache de

opened_tables

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

88

MySQL 5 Audit et optimisation

table. La variable systme correspondante se nomme


place table_cache partir de la version 5.1.3).

table_open_cache

(elle rem-

Attention nanmoins aux consquences potentielles dune telle modification. Modifier ce paramtre influence en effet le nombre de descripteurs de fichiers (file descriptors) requis par MySQL et en cela il est possible que le serveur MySQL (le processus
mysqld) dpasse le nombre de descripteurs autoris par processus, ce qui serait
potentiellement dsastreux pour le fonctionnement du serveur.
Rcupration de la valeur de table_open_cache
mysql> SHOW GLOBAL VARIABLES LIKE 'table_open_cache';
+------------------+-------+
| Variable_name
| Value |
+------------------+-------+
| table_open_cache | 64
|
+------------------+-------+

B.A.-BA MySQL vs mysqld


mysql dsigne le client MySQL, autrement dit le logiciel qui vous permet dinterroger le serveur MySQL.
Il en existe dautres tels que SQLYog, MySQL Query Browser, MySQL Administrator...
mysqld dsigne le serveur MySQL lui-mme ; cest le programme auquel sont rattachs bases, tables,
moteurs de stockage...

Nous ne rentrerons pas dans le dtail du fonctionnement du cache de table de


MySQL ici mais il est conseill de lire le lien figurant dans lencadr Deux descripteurs de fichiers pour une table MyISAM .
En quelques mots, chaque connexion (threads_connected) ncessite un descripteur
de fichier pour ouvrir une table sur le serveur. La variable systme max_connections
permet dvaluer le nombre de descripteurs ncessaires au bon fonctionnement de
toutes les connexions. On peut obtenir rapidement ce nombre en multipliant
max_connections par le nombre maximal de tables impliques dans une requte pour
un client donn.
ce nombre, MySQL conseille de rajouter encore quelques descripteurs de fichiers
pour les tables temporaires et autres fichiers.
Une fois encore ces trois valeurs permettent de se rendre compte de la corrlation
entre variables systme et variables de statut : table_open_cache (variable systme)
est rapprocher de max_connections (variable systme). Toutes les deux influencent
opened_tables (variable de statut).

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

89

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


la premire ouverture dune table MyISAM, celle-ci ncessite deux descripteurs de fichiers : un pour le
fichier de data (.MYD), et un autre pour le fichier dindex (.MYI) qui sera par la suite partag entre les
threads.
La documentation consacre un chapitre aux mcanismes de cache de tables utiliss par MySQL.
B http://dev.mysql.com/doc/refman/5.1/en/table-cache.htm

La catgorie General contient deux sous-catgories : la premire concerne les


threads, la seconde les fichiers ou tables crs par MySQL.
Retrouver soi-mme les variables listes par MySQL Administrator est un jeu
denfant ; par exemple :
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 dinterroger lensemble des variables systme ou de statut en utilisant des jokers de type
% ou _, comme dans SHOW STATUS like 'handler%';.

Ajoutons enfin que la casse nest pas prise en compte.

Retenons ici que threads_connected correspond au nombre de clients connects au


serveur, ne pas confondre avec Connections qui affiche le nombre de connexions,
russies ou non, au serveur.
Une valeur de threads_created importante doit tre surveille et doit amener la
vrification de la variable thread_cache_size. On constate une fois encore les liens
qui unissent variables systme, autrement dit la configuration du serveur et les variables statut refltant son comportement en production.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

90

MySQL 5 Audit et optimisation

Un moyen de rcuprer les variables globales dont le nom contient 'tmp'


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

Retenez que le serveur MySQL cre des tables temporaires en mmoire


(Created_tmp_tables) et sen sert comme dun tampon, notamment lorsquil ne peut
pas faire autrement pour rpondre un critre de tri dune requte. Cest le cas
lorsque MySQL ne trouve pas dindex utiles, ou par exemple lorsquune commande
GROUP BY est suivie dune instruction ORDER BY dans un ordre diffrent... Dans ces
deux cas, la cration dune table temporaire est systmatique. Il est donc possible de
les faire disparatre en retravaillant la requte ou les index.
Une autre possibilit, manier avec prcaution, consiste dporter le tri du ct du
langage de programmation utilis. Si votre serveur MySQL est sous-dimensionn,
cette technique pourrait lui redonner quelques couleurs. Il convient dans ce cas de
surveiller le temps dexcution du ct de lapplication ainsi que la consommation
mmoire ventuelle du script concern.
Base sur le mme principe, la variable Created_tmp_disk_tables reprsente le
nombre de tables temporaires cres sur disque, ce qui est plus pnalisant...
Le serveur MySQL bascule sur ce type de tables lorsque la taille de la table en
mmoire ncessaire pour stocker les donnes temporaires est suprieure la plus
petite des deux variables tmp_table_size et max_heap_table_size.
La prsence dun champ de type TEXT ou BLOB est galement une source de tables
temporaires puisque ces deux types ne sont pas grs par une table en mmoire. Dans
la mesure du possible utilisez plutt VARCHAR que le type TEXT.
Vrification de la valeur actuelle de ces deux variables systme
mysql> SHOW GLOBAL VARIABLES LIKE '%table_size%';
+---------------------+----------+
| Variable_name
| Value
|
+---------------------+----------+
| max_heap_table_size | 16777216 |
| tmp_table_size
| 67108864 |
+---------------------+----------+

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

91

Catgorie Performance
Parmi les variables disposes sous cette catgorie et hors rubriques, on trouve
slow_queries.
Il est important de jeter un il sur cette valeur qui comptabilise le nombre de
requtes plus lentes que le temps dfini dans long_query_time (variable systme,
10 s par dfaut).
La variable long_query_time sera davantage dtaille au chapitre 6 traitant de loptimisation du
serveur MySQL.

La catgorie Performance est celle qui contient le plus de rubriques. Passons en revue
quelques variables cls de chacune dentre elles.
Query Cache
Rcupration des variables systme lies au Query Cache
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 requte (Query Cache )


Sensible la casse, ce cache contient la liste des requtes SELECT dj envoyes au serveur MySQL
quil est possible de mettre en cache. Leurs rsultats associs sont galement stocks, vitant ainsi au
serveur des phases de parsing et dexcution superflues si la requte est dj connue... et toujours
valide ! En effet, un rsultat est exclu du cache si une des tables associes ce rsultat a t modifie.
Ce cache est particulirement utile lorsque plusieurs requtes identiques sont envoyes au serveur
MySQL mais peut savrer pnalisant si chaque requte est unique.
Il est possible de dsactiver le cache sur une requte en particulier, par exemple des fins de tests de
performance, via la commande suivante SELECT SQL_NO_CACHE...
Pour plus de dtails, consultez le chapitre 7 sur loptimisation du serveur ou la page ddie dans la
documentation :
B http://dev.mysql.com/doc/refman/5.1/en/query-cache.html

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

92

MySQL 5 Audit et optimisation

La variable Qcache_queries_in_cache permet de connatre le nombre de requtes


dans le cache. Ceci permet par exemple de calculer la taille moyenne dune requte
mise en cache :
taille_moyenne = (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache

La variable Qcache_lowmem_prunes compte le nombre de requtes retires du cache


par manque de mmoire. Le rsultat est corrler cependant avec
Qcache_free_blocks ; sil reste des blocs disponibles, cest probablement un cache
fragment qui empche les requtes dy trouver leur place. La commande FLUSH
QUERY CACHE est alors tout indique (elle nefface pas les requtes dj prsentes
comme son nom le laisse croire ; RESET QUERY CACHE, en revanche, les efface).
(Qcache_hits / (Qcache_hits + Com_select) x 100
422782474 / (422782474 + 56297674) = 88%

Keys
Variables de statut lies aux index
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
|
+------------------------+-----------+

Ces valeurs sont relatives au cache dindex des tables MyISAM uniquement. Que
retenir de cette slection ? Encore une fois, il est difficile dun premier coup dil
dvaluer rapidement ces variables et notamment lefficacit du cache dindex.
Figure 42

Pourcentage dutilisation du
Query Cache et indication de la
consommation actuelle du
key_buffer par MyISAM

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

93

MySQL Administrator dispose dune interface beaucoup plus visuelle (Memory


Health) qui indique visuellement lefficacit du cache dindex pour MyISAM ainsi
que le pourcentage de mmoire utilis sur le total allou pour ce cache.
Ces valeurs sont calcules de la faon suivante :
efficacit du cache : 100 - ((key_reads x 100) / key_read_request)

soit ici : 99,939 %.


linverse, le cache miss rate peut tre calcul par la formule key_reads/
key_read_requests o key_reads correspond au nombre de lectures disque dun
bloc dindex.
Il est possible de surveiller cette valeur par paliers successifs via quelques mises jour
de laffichage dans MySQL Administrator ou encore de manire plus automatise
avec 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 alatoires par seconde), il est grand temps de jeter un il au
key_buffer_size.
Variables systme lies aux index
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
|
+--------------------------+------------+

Le pourcentage approximatif de mmoire utilis se calcule de la sorte :


(1 - ((key_blocks_unused key_cache_block_size) / key_buffer_size) x 100)

Ce qui donnerait ici : 18,5 % environ.


RAPPEL Le cache MyISAM
Concernant le moteur de stockage MyISAM, MySQL ne gre que le cache dindex ; les donnes sont
mises en cache par le systme dexploitation (consultez le chapitre 3 ddi aux moteurs de stockage). Les
variables exposes dans cette partie sont relatives au cache dindex dont la taille est dfinie par la variable systme key_buffer_size, une des valeurs les plus importantes concernant la configuration de
MyISAM sur un serveur MySQL.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

94

MySQL 5 Audit et optimisation

SAVOIR Ajuster la taille du cache dindex


Outre MySQL Administrator qui permet de visualiser lutilisation du cache dindex sous MyISAM graphiquement, voici deux autres mthodes.
La premire est une commande shell excuter lorsque vous vous trouvez dans le datadir
mysql> SHOW GLOBAL VARIABLES LIKE 'datadir';
shell> du -sch `find . -name "*.MYI"`
[...]
233M
total

La seconde, base sur une requte SQL :


mysql> SELECT SUM(index_length/1024/1024) FROM information_schema.tables
WHERE engine='MyISAM';
+-----------------------------+
| sum(index_length/1024/1024) |
+-----------------------------+
|
230.54296875 |
+-----------------------------+

Rapprocher 230 Mo donc des 233 Mo obtenus par la commande prcdente : les rsultats sont assez
proches (mais pas identiques : les valeurs stockes en mmoire noccupent pas exactement la mme
place que sur disques) et permettent dvaluer la taille du key_buffer_size.

Sort
Rcupration des variables lies aux tris similaires celles affiches par MySQL Administrator
mysql> SHOW GLOBAL STATUS LIKE 'sort_%';
+-------------------+-----------+
| Variable_name
| Value
|
+-------------------+-----------+
| sort_merge_passes | 353
|
| sort_range
| 37748001 |
| sort_rows
| 394227305 |
| sort_scan
| 15437066 |
+-------------------+-----------+

Notez lutilisation de linstruction 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 variables
dfinies lors de la session qui seraient affiches par dfaut.
Inutile de les connatre par cur. Encore une fois, toutes ces variables et leurs attributs sont dfinis sur le site de MySQL.
RAPPEL
En ce qui concerne les variables de statut, vous en trouverez la dfinition ladresse :
B http://dev.mysql.com/doc/refman/5.1/en/server-status-variables.html

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

95

De manire gnrale, pour tre certain de bien afficher ce que lon souhaite, autant
utiliser SHOW GLOBAL STATUS lorsquon recherche les variables serveur.
Surveillez la variable sort_merge_passes : si celle-ci est leve et en forte progression, la variable systme correspondante, sort_buffer_size, est augmenter.
Consultez galement le chapitre 6 consacr loptimisation de votre serveur MySQL.

Delayed
mysql> SHOW GLOBAL STATUS LIKE '%Delayed_%';
+--------------------------+-------+
| Variable_name
| Value |
+--------------------------+-------+
| Delayed_errors
| 0
|
| Delayed_insert_threads
| 0
|
| Delayed_writes
| 0
|
| Not_flushed_delayed_rows | 0
|
+--------------------------+-------+

La catgorie Delayed, de moindre importance, est relative au nombre dINSERT


DELAYED effectus par le serveur MySQL. Les commandes INSERT DELAYED permettent un client MySQL de ne pas attendre la disponibilit dune table dans laquelle
il souhaite insrer des nouvelles donnes avant deffectuer dautres instructions de
type SELECT, par exemple. Les instructions INSERT sont regroupes dans un buffer
qui sera crit sur disque lorsque la table sera de nouveau disponible.
Nous vous conseillons de lire la documentation relative cette commande. Il est ncessaire de peser avantages et inconvnients puisque des pertes de donnes sont possibles
en cas darrt brutal du processus mysqld : la mmoire tampon serait alors perdue.
La documentation MySQL concernant les commandes INSERT

DELAYED

B http://dev.mysql.com/doc/refman/5.1/en/insert-delayed.html

Selects
mysql> SHOW GLOBAL STATUS LIKE 'select%';
+------------------------+----------+
| Variable_name
| Value
|
+------------------------+----------+
| Select_full_join
| 14473330 |
| Select_full_range_join | 41920
|
| Select_range
| 6869008 |

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

96

MySQL 5 Audit et optimisation

| Select_range_check
| 256
|
| Select_scan
| 31011598 |
+------------------------+----------+

Encore une fois, veillez bien distinguer les valeurs du serveur dans sa globalit et
celles lies votre session. Lintrt doprer cette distinction est par exemple de pouvoir isoler les statistiques provenant de sa session lorsquon passe des requtes, plutt
que de tenter disoler ses actions (session) parmi celles effectues sur le serveur.
La variable de statut select_full_join est surveiller particulirement. Il sagit dune
jointure sans condition entre deux tables, ce qui peut savrer trs coteux : un parcours
gal au produit cartsien du nombre de lignes des tables concernes sera excut.
Afin de calculer le pourcentage de ces commandes SELECT trs lourdes par rapport au
nombre total dinstructions SELECT effectues, on peut employer la mthode suivante :
mysql> SHOW GLOBAL STATUS LIKE 'Com_Select%';
+---------------+-----------+
| Variable_name | Value
|
+---------------+-----------+
| Com_select
| 157412518 |
+---------------+-----------+

Effectuez ensuite :
(Select_full_join / Com_select) * 100

Sur ce serveur, on obtient 9,2 % ce qui commence faire beaucoup. Un petit passage
sur les slow queries permettrait sans doute damliorer les choses.
MySQL Administrator ne permet pas deffectuer ce calcul automatiquement ; en
revanche mysqlreport, dtaill plus loin dans ce chapitre, est capable dafficher des
statistiques telles que celles-ci :
Statistiques dutilisation sur la commande SELECT et les tris
SELECT and Sort _____________________________________________________
Scan
6.46M
4.6/s %SELECT:
4.20
Range
6.83M
4.9/s
4.44
Full join
212.23k
0.2/s
0.14

On retrouve le nombre de select_full_join, leur frquence et leur pourcentage par


rapport au nombre de SELECT global, soit 0.14 %.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

97

Locks
mysql> SHOW GLOBAL STATUS LIKE 'table_lock%';
+-----------------------+-----------+
| Variable_name
| Value
|
+-----------------------+-----------+
| Table_locks_immediate | 403979893 |
| Table_locks_waited
| 79
|
+-----------------------+-----------+

Nous disposons du nombre de verrous qui ont pu tre acquis immdiatement ou qui
au contraire ont t poss aprs une attente.
Si la variable table_locks_waited est importante au regard de ceux qui ont pu tre
poss immdiatement, cest un bon indice qui doit vous orienter vers les slow queries.
Ici le ratio nest pas alarmant.
InnoDB
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
|
+-----------------------------------+--------------+

Dans la version 1.2.17 de MySQL Administrator, ce ne sont pas ces valeurs qui sont
affiches... lorsquelles le sont ! En effet, en fonction de la version de MySQL de
votre serveur, MySQL Administrator est susceptible de ne rien afficher du tout ; un
bogue est ouvert ce sujet.
Retenons donc les variables ci-dessus, accessibles via nimporte quel autre client.
Concernant les quelques lignes affiches par la commande ci-dessus, sans entrer dans
le dtail de chacune delles, on peut retenir ici que la totalit de lespace attribu au
buffer pool dInnoDB est consomme (Innodb_buffer_pool_pages_free = 0), ce

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

98

MySQL 5 Audit et optimisation

qui signifie que lon possde trs probablement plus de donnes que de mmoire
vive. Cela nest pas forcment un problme en soi, si le jeu de donnes avec lequel on
travaille est en mmoire.
Il est plus important de connatre la proportion de lectures qui ont besoin dinterroger les disques (Innodb_buffer_pool_reads) par rapport au nombre global de lectures reues par InnoDB (Innodb_buffer_pool_read_requests). Ce pourcentage est
obtenu par le calcul suivant :
(Innodb_buffer_pool_reads x 100) / Innodb_buffer_pool_read_requests

Il est parfois pratique de raliser ce calcul en ligne de commandes directement sous


MySQL.
Utilisation dun client MySQL pour y effectuer un calcul
mysql> SELECT (18501017*100)/755385349808\G
*************************** 1. row
(18501017*100)/755385349808: 0.0024

Ici, le taux de lectures interrogeant les disques est trs faible ! Avec un si faible taux
de lectures seffectuant sur disque, on peut considrer que la taille du buffer pool est
suffisante pour les applications reposant sur InnoDB et fonctionnant sur ce serveur.
Il est mme possible de rduire sa taille si besoin, en diminuant progressivement la
valeur de innodb_buffer_pool_size tout en effectuant ce mme calcul rgulirement sur quelques heures ou quelques jours afin de vrifier que lefficacit du buffer
pool ne baisse pas dramatiquement (hit rate).
Rendez-vous au chapitre concernant loptimisation de votre serveur MySQL pour
dautres dtails concernant les rglages dInnoDB.
Networking
Hors de ses rubriques Traffic et Replication, cette catgorie contient quatre variables.
Rcupration des variables affiches par MySQL Administrator pour la catgorie Networking
mysql> SHOW GLOBAL STATUS LIKE 'aborted%';
+------------------+---------+
| Variable_name
| Value
|
+------------------+---------+
| Aborted_clients | 5640
|
| Aborted_connects | 3081369 |

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

99

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
|
+----------------------+-------+

Quelques

mots

sur les deux premires variables. Aborted_clients/


: comme son nom lindique, la premire variable comptabilise le
nombre de clients qui se sont dconnects brutalement sans passer par la commande
mysql_close(), par exemple. Le second recense les tentatives choues de connexion
au serveur MySQL.

Aborted_connects

Un nombre important de commandes aborted_connect peut provenir de vos propres


outils de surveillance (ou de ceux de votre hbergeur). Un load balancer testant si vos
machines sont toujours disponibles puis coupant la connexion une fois son test
effectu (parfois chaque seconde), est susceptible dincrmenter ce compteur.
La documentation MySQL dtaille plusieurs scnarios lis ces erreurs ladresse
suivante : http://dev.mysql.com/doc/refman/5.1/en/communication-errors.html
ATTENTION Sortir un serveur client de la liste noire dun serveur MySQL
Par dfaut, le serveur MySQL bloque un serveur au bout de 10 connexions infructueuses. En cas
durgence la commande FLUSH HOSTS ou mysqladmin flush-hosts lvera le blocage. Il est
cependant ncessaire danalyser le problme afin de remonter jusqu sa cause. La documentation est un
bon point de dpart : http://dev.mysql.com/doc/refman/5.1/en/blocked-host.html

SAVOIR Droits ncessaires aux commandes SHOW STATUS et SHOW VARIABLES


Vous pouvez accder aux commandes SHOW STATUS et SHOW VARIABLES avec simplement le privilge USAGE (simple droit de se connecter). Ds lors que vous avez un compte mysql valid sur le serveur
tudier, vous tes certain de pouvoir au moins excuter ces deux commandes.
Les droits pour un utilisateur se dfinissent grce la commande GRANT. Pour visualiser lensemble de
vos droits, effectuez : mysql > SHOW GRANTS;
Attention : les droits se dfinissent pour un utilisateur associ un domaine. Consultez le chapitre 7 sur
la configuration serveur pour une explication dtaille de la gestion des droits utilisateurs.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

100

MySQL 5 Audit et optimisation

Donnons rapidement quelques mots sur les rubriques restantes.


Variables lies la rubrique traffic
mysql> SHOW GLOBAL STATUS LIKE 'bytes_%';
+----------------+---------------+
| Variable_name | Value
|
+----------------+---------------+
| Bytes_received | 732927533019 |
| Bytes_sent
| 1642267367588 |
+----------------+---------------+

Ces deux valeurs sont explicites : somme des donnes reues par lensemble des
clients et quantit de donnes envoyes par le serveur MySQL tous les clients.
Quelques variables lies la rplication et notamment au statut de lesclave
mysql> SHOW GLOBAL STATUS LIKE 'slave%';
+----------------------------+-------+
| Variable_name
| Value |
+----------------------------+-------+
| Slave_open_temp_tables
| 0
|
| Slave_retried_transactions | 258
|
| Slave_running
| ON
|
+----------------------------+-------+

Rien de vraiment notable ici. Il est plus utile deffectuer une commande SHOW SLAVE
STATUS\G quune vrification sur slave_running pour contrler ltat dun esclave.
Rcupration des variables affiches dans la rubrique Commands Executed
de MySQL Administrator
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
|
[...]

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

101

Trs nombreuses, ces variables sont des compteurs de chaque commande SQL effectues sur le serveur MySQL. Rparties en diffrentes sous-rubriques dont DDL
(Data Definition Language) et DML (Data Manipulation Language), ces statistiques
permettent de se rendre compte de limportance de telle ou telle commande. Hlas,
pas de calcul de pourcentage (exemple : les commandes SELECT reprsentent x % de
la somme des DML). Cependant, nous verrons que ce type dinformation se retrouve
dans dautres outils de surveillance, tel que mysqlreport.
Connatre la rpartition des lectures et critures sur son systme est important
lorsque vous souhaitez optimiser les performances. 80 % dcritures et 20 % de lectures, ou au contraire 20 % dcritures contre 80 % de lectures, correspondent des
impacts bien diffrents sur les serveurs concerns. Les solutions apporter sur de tels
systmes face une monte en charge sont elles aussi adapter en fonction de cette
rpartition.
La variable Com% dtaille le nombre de requtes reues par le serveur classes par type
(SELECT, ALTER, INSERT). Exemple pour le SELECT :
mysql> SHOW GLOBAL STATUS LIKE 'Com_select';
+---------------+----------+
| Variable_name | Value
|
+---------------+----------+
| Com_select
| 80666609 |
+---------------+----------+

Attention, dans ce cas, seules les commandes SELECT qui ne sont pas dans le cache et
rellement excutes par le serveur sont prises en compte.
De manire gnrale, consulter la documentation ds lors quune variable est digne
dintrt est une bonne faon de procder : comprendre leur comportement ncessite
parfois des prcisions techniques pas forcment intuitives au premier abord. Cest ce
qui arrive avec une instruction SELECT dont le rsultat se trouve dans le cache. Dans ce
cas, cest la variable Qcache_hits qui sera incrmente au lieu de Com_select.
mysql> SHOW GLOBAL STATUS LIKE 'Qcache_hits';
+---------------+-----------+
| Variable_name | Value
|
+---------------+-----------+
| Qcache_hits
| 205196094 |
+---------------+-----------+

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

102

MySQL 5 Audit et optimisation

Miscellaneous
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 |
+-----------------------+--------------+
|[...]

Sans entrer dans la dfinition de chacune de ces variables, handler_read_rnd et


handler_read_rnd_next sont surveiller. Elles indiquent en effet des lacunes probables
dans lindexation et trop de scans complets des tables. Une fois encore, pour dtecter ces
tendances les scripts de surveillance sont bien plus adapts quun calcul manuel.
Nanmoins, il est possible disoler dans la srie des handlers les handler_read. Ces
derniers renseignent sur lutilisation des index par MySQL. Difficiles lire dans leur
ensemble via un SHOW GLOBAL, ces valeurs sont beaucoup plus utiles lorsquelles sont
relatives une session. Elles permettent alors danalyser prcisment une requte,
suivant une autre approche que la commande EXPLAIN. On entre alors dans le
domaine du profiling de requtes.
Voici un rapide exemple avec la base sakila (tlchargeable sur http://dev.mysql.com/doc/).
On commence par rinitialiser les variables de statut lies sa session :
mysql> FLUSH STATUS;

Utilisation des variables de statut lies la session et non globales au serveur des fins danalyse
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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

103

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
|
+-----------------------+-------+

Ces valeurs sont propres la session en cours, ce qui permet dvaluer lvolution des
variables surveilles selon ses requtes.
utiliser galement :
SHOW STATUS LIKE 'SELECT%';
SHOW STATUS LIKE 'SORT%';
SHOW STATUS LIKE 'created_tmp%';

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

104

MySQL 5 Audit et optimisation

ASTUCE Optimiser et analyser une requte avec USE INDEX/IGNORE INDEX


Pour entrer dans le dtail du profiling dune requte, outre lindispensable EXPLAIN, il est possible
dutiliser la commande FLUSH STATUS/SHOW STATUS LIKE... en parallle des MySQL hints,
savoir des commandes spciales telles que USE INDEX, IGNORE INDEX ou SQL_NO_CACHE, qui
permettent dorienter le comportement de loptimiseur MySQL. Dsactiver un index sur une requte a un
impact sur les variables de statut. Il est donc possible de mener des tests pousss et de comprendre ainsi
ce queffectue MySQL.

Autre utilit de ce type de variables : il est possible, sous certaines conditions,


destimer le temps dexcution dune requte en analysant lvolution de
handler_read_rnd_next. Un article dcrivant cette manipulation se trouve
ladresse : http://www.mysqlperformanceblog.com/2008/04/22/

La commande SHOW ENGINE INNODB STATUS


SHOW ENGINE INNODB STATUS,

commande plus couramment utilise sous le raccourci


(obsolte mais toujours fonctionnel), permet dobtenir rapidement une vue globale du moteur de stockage InnoDB sur un serveur MySQL.

SHOW INNODB STATUS

Au programme, des informations sur les contentions au sein mme du code source
dInnoDB (rubrique semaphores) mais galement des informations plus accessibles
concernant les DEADLOCKS, les cls trangres, les transactions, le buffer pool, etc.
Afin de visualiser ces informations, il suffit dexcuter la commande SHOW ENGINE
INNODB STATUS au sein dun client MySQL. Il est galement possible dindiquer au
serveur MySQL que lon souhaite inscrire le rsultat de cette commande vers la
sortie standard ddie aux erreurs (stderr), en pratique le fichier de log derreurs
toutes les 15 secondes.
CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;

Pour dsactiver ce processus, il suffit de supprimer la table par linstruction classique


DROP TABLE.
noter quil sagit dans ce cas du Standard Monitor and Lock Monitor, pour
reprendre la dnomination prcise utilise par MySQL. Celle-ci est ncessaire car il
existe par ailleurs un Tablespace Monitor ainsi quun Table Monitor. Ces deux derniers ne seront pas tudis ici mais leur utilisation est dtaille dans la documentation
MySQL : http://dev.mysql.com/doc/refman/5.1/en/innodb-monitors.html
Nous allons analyser lessentiel dun SHOW
frentes sections.

ENGINE INNODB STATUS,

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

dont voici les dif-

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

105

Information den-tte
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

Cette premire section indique simplement lheure laquelle cette photographie de


ltat dInnoDB a t prise. Une bonne pratique est de vrifier que la dure sur
laquelle ont t tablies les statistiques prsentes est suffisante pour obtenir des
rsultats significatifs.
59 secondes, comme dans cet exemple, semblent suffisantes. Essayez dobtenir des
rsultats recueillis sur au moins 20 secondes. Quelques essais successifs sont nanmoins
parfois ncessaires pour arriver obtenir des moyennes de plus de 10 secondes : en
effet, vous ne matrisez pas le moment o ces statistiques sont rinitialises.
Information sur les smaphores
---------SEMAPHORES
---------OS WAIT ARRAY INFO: reservation count 1877627232, signal count
1590319303
Mutex spin waits 0, rounds 297103334422, OS waits 1220510239
RW-shared spins 294569924, OS waits 35432718; RW-excl spins 1711817825,
OS waits 32784412

Section pointue concernant lactivit des threads, les informations dlivres ici sont
difficiles interprter du premier coup dil. Il sagit de statistiques concernant la
proportion de threads consommant des cycles processeur (spins) en attendant de
pouvoir accder une ressource. Au-del dun nombre de cycles dfini par la variable
innodb_sync_spin_loops (20 par dfaut), le thread est suspendu et lattente est
dsormais gre par le systme dexploitation. Celui-ci opre un context switch (changement de contexte et sauvegarde du contexte suspendu) et excute un autre thread.
Selon lactivit de votre serveur cette rubrique peut galement contenir des informations
supplmentaires sur dventuels points de blocage, comme dans lextrait ci-dessous.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

106

MySQL 5 Audit et optimisation

Dans la section smaphores, InnoDB indique sur quelle partie du code source se trouve la contention.
--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 0
waiters flag 0
[...]

Une liste de threads est alors affiche avec le mutex responsable de leur prsence dans
cette liste. Le thread ci-dessus attend quun verrou du fichier trx0purge.c se libre.
Une information plutt difficile analyser, moins dexaminer le code source et
danalyser le problme... Ce qui pourrait l encore prendre un certain temps.
Une approche plus rapide consiste tenter de comprendre quelles catgories appartiennent les mutex. Soumettre un moteur de recherche le nom du fichier source dans
lequel se trouve le mutex permet bien souvent de restreindre la zone du problme.
Il sagit en loccurrence dun problme probablement relatif aux mcanismes de purge
mis en uvre par InnoDB et notamment de la variable innodb_max_purge_lag sur
laquelle il serait bon deffectuer quelques tests. Les noms des mutex sont parfois suffisamment explicites, comme buf0buf.ic qui concerne une contention du buffer pool.
Une longue liste de threads bloqus par des mutex nest pas bon signe et est caractristique de goulets dtranglement soit au niveau des disques, dInnoDB lui-mme (il
est possible dagir sur la variable innodb_thread_concurrency pour rduire cette
contention), soit encore sur la gestion des threads par le systme dexploitation.
SAVOIR Diffrence entre mutex et smaphores
Un mutex est utilis pour restreindre laccs une ressource partage, par exemple un bout de code
source, par un thread au plus la fois. Un smaphore permet de restreindre laccs une ressource un
certain nombre de threads simultanment. Autrement dit un smaphore qui restreint laccs un seul
thread est un mutex.
La recherche suivante, effectuer sur votre moteur de recherche prfr, permet de comprendre trs...
concrtement cette diffrence Mutex vs Semaphore, the toilet example !

Les cls trangres


Cette section est une aide prcieuse pour qui souhaite rapidement constater si des
problmes existent autour des contraintes poses sur certaines tables.
-----------------------LATEST FOREIGN KEY ERROR
-----------------------091005 17:48:06 Transaction:

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

107

TRANSACTION 0 663601494, ACTIVE 0 sec, process no 14626, OS thread id


1205045600 inserting, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1216, 2 row lock(s), undo log entries 1
MySQL thread id 64847939, query id 959410328 localhost user update
INSERT INTO ABO_SERV (NUM_ABO,CODE_SERVICE,...) VALUES
('1234','5678',...)
Foreign key constraint fails for table `base1`.`ABO_SERV`:
,
CONSTRAINT `AS_ibfk_8` FOREIGN KEY (`CODE_SERVICE`) REFERENCES `DS`
(`CODE_SERVICE`) ON UPDATE CASCADE
Trying to add in child table, in index `INDEX_CODE_SERVICE` tuple:
DATA TUPLE: 2 fields;
[...]

Cette partie est plutt explicite et permet facilement didentifier des erreurs parfois
silencieuses concernant la gestion des cls trangres. SHOW INNODB STATUS est alors
un trs bon moyen de comprendre, par exemple, pourquoi une insertion na pas pu
seffectuer. Ce type derreur doit tre remont par ladministrateur de bases de donnes aux quipes de dveloppement sil savre que le souci est applicatif.
Les deadlocks
Exemple de deadlock ou verrou infini rsolu par InnoDB en annulant une des deux transactions
impliques
-----------------------LATEST DETECTED DEADLOCK
-----------------------030709 12:59:58
*** (1) TRANSACTION:
TRANSACTION 0 290252780, ACTIVE 1 sec, process no 3185, OS thread id
30733
inserting
LOCK WAIT 3 lock struct(s), heap size 320, undo log entries 146
MySQL thread id 21, query id 4553379 localhost heikki update
INSERT 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 index
symbole trx id 0 290252780 lock mode S waiting
Record 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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

108

MySQL 5 Audit et optimisation

inserting
130 lock struct(s), heap size 11584, undo log entries 437
MySQL thread id 23, query id 4554396 localhost heikki update
REPLACE 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 index
symbole trx id 0 290251546 lock_mode X locks rec but not gap
Record 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 index
symbole trx id 0 290251546 lock_mode X locks gap before rec insert
intention
waiting
Record lock, heap no 82 RECORD: info bits 0 0: len 7; hex
61613335373230;
asc aa35720;; 1:
*** WE ROLL BACK TRANSACTION (1)

Ce paragraphe facultatif (il napparat quen cas de deadlock) permet didentifier les
problmes de deadlock : il sagit de deux transactions qui sattendent mutuellement
et o lune delle sera annule par InnoDB. Cet exemple provient de la documentation MySQL.
La transaction annule est souvent celle qui verrouille le plus de lignes. Il peut galement sagir dune transaction qui en attend une autre... mais trop longtemps. Par
dfaut cette variable, innodb_lock_wait_timeout, a une valeur de 50 secondes, ce
qui devrait convenir la plupart du temps.
ASTUCE Crer un deadlock dlibr
La commande SHOW ENGINE INNODB STATUS excute en ligne de commandes ( la diffrence de
son criture dans le fichier derreurs) dispose dun affichage limit 64 Ko. Lorsquun deadlock important
se produit, il est susceptible de publier via cette commande trop dinformations pour le buffer de 64 Ko ;
il est alors impossible de lire les sections suivantes du SHOW ENGINE INNODB STATUS. Pour remdier ce problme et si vous avez identifi le deadlock, il est possible de crer un deadlock dlibr simplement pour effacer le prcdent (seul le dernier est conserv en mmoire).
Baron Schwartz dcrit la manipulation sur son blog : http://www.xaprb.com/blog/2006/08/08/
Il est galement possible dutiliser InnoTop, un outil du mme auteur.

Plutt que de penser doubler cette valeur, il est conseill dtudier la transaction qui
est attendue, analyser la ou les requtes la composant, peut-tre un SELECT trop lent...
Bref doptimiser la requte laide dEXPLAIN notamment afin de dtecter rapide-

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

109

ment si le plan dexcution indique quun index serait ventuellement le bienvenu.


Une transaction excute sur un serveur esclave qui attend trop longtemps peut provoquer larrt de la rplication...
Le MVCC
La section des transactions renseigne sur ltat du mcanisme de purge dInnoDB et indique les
verrous ventuels
-----------TRANSACTIONS
-----------Trx id counter 0 1433572342
Purge done for trx's n:o < 0 1433571830 undo n:o < 0 0
History list length 6
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 0, not started, process no 24720, OS thread id 1184811360
MySQL thread id 49776520, query id 2483480984 localhost user1
show engine INNODB STATUS
---TRANSACTION 0 0, not started, process no 24720, OS thread id 1192532320
MySQL thread id 49776544, query id 2483462446 localhost user2
---TRANSACTION 0 1433571828, not started, process no 24720, OS thread id
1171499360
MySQL thread id 2434784, query id 2483477073 Has read all relay log; waiting for
the slave I/O thread to update it
[...]

Les trois premires lignes renseignent sur ltat du mcanisme de purge dInnoDB
concernant le MVCC. Avec un tel systme, chaque transaction ne voit que sa propre
version des donnes, cest la lettre I de la norme ACID (atomicit, cohrence, isolation, durabilit). La contrepartie de ce systme est quInnoDB doit conserver lintgralit des enregistrements dune table tant que toutes les transactions nen ont pas
termin avec eux.
LIRE GALEMENT Le MVCC
La notion de MVCC est dtaille au chapitre 3 consacr aux moteurs de stockage.

Autrement dit, mme un enregistrement dont la suppression est effectue (COMMIT)


nest pas forcment rellement effac de la table. Il se peut en effet que cet enregistrement ait des liens avec dautres transactions dont les rsultats seraient impacts, deux
lectures successives de la table en question ne donnant pas les mmes rsultats par
exemple (dirty reads, phantom reads...). Ces mcanismes dpendent du niveau disolation dInnoDB (par dfaut REPEATABLE READ).

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

110

MySQL 5 Audit et optimisation

La premire ligne indique en quelque sorte lidentifiant unique de la dernire


transaction ; on peut comparer cela la valeur dune cl primaire en auto-incrment.
La deuxime ligne indique que le mcanisme de purge des anciennes lignes modifies est jour jusqu lidentifiant de transaction 1433571830. On peut donc en
dduire en soustrayant les deux valeurs, que 512 identifiants restent purger. Afin de
limiter lexpansion de ce nombre, une bonne pratique consiste ne pas laisser ouverte
inutilement une transaction mais effectuer linstruction COMMIT au plus tt.
Le mcanisme de purge affecte galement la valeur de la dernire ligne de len-tte :
il sagit du nombre de transactions non purges dans la zone undo des fichiers de
donnes dInnoDB.
Suit une liste de transactions en cours. Pour chacune dentre elles un tat (not
started, active...) est affich. Dans lexemple ci-dessus, il est plus clair de se rfrer
la commande mysql> SHOW FULL PROCESSLIST;.
Cependant certaines entres de cette liste sont parfois plus bavardes (souvent en cas
de forte charge), par exemple :
Le MVCC permet chaque transaction dobtenir sa propre vue des donnes (en fonction du degr
disolation dfini dans InnoDB)
---TRANSACTION 0 663702920, ACTIVE 23 sec, process no 14626, OS thread id
1239923040
MySQL thread id 64957572, query id 960138174 localhost 192.168.10.1 my_user
Trx read view will not see trx with id >= 0 663702921, sees < 0 663650722

La dernire ligne nous apprend que cette transaction, du fait du MVCC voqu prcdemment, ne verra pas les modifications potentielles apportes aux enregistrements par les transactions dont lidentifiant est suprieur au sien (ce qui est logique).
Information intressante, il existe plus de 50 000 identifiants de transaction en relation avec cette transaction, ce qui est norme. Cet exemple provient dun systme
confront de gros problmes de contentions au sein dInnoDB.
I/O
-------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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

111

Pending flushes (fsync) log: 0; buffer pool: 0


29078727 OS file reads, 270066897 OS file writes, 5161540 OS fsyncs
1.12 reads/s, 16384 avg bytes/read, 5.92 writes/s, 1.60 fsyncs/s

Si lune des quatre premires lignes nest pas en attente (waiting) cest quil existe un
goulet dtranglement au niveau du thread concern (criture dans le tablespace partir
du buffer dinsertion, les flushs asynchrones des logs, mcanisme de read-ahead
dInnoDB (consultez le chapitre 2 consacr au matriel) ou pour le dernier thread, le
flush des buffers dits dirty, modifis en mmoire mais pas encore sur disques.
Notez galement que la ligne Pending flushes (fsync) log: 0; buffer pool: 0 indique
lactivit du log buffer et du buffer pool. Quelques autres statistiques suivent, calcules par
seconde et sur le laps de temps coul et figurant au tout dbut de la commande SHOW
ENGINE INNODB STATUS; : Per second averages calculated from the last 59 seconds.
INSERT BUFFER AND ADAPTIVE HASH INDEX
------------------------------------INSERT BUFFER AND ADAPTIVE HASH INDEX
------------------------------------Ibuf: size 1, free list len 5493, seg size 5495,
12071862 inserts, 12078750 merged recs, 2386492 merges
Hash table size 25499819, node heap has 81971 buffer(s)
48717.97 hash searches/s, 18252.11 non-hash searches/s

Un adaptive hash index est une tentative dInnoDB doptimiser une recherche par index
sur une table susceptible de tenir en mmoire. La transformation consiste passer dun
index B-TREE celui dun hash index plus rapide parcourir (vous trouverez plus de
dtails sur lun de nos articles en ligne : http://www.dbnewz.com/2008/05/19/).
La quatrime ligne permet de mesurer lefficacit des hash index ; dans cet exemple,
InnoDB les utilise environ 2,5 fois plus souvent que le parcours dun B-tree.
Ce processus de choix est automatique. Cette section a donc un but informatif
uniquement ; ceci est galement valable pour le buffer dinsertion.
Les logs de transactions
--LOG
--Log sequence number 75 2845856081
Log flushed up to
75 2845855633
Last checkpoint at 75 2845688745
0 pending log writes, 0 pending chkp writes
405283217 log i/o's done, 6.75 log i/o's/second

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

112

MySQL 5 Audit et optimisation

Ces cinq lignes concernent la gestion des fichiers de log de transactions.


On peut tirer des deux premires lignes que seuls (2845856081-2845855633)/1024 =
0,4375 Ko nont pas t placs sur disque.
Le dernier checkpoint (dernier point de sauvegarde exploitable en quelque sorte) se
situe une distance de (2845855633-2845688745)/1024 = 162,98 Ko.
Le buffer pool et la mmoire
Les informations consacres au buffer pool
---------------------BUFFER POOL AND MEMORY
---------------------Total memory allocated 14319368562; in additional pool allocated 1048576
Dictionary memory allocated 7955472
Buffer pool size
786432
Free buffers
0
Database pages
686045
Modified db pages 604
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 24671168, created 1866207, written 36500640
2.55 reads/s, 0.05 creates/s, 11.35 writes/s
Buffer pool hit rate 1000 / 1000

Cette section permet dun coup dil dobtenir quelques informations intressantes
propos du buffer pool, lment crucial pour InnoDB.
Le buffer pool na plus de place disponible. Il sera nanmoins capable de contenir au
prix de lectures disque dventuels nouveaux enregistrements. Ceci tant dit, son taux
defficacit est excellent. Nous avions dj voqu une autre mthode dans ce chapitre pour le calculer grce aux variables de statut Innodb_buffer_pool_reads et
Innodb_buffer_pool_read_requests.
Nous apprenons galement que le buffer pool contient 604 pages modifies en
mmoire. Celles-ci sont dites dirty car les modifications apportes nont pas encore
t crites sur disque.
Statistiques sur le moteur InnoDB
-------------ROW OPERATIONS
-------------0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

113

Main thread process no. 24720, id 1140881760, state: sleeping


Number of rows inserted 105920506, updated 212285505, deleted 15281146,
read 575888002863
0.56 inserts/s, 0.88 updates/s, 0.00 deletes/s, 83686.01 reads/s
---------------------------END OF INNODB MONITOR OUTPUT
============================

La premire ligne de cette dernire section indique le nombre de threads actuellement traits par InnoDB (limit par innodb_thread_concurrency) ainsi que le
nombre de threads attendant leur tour daccder lintrieur du moteur.
Extrait montrant une activit beaucoup plus soutenue de ce point de vue
8 queries inside InnoDB, 79 queries in queue
83 read views open inside InnoDB

Issues dun serveur satur, ces deux lignes montrent la limite impose InnoDB, via
un rglage de la variable innodb_thread_concurrency = 8, et une forte activit
puisque 79 threads sont dans la file dattente.
De plus, 83 vues ou snapshots en lecture sont en cours au sein dInnoDB. Cela concerne les vues dont dispose chaque transaction sur les donnes quelles grent grce
au systme de MVCC. Ces vues ont bien sr un cot et font souffrir le systme qui
doit garder en mmoire davantage de donnes.
La dernire ligne de cette section permet dobtenir la rpartition de lactivit
dInnoDB en termes de lectures ou critures (insertions, suppressions, mises jour).
Dautres informations concernant la commande SHOW ENGINE INNODB STATUS se
trouvent dans la documentation MySQL : http://dev.mysql.com/doc/refman/5.1/en/innodb-monitors.html

INFORMATION_SCHEMA
Outre les commandes classiques SHOW GLOBAL VARIABLES; et SHOW GLOBAL STATUS;,
il est galement possible de profiter de la base information_schema afin dobtenir les
informations relatives aux variables de sessions ou globales au serveur.
mysql> SELECT variable_name, variable_value FROM
information_schema.GLOBAL_STATUS ORDER BY variable_name;
+-----------------------------------+----------------+
| variable_name
| variable_value |
+-----------------------------------+----------------+
| ABORTED_CLIENTS
| 0
|

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

114

MySQL 5 Audit et optimisation

| ABORTED_CONNECTS
| BINLOG_CACHE_DISK_USE
| BINLOG_CACHE_USE

| 0
| 0
| 0

|
|
|

Il est galement possible dobtenir les mmes informations quavec la commande


SHOW ENGINES par ce biais :
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
[...]

La base information_schema recle une large palette dinformations susceptibles de


vous intresser : http://dev.mysql.com/doc/refman/5.1/en/information-schema.html

Connatre et savoir exploiter les outils de surveillance


Connatre le fonctionnement des variables systme et de statut dun serveur MySQL est
indispensable... mais insuffisant. Une tude plus pousse ncessite une analyse plus complte du systme (matriel et systme dexploitation). Cest en matrisant parfaitement
votre environnement et ses outils que vous pourrez identifier les goulets dtranglement.
Les goulets pour une base de donnes sont souvent issus des I/O disques. En effet, la
lecture de donnes sur un disque est une action mcanique et prend donc beaucoup
plus de temps quune lecture en mmoire.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

115

La mmoire vive (RAM) est galement une ressource cruciale. Un serveur qui possde davantage de donnes exploiter que de mmoire vive risque dutiliser son
fichier dchange (swap) et donc daugmenter les I/O.
Autre zone de ralentissement, la contention au niveau des processeurs (CPU). Plusieurs processeurs travaillant de concert signifient galement plusieurs threads en
parallle accdant des ressources partages. Pour viter que ces mme ressources
soient utilises en mme temps, MySQL utilise des mutex (Mutal exclusion). On
appelle ce mcanisme une primitive de synchronisation. Diffrentes implmentations sont possibles. Si tous les threads veulent accder au mme mutex, une contention apparat au niveau des threads et donc au niveau des processeurs. Dans le mme
registre, on voque parfois les smaphores, sorte de mutex avec un compteur.
Enfin, les I/O de linterface rseau sont eux aussi susceptibles davoir un impact sur
les performances du systme.

Quest-ce que la performance ?


La dfinition de la performance varie selon le type dactivit. Pour une base de donnes, la performance est mesure en temps et en nombre de requtes.
Quelle quantit de donnes la base va-t-elle tre capable de retourner dans un
minimum de temps ? La notion de temps tant la base de cette valuation, il est
ncessaire de garder en mmoire certains repres (source : Jeff Dean gave at a Engineering All-Hands Meeting at Google) :
poser ou enlever un verrou sur un Mutex : 100 ns ;
envoyer 2 Ko sur un rseau Ethernet 1 Go : 20 000 ns ;
lire 1 Mo squentiel en mmoire : 250 000 ns ;
lire 1 Mo squentiellement sur le rseau : 10 000 000 ns ;
lire 1 Mo squentiellement sur un dique dur : 30 000 000 ns ;
un dplacement 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 tte, il ny a pas de doute que MySQL rpondra plus rapidement une requte SQL en lisant les informations en mmoire plutt que sur le disque.
Pourtant, ltape du disque est encore indispensable aujourdhui.
Une base de donnes transactionnelle (comme MySQL + InnoDB) doit la fois
crire les donnes, grer les transactions ainsi que leurs potentielles annulations
(ROLLBACK) ; il sagit dans ce cas des donnes modifies par un ordre SQL non valid
par une instruction COMMIT. Lire sur le disque entrane le dplacement de la tte de
lecture et augmente les temps daccs.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

116

MySQL 5 Audit et optimisation

LIRE Technologie du disque


Rendez-vous au chapitre 2 consacr au matriel pour de plus amples dtails sur les mcanismes lis
lutilisation dun disque.

Afin de faciliter la monte en charge ultrieure de votre systme, il est souhaitable dtudier ds le dbut la faon de grer les critures afin dviter les contentions ce niveau.
En effet, lorsquun thread crit une donne, comme un enregistrement dans une table
avec un systme est ACID, les mises jour sont appliques sur les lments suivants :
la page qui stocke la table ;
le log de transactions ;
le log binaire (sil est activ).
Afin daccder toutes ces ressources, MySQL utilise des mutex. Si tous les threads
accdent aux mmes mutex, les performances se dgradent.
InnoDB souffre lui aussi de ce problme et il est courant de voir les performances se
dgrader sur des systmes multiprocesseurs ( partir de huit curs en gnral).
En consquence, il faut absolument pouvoir parallliser les critures si lon souhaite
atteindre de meilleures performances. Des solutions ont t implmentes par InnoDB
et son plug-in 1.0.4 et par MySQL partir de la version 5.4 (encore en bta).
Pour rsumer, si le temps daccs dun disque (disk seek) est de 10 ms, nous pourrons
au maximum effectuer 100 recherches par seconde (1 s/10 ms). Ceci dpend videmment de la taille des donnes et de la faon dont elles sont crites sur le disque (continue ou non).
Pendant cette mme seconde, il est possible de lire 4 Go en mmoire (1 Mo squentiel en mmoire, 1 s/250 000 ns), ce qui donne pour 1 Mo environ 4 000 fetch/s
(4 000 lectures en mmoire).
Voici ce quon peut en dduire :
une criture est 40 fois plus coteuse quune lecture (100 seek vs 4 000 fetch).
100 seek signifie 100 recherches sur le disque ; nous sommes limits par le dplacement la tte de lecture ;
partager des donnes est coteux ;
le temps daccs dune lecture en mmoire est dj 120 fois plus rapide que sur un
disque (250 000 ns vs 30 000 000 ns).

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

117

LVM : la gestion des volumes logiques


Avant danalyser plus en dtail une tude de cas reposant sur un serveur MySQL, il
est utile de dcrire les mcanismes du LVM. En effet, lors dune phase daudit ou
doptimisation MySQL, vous tes susceptible de rencontrer voire de mettre en place
vous-mme ce type de systme.
La gestion par volumes logiques LVM (logical volume management), est une faon de
grer son espace de stockage.
Figure 43

Architecture LVM

Elle offre beaucoup de flexibilit et de confort pour agrandir chaud les partitions ou
pour les diminuer. Il est possible de diffrencier les entits suivantes.
Les volumes physiques (PV) sont au choix des disques durs, des partitions de disques durs, des volumes RAID ou des units logiques provenant dun SAN.
Les groupes de volumes (VG) runissent les volumes physiques.
Les volumes logiques (LV) sont dcoups dans les groupes de volumes, puis formats et monts dans des systmes de fichiers ou utiliss en tant que raw devices.
Le gros avantage pour les bases de donnes dun tel systme est la possibilit de
prendre des clichs (snapshots), un LV permettant deffectuer une sauvegarde cohrente dun autre volume logique du mme groupe de volumes. La cration dun
snapshot consiste prendre une photo, un instantan du volume logique cible (ce qui
est quasi-immdiat). Il est alors possible de commencer enregistrer les modifications apportes au volume logique cible.
La lgre perte en performance due au rajout dune couche logique entre systme et
matriel est largement acceptable par rapport la flexibilit apporte.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

118

MySQL 5 Audit et optimisation

JARGON Transactionnel et cohrence, quelles diffrences ?


Une transaction est une opration informatique cohrente qui peut tre compose dune ou plusieurs
tches. Cette opration est valide si toutes les tches ont t effectues (elle est valide par une action
dite de COMMIT). Si elle ne lest pas vous devez revenir dans ltat original (ROLLBACK). Une transaction doit rpondre dans la plupart des cas ces quatre rgles :
Atomicit : ensemble de requtes indivisibles (tout ou rien).
Cohrence : la transaction ne doit pas violer de contraintes dintgrit pendant son excution. Elle doit
laisser la base de donnes dans un tat cohrent. Dans le cas contraire elle doit tre annule et signale.
Isolation : une transaction t1 ne doit pas tre perturbe par t2 si t2 nest pas encore valide. Avec
MySQL la plupart des moteurs de stockage utilise le modle MVCC pour cela.
Durabilit : une fois la transaction termine et quel que soit son tat (COMMIT / ROLLBACK), il faut
assurer que laction a bien t prise en compte. Dans le monde des bases de donnes on parle alors de
logs de transactions (transaction log, redo log...).
Dans le cas de la lecture dun enregistrement, il faut tre sr de lire la bonne valeur (cohrence) mais
nous ne modifions aucun lment. Pour un SGBD, nous diffrencions aussi les verrous en lecture et en
criture.

Lavantage devient vident lorsque nous pensons certaines mthodes de sauvegarde


dune base MySQL. Si nous souhaitons effectuer une sauvegarde physique (non
logique) de MySQL, il faut arrter le serveur (sauvegarde froid) et effectuer une
copie des donnes (cp, rsync, tar) sur un autre disque. Tant que la copie nest pas
termine, le serveur nest pas disponible. Cette mthode est ncessaire lorsquon utilise InnoDB sans outils particuliers tels que InnoDB Hot Backup ou Xtradb Backup.
Avec MyISAM, en revanche, il est possible dutiliser mysqlhotcopy qui verrouille en
lecture seule la base pendant que la copie des fichiers est effectue en local sur le serveur (pas de copie distante).
Utiliser un snapshot permet de bloquer le serveur MySQL pour un minimum de
temps. Une fois la photo prise, il est possible de redmarrer le serveur et de raliser la
copie en tche de fond. Il va de soi que limpact sur le systme de stockage est toujours prsent puisquil faut bien effectuer la copie des donnes. Cependant la base de
donnes naura connu quun temps darrt trs court.
Les snapshots ne sont pas des sauvegardes compltes dun volume logique. Ils enregistrent uniquement les modifications apportes au volume cible et ne contiennent
pas les donnes de celui-ci. De plus, ils ne sont pas persistants, cest--dire quils disparaissent en cas de redmarrage de la machine. Lespace libre que vous devez laisser
dans le groupe de volumes (VG) pour prendre des snapshots dpend essentiellement
de lactivit en criture sur le volume logique cible pendant la dure de vie de ce
snapshot. Encore une fois, le snapshot ne stocke que la diffrence ; plus la diffrence
est grande, plus elle prend despace. Pour une base MySQL, 15 20 % du LV sauvegarder est suffisant.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

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 mthode pour effectuer une sauvegarde froid de MySQL dans un contexte
LVM :
1 Arrtez MySQL.
2 Avec lvcreate -LxxxM -s snapname /dev/vgname/lvname crez un clich de
xxx Mo du LV lvname dans le VG vgname.
3 Dmarrez MySQL.
4 Effectuez la sauvegarde des donnes.
5 Avec lvremove /dev/vgname/snapname dtruisez le clich.
Il existe galement une possibilit deffectuer une sauvegarde sans arrter le serveur
MySQL. Il sagit de verrouiller les tables en lecture, la sauvegarde est alors dite tide
(warm) :
FLUSH TABLES WITH READ LOCK pose un verrou en lecture ; peut prendre du temps
si de lourdes oprations sont dj en cours.
lvcreate -LxxxM -s snapname /dev/vgname/lvname cre un clich de xxx MB
du LV lvname dans le VG vgname.
UNLOCK TABLES dbloque les tables.
Attention : cette commande bloque lcriture des tables. Cependant, avec InnodB
par exemple, elle ninfluence pas les tches de fond du moteur. Il est donc possible,
une fois votre sauvegarde restaure, que InnoDB dmarre en mode recovery.
B.A.-BA Les diffrents types de sauvegardes (backups)
Backup froid : arrt du serveur MySQL, aucune connexion la base nest possible.
Backup chaud : le serveur MySQL continue son activit (InnoDB Hot Backup/tradbbackup),
les applications continuent se connecter, excuter des requtes...
Backup tide (warm) : toutes les tables sont bloques, lapplication continue se connecter, en revanche aucune requte sur les tables en question ne peut tre excute.
Backup logique : opr laide de mysqldump, par exemple. Toutes les commandes SQL permettant de
restaurer la base sont gnres. Cest un backup chaud.
Backup physique : copie des donnes (tar, LVM...).

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

120

MySQL 5 Audit et optimisation

En conclusion, voici un petit rcapitulatif sur les LVM.


Concernant les avantages des volumes logiques (LV) :
possibilit de rpartir des LV sur un ensemble de volumes physiques (similaire au
RAID 0) ;
dupliquer (mirroring) des LV (similaire au RAID 1) ;
faire des clichs (snapshots) ;
changement dun disque dfectueux possible ;
augmentation de la taille dune partition chaud ;
rduction la taille dune partition possible.
Attention : un clich nest pas une sauvegarde complte dun LV. Il enregistre uniquement les modifications apportes.
Les problmes :
avec limplmentation actuelle, des corruptions peuvent arriver mme sur des systmes journaliss 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 dentre intressant : http://www.tldp.org/HOWTO/LVMHOWTO/.

tude de cas : analyse dun serveur MySQL


Jusqu maintenant, nous obtenions des informations partir du serveur MySQL
lui-mme. Il sagit notamment de la rcupration des valeurs de certaines variables
systme ou de statut. Comment aller plus loin et en savoir davantage ?
Voici la marche suivre, tire dun serveur rel nomm ici mysql1.
Quel est le systme dexploitation ?
[borghino@mysql1 ~]$ uname -a
Linux mysql1 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64
x86_64 x86_64 GNU/Linux

Le serveur fonctionne donc sous Linux 64 bits.


Obtenir la distribution de sa machine
[borghino@mysql1 ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 8)

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

121

Nombre de processeurs disponibles


[borghino@mysql1 ~]$ cat /proc/cpuinfo

Cette commande fournit des informations sur le nombre de curs de chacun des processeurs. Ici, un quatre curs Intel Xeon CPU L5320 qui tourne 1,86 GHz. Il est
ainsi possible de vrifier si le processeur est en 64 bits. Cette information est importante,
comme cela est expos au chapitre 2 consacr au matriel. Il nest pas impossible de
croiser un serveur 64 bits utilisant un systme dexploitation ou une instance MySQL en
32 bits. Pour mmoire, un systme 32 bits limite la mmoire virtuelle 4 Go.
Quantit de mmoire vive disponible
[borghino@mysql1 ~]$ cat /proc/meminfo
MemTotal: 8165320 kB

Dtecter les priphriques


[borghino@mysql1 ~]$ dmesg

Lorsquun systme Linux dmarre, le noyau (kernel) est charg en mmoire. Pour
simplifier, on peut considrer que le systme dtecte alors tous les priphriques prsents et un message de diagnostic est produit. En utilisant dmesg (display message), il
est possible de vrifier son matriel.
Quelques informations susceptibles dtre affiches suite cette commande et leur
correspondance :
SCSI device sda : prsence de disques SCSI ;
sda: sda1 sda2 : 2 volumes sont prsents ;
EXT3-fs : le systme de fichier utilis est EXT3 ;
scsi0 : LSI Logic SAS based MegaRAID driver : technologie RAID utilise ;
md: Autodetecting RAID arrays ;
eth0: Broadcom NetXtreme II BCM5708 1000Base-T : la carte rseau est du giga
Ethernet.
Cette recherche dinformation est un peu fastidieuse sous cette forme. Heureusement, il existe des utilitaires qui permettent de rcuprer directement ces lments
sans avoir se rappeler tous les noms de fichiers de configuration.
Prenons par exemple lshw. Cet outil affiche la configuration exacte de la mmoire,
du firmware, de la carte mre, des processeurs, du cache...

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

122

MySQL 5 Audit et optimisation

Installation de lutilitaire lshw


[borghino@mysql1 proc]$ yum install lshw
[borghino@mysql1 proc]$ lshw -short
[borghino@mysql1 proc]$ lshw -class memory

Une fois excut, lshw permet dafficher ce type dinformations :


System: Dell PowerEdge 2950
Processors: 1 x Xeon L5320 1.86GHz 1066MHz FSB (4 cores) 64-bit
Memory: 8GB (4 x 2) 667MHz DDR2
Disk: sda (megaraid_sas0): 438GB (0%) RAID-10/3 == 6 x 146GB 15K SAS/3
Disk-Control: megaraid_sas0: PERC 5/i,

La lecture de la configuration est ainsi facilite : nous sommes ici en prsence de


six disques monts en RAID 10.
Rcuprer les informations relatives lespace disque
[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 pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 sys lvm2 a- 408.11G 25.65G
1 volume physique sda2 utilisant LVM2 qui fait 400 Go
[borghino@mysql1 proc]$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
sys 1 6 0 wz--n- 408.11G 25.65G
1 groupe de volumes rparti sur 1 volume physique qui comporte 6 volumes
logiques
[borghino@mysql1 proc]$ sudo lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
var sys -wi-ao 283.00G
mysql sys -wi-ao 80.00G
root sys -wi-ao 3.91G
swap sys -wi-ao 7.75G
tmp sys -wi-ao 3.91G
les 5 volumes logiques.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

123

Il est trs important de vrifier la configuration RAID de votre machine. En effet


chaque contrleur RAID possde sa propre configuration.
Vu la configuration de la machine, nous allons utiliser lutilitaire megacli.
[borghino@mysql1 ~]$ sudo megacli -LDInfo -L0 -a0 -NoLog
Adapter 0 -- Virtual Drive Information:
Virtual Disk: 0 (target id: 0)
Name:
RAID Level: Primary-1, Secondary-3, RAID Level Qualifier-0
Size:418176MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:2
Span Depth:3
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache
if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache
if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk's Default

RAPPEL write-through/write-back
Cache write-through : toutes les critures seffectuent de faon synchrone avec le disque.
Cache write-back (ou write-behind) : toutes les critures ne seffectuent pas de faon synchrone ; elles
sont caches.
ReadAheadNone : pas de lectures prdictives.
Relisez le chapitre 2 consacr au matriel pour de plus amples informations sur le fonctionnement de ce
type de cache.

La machine est bien configure pour travailler avec une base de donnes
transactionnelle : 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 sont
pas en bon tat, nous risquons de perdre des donnes : No Write Cache if Bad BBU.
Nous connaissons maintenant toutes les caractristiques de la machine. Il reste voir
si elles sont utilises bon escient.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

124

MySQL 5 Audit et optimisation

Mesurer lactivit du serveur


Excutons tout dabord quelques commandes de base :
[borghino@mysql1 ~]$ uptime
16:44:05 up 12 days, 1:45, 1 user, load average: 0.00, 0.00, 0.00
[borghino@mysql1 ~]$ top
Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie
top - 16:44:57 up 12 days, 1:46, 1 user, load average: 0.00, 0.00, 0.00
Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0% us, 0.1% sy, 0.0% ni, 99.9% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 8165320k total, 1441516k used, 6723804k free, 104700k buffers
Swap: 8122360k total, 0k used, 8122360k free, 1149832k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
882 mysql 16 0 428m 66m 6488 S 0.0 0.8 0:00.20 mysqld

Nous en dduisons les informations suivantes :


load average : il sagit du nombre de processus en attente de ressources
(mmoire, CPU, I/O) ;
SWAP : lorsque le serveur na pas assez de mmoire vive, il utilise sa zone dchange
sur disque, dite zone de swap, augmentant ainsi normment les I/O sur le disque, ce que nous souhaitons absolument viter.

Les outils systme


iostat, vmstat

et netstat sont les trois outils les plus courants en ce qui concerne
lanalyse de performances. Ils sont en gnral livrs avec tous les systmes Unix et
sont faciles utiliser :
iostat : cet outil est relatif aux statistiques des entres/sorties (input output statistics). On y trouve galement des informations concernant la mmoire, le swap et
les disques durs ;
vmstat : statistiques sur la mmoire virtuelle ;
netstat : statistiques sur le rseau ;
mpstat : statistique sur les processeurs.

Toutes ces commandes donnent des informations sur les performances et les temps
dattente. Nous cherchons toujours reprer les points de contention, souvent identifis par des temps dattente.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

125

La commande iostat
[borghino@mysql1 ~]$ iostat -dx 5 5
Linux 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 %util
sda 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.08
sda1 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.00
sda2 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.08
dm-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.00
dm-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 41 Lgendes de la commande iostat

Lectures

critures

Signification

rrqm/s

wrqm/s

Les lectures/critures fusionnes au niveau des blocs I/O.


Il est plus simple et plus courant de voir des fusions au niveau des lectures
quau niveau des critures.

r/s

w/s

Les lectures/critures aprs la fusion.

rsec/s

wsec/s

Les secteurs sont des lments 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.

Notez que deux colonnes reprsentent des valeurs moyennes, avgrp-sz et avgqu-sz.
Cette dernire est particulierement intressante :
avgrq-sz : taille moyenne en secteurs des requtes ;
avgqu-sz : taille moyenne des queues de requtes.
est une des informations les plus importantes. Comment sont gres les
actions sur le disque ? Peu de requtes qui attendent peut signifier dans un cas que le
systme nest pas charg, ou alors que toutes les actions sont srialises. Dans lautre cas,
avec une liste de requtes en attente, tous les disques sont occups. Par exemple, dans le
cas dun systme avec des problmes de performance mais pas de contention au niveau
des queues, nous pourrions envisager dutiliser davantage de lectures en avance de phase
pour rpondre aux besoins. Lobjectif est doptimiser les ressources disponibles.
Await : temps moyen pour traiter nos I/O (queue + requte). Plus cette valeur est
haute, moins le systme est performant.
Svctm : temps moyen pour servir les requtes. Plus le systme est charg, moins
cette valeur est importante car des ressources vont tre utilises par ailleurs.
%util : temps pendant lequel les processeurs ont t utiliss pour grer les disques. Plus on approche de 100 %, plus la ressource est proche de la saturation.
avgqu-sz

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

126

MySQL 5 Audit et optimisation

La commande vmstat
[borghino@mysql1 ~]$ vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 6036692 112004 1790568 0 0 8 9 5 8 0 0 100 0
0 0 0 6036692 112004 1790568 0 0 0 0 1013 18 0 0 100 0

La lgende de cette commande est la suivante.


Processus :
r : processus en attente ;
b : processus dormant.
Mmoire :
swpd : virtuelle ;
free : en attente ;
buff : utilise comme buffer ;
cache : utilise comme cache ;
inact : inactive ;
active : active.
Swap :
si : swap en entre ;
so : swap en sortie.
Entres/sorties :
bi : blocs reus ;
bo : blocs envoys.
Systme :
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.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

127

Les commandes netstat et mpstat


(network statistics) affiche les statistiques sur les connexions rseau entrantes et
sortantes, mais aussi sur les tables de routage ainsi que sur les interfaces. Grce elle, il
est possible dvaluer le trafic rseau et didentifier une ventuelle contention, par
exemple reprer certaines connexions en trop grand nombre manant d'un mme port.

netstat

Quant mpstat, elle renseigne sur lactivit du processeur : est-il pleinement utilis
ou en attente ? Quels sont les processus qui lutilisent ? Etc.
Voici un exemple dutilisation de ces deux commandes avec leurs rsultats.
[borghino@mysql1 ~]$ netstat -rn
Kernel IP routing table
Destination Gateway
Genmask
Flags
MSS Window irtt Iface
68.152.212.0 0.0.0.0
255.255.254.0 U
0
0
0
eth0
0.0.0.0
68.152.212.1 0.0.0.0
UG
0
0
0
eth0
[borghino@mysql1 ~]$ mpstat 5 5
Linux 2.6.9-89.ELsmp (mysql1) 09/11/2009
08:00:07 AM CPU %user %nice %system %iowait %irq %soft %idle intr/s
08:00:12 AM all 0.00 0.00 0.00
0.00
0.00 0.00 100.00 1039.43
08: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 dautres outils systme intressants :
oprofile (http://oprofile.sourceforge.net/news/) est un profiler qui permet, lors dun problme de performance CPU, de connatre exactement les lignes de code lorigine de cette perte de temps.
dtrace est un excellent outil, hlas pour linstant limit Solaris.
fincore (http://net.doit.wisc.edu/~plonka/fincore/fincore) permet de vrifier comment le systme
dexploitation cache les fichiers. Cet outil est particulirement utile pour MyISAM vu que nous ne contrlons pas le cache des donns (seuls les index sont mis en cache).
filefrag calcule la fragmentation dun fichier. On peut donc lutiliser pour mesurer la fragmentation des
tables ou dun tablespace.

En plus des outils systme, voici une liste doutils Open Source qui ont t crs autour
de MySQL par des membres de la communaut. Vous trouverez plusieurs catgories,
que ce soit des outils ddis laudit ou lanalyse temps rel diffre (enregistrement
de mtriques).

Outils daudit : MySQLTuner et mysqlreport


MySQLTuner a t cr par Major Hayden en 2006. Il permet dobtenir une analyse
dtaille de la base de donnes. Les messages prsents sont clairs et beaucoup plus
faciles comprendre que ceux issus de la commande SHOW STATUS. Le groupe de

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

128

MySQL 5 Audit et optimisation

DBA Pythian (http://www.pythian.com) est en train de crer une nouvelle version plus
complte de ce script.
B http://mysqltuner.com

Dans lexemple suivant (voir ci-contre), MySQLTuner constate de nombreux problmes :


La version de MySQL est mettre jour.
Le systme doit tre pass en 64 bits.
InnoDB nest pas utilis.
Il y a des tables fragmentes.
Le nombre de connexions maximal a t atteint.
Le cache de requtes est souvent invalid.
Prs de la moiti des tables temporaires cres le sont sur disque et non en
mmoire.
Le nombre maximal de fichiers ouverts simultanment est presque atteint/
Le cache de table est trop faible.
Les actions adquates sont recommandes :
Mettre jour si besoin la version de MySQL
Passer le systme en 64 bits (systme et matriel) si la quantit de RAM prsente
sur le serveur est suprieure 4 Go.
Appliquer un OPTIMIZE TABLE sur les tables qui sont les plus rgulirement mises
jour (nombreux ajouts/suppressions).
Dsactiver le cache de requtes sur celles dont les tables impliques sont mises
jour rgulirement.
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 cres sur disque il est
possible soit doptimiser les requtes SQL qui provoquent ces crations de tables
temporaires (orientez-vous vers celles qui effectuent des tris de type GROUP BY par
exemple) soit daugmenter simultanment les valeurs de max_heap_table_size et
tmp_table_size.
Augmenter la limite du nombre de fichiers ouverts simultanment via la variable
--open-files-limit, celle-ci tant borne par la valeur retourne par la commande systme ulimit.
Concernant les variables ajuster releves par loutil, celui-ci attribue le signe >
quand il recommande daugmenter une valeur et au contraire le signe < lorsquil

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

129

estime souhaitable de la diminuer. Par exemple pour max_connections, la limite des


250 dfinie dans le serveur MySQL est atteinte (251) do sa recommandation de
laugmenter. Ceci est bien sr effectuer dans la mesure des possibilits physiques de
la machine. linverse, le wait_timeout 3600s peut tre rduit afin que le serveur
coupe plus rapidement une connexion considre inactive.
Rappelons encore que MySQL Tuner nest quun outil, dont il ne faut jamais suivre
aveuglment les recommandations. Il faut sattacher y lire dabord des suggestions,
ou des indices.
Types dinformations retournes par MySQLTuner
[borghino@mysql1 ~]$ sudo ./mysqltuner.pl
>> MySQLTuner 1.0.0 - Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at http://
mysqltuner.com/
>> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please 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)

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

130

MySQL 5 Audit et optimisation

[OK] Table locks acquired immediately: 99% (18M immediate / 18M locks)
[!!] Connections aborted: 24%
-------- Recommendations ----------------------------------------------------General recommendations:
Add skip-innodb to MySQL configuration to disable InnoDB
Run OPTIMIZE TABLE to defragment tables for better performance
Reduce or eliminate persistent connections to reduce connection usage
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Your applications are not closing MySQL connections properly
Variables 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 dviter la multiplication des installations des outils de
surveillance. En effet la plupart dentre eux possdent la fameuse option -h permettant de pointer vers
la machine cible.
En plus de limiter linstallation proprement dite des programmes/scripts de surveillance, procder une
surveillance distance permet de ninstaller que le strict ncessaire sur les machines de production (pas
de librairies externes ou de langages de script superflus).
Attention, ce mode de surveillance prsente un inconvnient : si vous perdez, pour une raison quelconque, la machine sur laquelle est installe lintgralit de vos outils, vous voil aveugle.

mysqlreport fournit peu prs les mmes informations. vous de le tester et dutiliser
loutil qui vous intresse le plus. Sil vous manque une information cruciale, pourquoi
ne pas participer la vie du projet et apporter votre contribution ? Les outils MySQL
et le serveur MySQL lui-mme se sont dvelopps grce la communaut.
B http://hackmysql.com/mysqlreport

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

131

Outils danalyse temsp rel : mytop, mtop, innotop et maatkit


Une fois que nous possdons une vue de lensemble, il est temps danalyser la base en
temps rel.
mytop (http://jeremy.zawodny.com/mysql/mytop/) possde, comme la commande top qui
permet dobserver les processus lancs sur un serveur, la mme logique. Il propose
de visualiser facilement les requtes, les threads et les performances du systme. Cet
outil a t crit par Jeremy Zawodny dans les annes 2000. La dernire version date
de 2007, mais le dveloppement nest plus trs actif depuis quelques annes.
innotop est apparu en 2006. Les outils comme mytop (2003) et mtop (2004)
ntaient plus maintenus et manquaient surtout dune capacit essentielle : lanalyse du moteur InnoDB. En effet, pour suivre en temps rel ce qui se passe dans
ce moteur, nous ne disposions que de la commande SHOW INNODB STATUS, plutt
difficile lire. Nous y trouvons des informations sur les verrous, les smaphores...
Innotop rend ces informations lisibles et les complte de renseignements pertinents. Ce script a t crit par Baron Schwartz (http://code.google.com/p/innotop/).
Impossible dvoquer Baron sans parler de Maatkit (http://www.maatkit.org/). Si Maatkit
ne permet pas de surveiller votre serveur, cest en revanche un ensemble de scripts
trs pratiques. Parmi ces scripts, on trouve mk-table-checksum qui permet de vrifier que les tables du matre et de lesclave sont bien identiques. mk-parallel-dump
permet quant lui dutiliser plusieurs instances de mysqldump en parallle.
Les outils que nous venons dvoquer fournissent des informations sur ltat actuel
du systme, permettant ainsi de dtecter plus facilement les goulets dtranglement.
La prochaine tape consiste tenter danticiper ces ralentissements.
Combien dI/O le systme est-il capable de supporter ? Comment cela se traduit-il
sur la base et sur lapplication ?
Ceci nous amne aux deux prochains thmes : valuer les performances dun systme
et le capacity planning.

valuer les performances dun systme


Analyser et comprendre son systme (systme dexploitation, matriel...) sont deux
points essentiels concernant laudit et la performance dun serveur. Ltape suivante est
den connatre les limites. Pour cela, il ny a quune seule option possible : le benchmark. Il sagit dun banc dessai permettant de mesurer les performances dun systme
pour le comparer dautres.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

132

MySQL 5 Audit et optimisation

Il existe des centaines de possibilits et il est trs difficile de modliser par les tests le
futur fonctionnement dune application. Parmi les principaux types de tests on peut
identifier les suivants :
tests de charges ;
tests de performances ;
tests de stress ;
tests de robustesse ;
tests de capacit.
Tester un systme est une tche qui prend beaucoup de temps et constitue un luxe
que peu dentre nous peuvent soffrir. Nous allons donc nous concentrer sur
lessentiel : le disque, traditionnel goulet dtranglement pour une base de donnes.
Afin de tester les capacits des disques, nous vous conseillons lutilisation de
Bonnie++.
Bonnie++ sappuie sur Bonnie, un outil de type benchmark spcialis dans les disques
durs. Une des amliorations importantes de cet outil est le support pour des fichiers
de plus de 2 Go et des rpertoires comportant des milliers de fichiers. Grce cet
outil, il est par exemple possible de distinguer les diffrences de performance en
fonction des diffrentes options dune configuration RAID. Les informations analyses sont la vitesse de lecture, la vitesse dcriture et le nombre doprations sur
disque (seek) qui peuvent tre traites par seconde.
JARGON Le smoke test, un test aux limites
Ce type de test est galement appel smoke test, autrement dit un test qui pousse le systme dans ses
retranchements, quitte ce quil dgage de la fume si daventure un composant dfectueux dcide de
griller.

Un test bonnie++ prend environ 10 minutes. Nous allons utiliser la commande


suivante : bonnie++ -f -n 256
-n 256 pour forcer Bonnie afficher tous les rsultats.
-f pour forcer lutilisation de la fonction fsync(). Ce paramtre est important
selon que lon souhaite effectuer des tests pour une base de donnes ou un serveur
de messagerie.
Lancement du test bonnie++
Tests run: Sequential output (block, rewrite), Sequential Input (block), Random
(seeks)
[borghino@mysql1 bonnie++-1.03e]$ bonnie++ -f -n 256

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start '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------Per Chr- --Block-- -RewriteMachine
Size K/sec %CP K/sec %CP K/sec %CP
mysql1
16G
132920 32 62411 11
------Sequential Create------Create-- --Read--- -Delete-files /sec %CP /sec %CP /sec %CP
256 49654 90 384386 99 22295 44

133

--Sequential Input- --Random-Per Chr- --Block-- --Seeks-K/sec %CP K/sec %CP /sec %CP
234892 19 805.4
1
--------Random Create--------Create-- --Read--- -Delete-/sec %CP /sec %CP /sec %CP
50144 89 +++++ +++ 14646 33

Operating System A:
Version 1.02
Machine
tr

Size
512M

files
16

------Sequential Output------Per Chr- --Block-- -RewriteK/sec %CP K/sec %CP K/sec %CP
26157 94 36552 39 15361 19
------Sequential Create------Create-- --Read--- -Delete-/sec %CP /sec %CP /sec %CP
97
1 +++++ +++
119
0

--Sequential Input- --Random-Per Chr- --Block-- --Seeks-K/sec %CP K/sec %CP /sec %CP
19900 94 37817 21 899.6
4
--------Random Create--------Create-- --Read--- -Delete-/sec %CP /sec %CP /sec %CP
95
1 +++++ +++
263
1

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 mesures, examinons les performances de
MySQL. Pour cela, nous allons utiliser loutil sysbench.
Il est possible dobtenir les performances en criture et lecture avant de tester le serveur MySQL lui-mme :
Lancements de sysbench sans connexion au serveur MySQL
[borghino@mysql1 sysbench]$ sysbench --test=fileio --max-time=60 --maxrequests=1000000 --file-num=1 --file-extra-flags=direct --file-fsync-freq=0
--file-total-size=128M --num-threads=64 --file-test-mode=rndwr run

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

134

MySQL 5 Audit et optimisation

Operations performed: 0 Read, 187852 Write, 0 Other = 187852 Total


Read 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 --maxrequests=1000000 --file-num=1 --file-extra-flags=direct --file-fsync-freq=0
--file-total-size=128M --file-test-mode=rndrd --num-threads=64 run
Operations 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

En conclusion de ces tests, avec 64 threads en parallle sur un fichier on obtient :


criture : 3k 16k 50 Mo/s ;
lecture : 22k 16k 355 Mo/s.
Les rsultats correspondent avec ceux de Bonnie++.
Ajoutons maintenant MySQL dans le test sysbench :
Excution de sysbench corrle au serveur MySQL
sysbench --test=oltp --mysql-host=localhost --db-driver=mysql --oltp-tablename=big --oltp-table-size=30000000 --num-threads=$1 --max-requests=10000000 -mysql-engine-trx=auto --mysql-table-engine=innodb --max-time=900 --myisam-maxrows=120000000 cleanup
Une table InnoDB avec 30 millions d'enregistrements est cre. Les tests seront
limits 15min.
sysbench -mysql-host=localhost --db-driver=mysql --oltp-table-name=big --oltptable-size=30000000 --num-threads=64 --max-requests=10000000 --mysql-enginetrx=auto --mysql-table-engine=innodb --max-time=900 --myisam-max-rows=120000000
--oltp-test-mode=complex --oltp-dist-type=special --oltp-dist-pct=10 --oltpdist-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 test
Using 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:
write:
other:
total:

16924270
8462135
3384854
28771259

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4
transactions:
deadlocks:
read/write requests:
other operations:

135

1692427 (1880.39 per sec.)


0
(0.00 per sec.)
25386405 (28205.87 per sec.)
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):
execution time (avg/stddev):

26444.1719/140.83
899.6638/0.01

Conclusion : environ 30 000 requtes par seconde sont traites sur ce systme.
Ces tests nous ont permis dobtenir un complment dinformations qui permet de dessiner les limites du systme. Il est alors plus ais danticiper les points de contention.
Anticiper et prvenir nous amne dans un autre apart, celui de la planification des
capacits du systme (capacity planning).
MTHODE Dimensionnement : les bons tests
Un bon test est celui qui vous permet den apprendre davantage sur votre environnement et ses limites.
Prenons par exemple le cas dune voiture. Savoir que celle-ci peut rouler 200 km/h ne sert rien si vous
ne dpassez pas les 130 km/h. En revanche, connatre la diffrence de consommation de carburant entre
120 km/h et 130 km/h est pertinent.
Imaginons maintenant que nous analysions un site web prsentant des informations sportives. Il faut
absolument connatre la correspondance entre le nombre de pages vues et le nombre de requtes gnres en base de donnes. Ces requtes vont elles-mmes se traduire en nombre daccs disque. Une
seule solution : tester toute la chane.

Que faire des rsultats prcdemment obtenus : sont-ils bons ou mauvais ? Finalement
la question nest pas l. Nous savons dsormais quelles sont les performances sur de tels
systmes. vous de dterminer si celles-ci sont suffisantes en fonction de vos besoins.
Dans le cas prsent, si votre systme en pleine charge doit tre capable de supporter
30 000 requtes, dcrire plus de 50 Mo/s ou de lire plus de 355 Mo/s, alors tout va
bien. Dans le cas contraire, il est temps de trouver un moyen daugmenter la capacit
de lensemble, soit au niveau du serveur, de larchitecture ou de lapplication.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

136

MySQL 5 Audit et optimisation

Dautres outils existent sur le march que nous ne pouvons pas tous prsenter ; en
voici quelques exemples que vous pouvez examiner.
Pour tester votre systme :
LMBench : http://www.bitmover.com/lmbench/
unixbench : http://www.tux.org/pub/tux/niemi/unixbench/
Pour tester votre rseau :
dbench : http://samba.org/ftp/tridge/dbench/
Pour tester vos CPU/mmoire :
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 requtes :
mysqlslap : http://dev.mysql.com/doc/refman/5.1/en/mysqlslap.html
supersmack : http://vegan.net/tony/supersmack/

Bien dimensionner un systme (capacity planning)


Le capacity planning (ou gestion de la capacit dun systme) est aussi appel right
sizing. Cette mthode a pour but de dvelopper un modle, une hypothse, sur la
charge future des serveurs et la faon de grer cette charge.
Dans cette optique il faut dfinir :
des niveaux de services adquats ;
un surplus de machine raisonnable ;
une tolrance aux erreurs ;
une gestion des mises jours (logicielles ou matrielles) ;
un cycle de vie appropri.
Le capacity planning a pour but de dterminer quels vont tre les besoins en fonction
des changements des produits. Par exemple, larchitecture dun site web comprend
probablement un serveur de base de donnes et un serveur web Apache/PHP.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

137

Jusque-l, du classique. Nouvelle hypothse, ce systme doit faire face un vnement trs mdiatique augmentant du mme coup de faon trs significative le trafic
Internet du systme... Que faut-il faire pour supporter la charge ? Cest en imaginant
ce type de scnarios que vous devez dfinir une architecture. Sil est bien souvent
impossible de dfinir son systme en se basant sur un pic de charge, avoir en tte
quun tel pic puisse survenir est une bonne pratique.
Dans cet exemple, la capacit correspond au trafic maximal sur le site web sans quil y
ait de dgradations (performances de lapplication, temps de rponse...).
Une bonne gestion consiste supprimer les anomalies entre la capacit du systme et
les besoins des clients. Un systme sous-utilis est plus souhaitable quun systme
suremploy. Il faut trouver le juste milieu en sachant prvoir :
les pics occasionnels ;
la monte en charge ;
les augmentations de trafic.
Il existe plusieurs modles mathmatiques pour calculer la capacit dun systme,
comme :
nombre de machines (% dutilisation) x (% defficacit)

Par efficacit, nous entendons les critres suivants :


Les objectifs sont-ils atteints?
Les systmes sont-ils correctement utiliss ?
Les utilisateurs sont-ils satisfaits ?
Ltude du cot vs le revenu est-elle satisfaisante ?
Nous pouvons galement appliquer diffrentes stratgies :
anticipation (lead) : ajouter de la capacit en anticipant la demande. Cest une
stratgie offensive qui a un cot assez important et est souvent source de gaspillage.
retard (lag) : ajouter de la capacit une fois que le besoin sest fait sentir. Nous
gaspillons moins de ressources, mais, pour un site Internet, un mauvais temps de
rponse ou une interruption de services engendre souvent une perte de revenus ou
dutilisateurs.
modre (match) : ajouter de la capacit petit petit en fonction des besoins.
Nous allons adapter ces stratgies. La premire question se poser lorsquun problme apparat est tout dabord de sassurer quil sagit bien dun problme de capacit. En effet, un bogue, de mauvaises pratiques, un problme de scurit... peuvent
tre la cause dennuis sans pour autant que soient atteintes les limites du systme.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

138

MySQL 5 Audit et optimisation

Dans tous les cas, lorsquon voque la notion de capacit, il faut dans un premier
temps oublier les performances. Nous ne sommes plus l pour optimiser mais pour
connatre les limites actuelles du systme.
partir de cet instant, il faut tre certain que tous les systmes de surveillance sont
activs. Cest en effet en visualisant comment la plate-forme se comporte que nous
allons collecter suffisamment dinformations pour grer la capacit. Voici ce quil faut
mesurer :
les mtriques entre/sortie ;
les mtriques applicatifs (comme le nombre de pages vues).
Il est trs important de faire le lien entre les deux afin de pouvoir comparer les informations. En effet, 300 Mo/s en lecture sur la base de donnes nest pas trs parlant a
priori... En revanche, savoir que 300 Mo correspondent 200 000 pages vues, traduit lapparition dune tendance et il devient possible de quantifier le nombre de
requtes auquel le systme sera soumis.
SAVOIR La notion de seuil
Une notion trs importante est celle des plafonds ou seuils. Par exemple, si un serveur web a une utilisation de CPU 50 %, jusqu quel pourcentage dutilisation du processeur pouvons-nous monter sans
connatre de problmes de stabilit ? Ce pourcentage dterminera le plafond. Dans le cas dun plafond
dfini 80 %, avec une consommation processeur de 50 % comme ici, nous disposons de 30 % marge
de manuvre.

Dans cette quation, linconnue est le temps. Au bout de combien de temps, si le trafic
augmente rgulirement, allons-nous atteindre ces 80 %. Une fois cette inconnue limine, nous pourrons quantifier sous quel dlai il faudra ajouter des machines.
Fityk est un outil qui permet de calculer ce type dinformations (http://www.unipress.waw.pl/
fityk/).

Connatre la capacit, cest connatre le systme avec les pics haut et bas... En effet, si le
trafic augmente trop rapidement, cela signifie quun vnement spcial a lieu. Inversement, le trafic peut chuter dun coup. Dans les deux cas une alerte doit tre lance.
Augmenter la capacit peut la fois signifier tre capable daugmenter le nombre de
serveurs mais galement de conserver le mme nombre de machines en augmentant
leur puissance : davantage de curs, de RAM, de disques (scaling-up).
LIRE La monte en charge matrielle
Le chapitre 2 consacr au matriel revient plus prcisment sur les notions de scaling-up/scaling-out.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Surveiller son serveur MySQL


CHAPITRE 4

139

Enfin, gardez lesprit quun point de contention en cache toujours un autre. Si


ajouter des serveurs web va potentiellement rsoudre une contention en entre dune
plate-forme, cela va srement augmenter la charge sur la base de donnes qui sera
alors le prochain point surveiller de prs.
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-9780596518578
R J. Gabs, N. Makarvitch, Nagios 3 pour la supervision et la mtrologie, Eyrolles 2009

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

5
Exploiter les journaux de MySQL
linstar des botes noires qui enregistrent les donnes de vol dun avion, les fichiers
de journalisation ou logs gardent la trace des vnements survenus sur un serveur
MySQL. Dans ce chapitre, nous allons vous prsenter les principaux logs serveur de
MySQL, leurs rles respectifs et expliquer comment bien les utiliser.
Ces fichiers, trs utiles ladministrateur, ont la particularit de permettre deffectuer
des tches aussi varies que la restauration de la base de donnes, lidentification des
requtes problmatiques, laide la prvention des incidents ou tout simplement
doffrir ladministrateur les moyens de comprendre pourquoi le serveur est en panne.
Sur un serveur en production, dimportants volumes de donnes peuvent tre journaliss. Il est donc fortement conseill de mettre en place des procdures pour surveiller
les espaces de stockage. En effet, certains fichiers de logs peuvent, en fonction de la
volumtrie et/ou de la charge du serveur, grossir rapidement.
Limpact de ces fichiers sur les performances du serveur est un autre point important
garder lesprit. Par exemple, le journal gnral, sil stocke ces informations dans la
table qui lui est ddie (mysql.general_log), peut diminuer les performances de
votre serveur de moiti. Le bon rglage est bien souvent le rsultat dun compromis...
MySQL possde 4 types de journaux serveur :
le journal des erreurs (error log) ;
le journal gnral (general query log) ;
le journal des requtes lentes (slow query log) ;
le journal binaire (binary log).

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

142

MySQL 5 Audit et optimisation

Le journal des erreurs


Activ par dfaut, ce fichier se reconnat grce son extension .err. On le retrouve
gnralement sous la forme nom_machine.err. Il est situ, l encore par dfaut, dans
le rpertoire de donnes (que vous pouvez identifier avec la commande SHOW GLOBAL
VARIABLES LIKE 'datadir'). Il est possible de changer son nom, lexception du
suffixe, et de le placer un autre endroit, laide de loption log-error, au dmarrage du serveur en ligne de commandes :
mysqld --log-error = /appli/log/mysql-error.err

ou alors dans le fichier de configuration, dans la section serveur (mysqld) :


[mysqld]
log-error = /appli/log/mysql-error.err

Notez que si vous dmarrez le serveur en ligne de commande avec loption --console,
les informations du journal des erreurs ne safficheront que dans stderr (a priori dans
la console).
Pour localiser le journal des erreurs, vous pouvez utiliser la commande SHOW
dans un client MySQL :

GLOBAL

VARIABLES

Localiser le journal des erreurs


mysql> SHOW GLOBAL VARIABLES LIKE 'log_error' \G
***************** 1. row ******************
Variable_name: log_error
Value: /appli/log/mysql-error.err

Le journal des erreurs est un fichier qui grossit au fil du temps. Sa gestion est en fait
assez basique : vous avez la possibilit de fermer (flush) le journal courant et den
ouvrir un autre avec la commande FLUSH LOGS. Le serveur renommera le fichier en le
compltant par la chane de caractres -old et un nouveau fichier vide sera cr avec
lancien nom :
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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Exploiter les journaux de MySQL


CHAPITRE 5

143

ASTUCE Rotation des journaux avec logrotate


Pour faciliter la gestion du journal des erreurs, vous pouvez utiliser loutil de maintenance logrotate et
planifier des tches (cron) pour ventuellement compresser et dplacer lhistorique trop ancien. Un des
auteurs de ce livre en est devenu un adepte aprs avoir rencontr des problmes avec MySQL 4.0 en
environnement FreeBSD 4.

Identifier et rsoudre les problmes


Les informations consignes dans le fichier de journalisation des erreurs peuvent tre
lorigine de la rsolution dun certain nombre de problmes. Il est par exemple possible dy dceler un redmarrage non prvu. Dans le cas suivant, le processus mysqld a
t arrt 17h55, puis redmarr par le processus mysqld_safe.
Arrt et redmarrage du serveur
shell> cat mysql-error.err
090812 17:20:44 mysqld_safe Starting mysqld daemon with databases from /home/
daz/sandboxes/msb_5_1_35/data
090812 17:20:44 InnoDB: Started; log sequence number 0 6973121
090812 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)
Killed
090812 17:55:07 mysqld_safe Number of processes running now: 0
090812 17:55:07 mysqld_safe mysqld restarted
090812 17:55:08 InnoDB: Started; log sequence number 0 6973121
090812 17:55:08 [Note] Recovering after a crash using /appli/log/mysql-bin
090812 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)

Modifier le tablespace ou les journaux dInnoDB


Une erreur courante est de penser que changer la taille du tablespace
(innodb_data_file_path) ou celle des journaux dInnoDB (innodb_log_file_size)
seffectue simplement en modifiant ces paramtres dans le fichier de configuration.
En fonction de votre version de MySQL, au mieux le serveur ne dmarrera pas, au
pire, il dmarrera mais sans lancer le plug-in InnoDB. En dautres termes, les tables
InnoDB ne seront plus accessibles.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

144

MySQL 5 Audit et optimisation

Pour modifier ces paramtres, il faut oprer une sauvegarde logique des tables InnoDB,
arrter le serveur MySQL en vrifiant quil ny a pas derreurs, dplacer le tablespace et
les journaux dInnoDB (vous pourrez les supprimer une fois lopration termine avec
succs). Redmarrez ensuite le serveur MySQL avec la nouvelle configuration et
rejouez votre sauvegarde. Vrifiez dans le journal des erreurs que tout sest bien pass.
shell> cat mysql-error.err
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: 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 event
090928 19:13:46 [Note] /usr/local/mysql/5.1.35/bin/mysqld: ready for
connections.
...
shell> cat mysql-error.err
InnoDB:
InnoDB:
InnoDB:
InnoDB:
...

Error: data file ./ibdata1 is of a different size


1152 pages (rounded down to MB)
than specified in the .cnf file 640 pages!
Could not open or create data files.

Paramtre incorrect dans le fichier de configuration


Une simple erreur de frappe, sur le nom dun paramtre et le serveur refuse de
dmarrer. Dans lexemple qui suit, on identifie donc la cause du problme et implicitement sa solution. Le vritable nom de la variable nest pas log-binaire mais log-bin.
Paramtre inconnu dans le fichier de configuration
shell> cat mysql-error.err
090812 18:19:50 mysqld_safe mysqld from pid file /appli/log/
mysql_sandbox5135.pid ended
090812 18:19:53 mysqld_safe Starting mysqld daemon with databases from /home/
daz/sandboxes/msb_5_1_35/data
090812 18:19:53 InnoDB: Started; log sequence number 0 6973121
090812 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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Exploiter les journaux de MySQL


CHAPITRE 5
090812
090812
090812
090812

18:19:53
18:19:54
18:19:54
18:19:54

145

InnoDB: Starting shutdown...


InnoDB: Shutdown completed; log sequence number 0 6973121
[Warning] Forcing shutdown of 1 plugins
[Note] /usr/local/mysql/5.1.35/bin/mysqld: Shutdown complete

Si le nom dun paramtre doit tre correctement orthographi, sa valeur doit bien
entendu tre adapte aux besoins de lapplication dans un souci doptimisation. Elle
doit galement tre ajuste aux caractristiques de la machine.
Par exemple, il nest pas permis dallouer un buffer dune taille suprieure la possibilit
dallocation du serveur. Si tel est le cas, MySQL va alors essayer de procder au mieux.
Par exemple, si le paramtre innodb_buffer_size est trop grand, la sanction est
immdiate : le serveur ne dmarre pas. Si la valeur du paramtre key_buffer_size est
surdimensionne, elle est ramene la taille maximale supporte.
090812 18:15:58 mysqld_safe mysqld from pid file /appli/log/
mysql_sandbox5135.pid ended
090812 18:16:00 mysqld_safe Starting mysqld daemon with databases from /home/
daz/sandboxes/msb_5_1_35/data
090812 18:16:01 InnoDB: Error: cannot allocate 2147500032 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 25166072 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: 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


systems
090812 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/data
090812 18:29:42 [Warning] option 'key_buffer_size': unsigned value 8589934592
adjusted to 4294963200
090812 18:29:42 InnoDB: Started; log sequence number 0 6973121
090812 18:29:42 [Note] Event Scheduler: Loaded 0 events
090812 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)

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

146

MySQL 5 Audit et optimisation

Erreurs lies la rplication


Comme nous lavons voqu plus tt, le journal des erreurs permet de surveiller certaines fonctionnalits de MySQL, dont la rplication (la rplication est expose en
dtail au chapitre 8, La rplication MySQL). Dans cet usage, le journal des erreurs
nindique pas que des mauvaises nouvelles. Sur une machine esclave, les informations
relatives au dmarrage de la rplication, notamment le thread I/O et le thread SQL,
y sont notes :
090813 14:12:14 [Note] Slave I/O thread: connected to master
'machine_maitre@127.0.0.1:23150',replication started in log 'mysqlbin.000001' at position 4357768
090813 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

Sur lexemple suivant, notez un arrt puis un redmarrage du thread SQL :


090813 16:45:56 [Note] Error reading relay log event: slave SQL thread
was killed
090813 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

Une rplication en chec peut avoir plusieurs origines (le serveur matre nest plus
accessible, une erreur de requte sur le serveur esclave...). L encore, des informations
sont journalises dans le journal des erreurs de la machine esclave et permettent souvent dliminer de mauvaises pistes. Dans le premier extrait de log qui suit, on saperoit que la machine esclave a perdu la connexion avec la machine matre. Dans le
second, des critures sur le serveur esclave sont lorigine de la violation de la contrainte dunicit de la cl primaire (Duplicate entry). Dans les deux cas, la rplication
est casse.
Connexion perdue entre serveurs matre et esclave
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 4357768
090813 14:25:41 [ERROR] Slave I/O: error reconnecting to master
'machine_maitre@127.0.0.1:23150' - retry-time: 60 retries: 86400,
Error_code: 2013

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Exploiter les journaux de MySQL


CHAPITRE 5

147

Violation de la contrainte dintgrit sur lesclave


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', 'olivier@dasini.net', 1)', Error_code:
1062
090813 17:02:55 [Warning] Slave: Duplicate entry '1' for key 'PRIMARY'
Error_code: 1062
090813 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

Erreurs diverses
Le programmateur dvnements ou event scheduler est apparu avec MySQL 5.1.6. Il
offre la possibilit ladministrateur de bases de donnes de dclencher lexcution
de requtes programmes directement dans le serveur MySQL. Il permet donc,
comme avec les commandes cron ou tches planifies, dautomatiser trs simplement
des tches des intervalles rguliers, ou heure fixe, sans avoir besoin de configurer
le systme sur lequel la base de donnes fonctionne. Le journal des erreurs permet
dtre averti si lune des tches ne sest pas droule correctement.
090813 17:40:05 [Note] Event Scheduler: scheduler thread started with id 3
090813 17:53:14 [ERROR] Event Scheduler:
[daz@localhost][_event.vue_materialisee] Table '_event.City_fra' doesn't exist
090813 17:53:14 [Note] Event Scheduler:
[daz@localhost].[_event.vue_materialisee] event execution failed.

La cohrence des donnes est un point trs important, que votre base de donnes
doit assurer. Aprs un arrt brutal, si vous utilisez des tables InnoDB, un mcanisme
appel crash recovery est enclench automatiquement au redmarrage de linstance. Il
a pour but de mettre la base dans un tat propre :
090806 18:03:19
090806 18:03:19
090806 18:03:19
090806 18:03:19
090806 18:03:19
connections.

InnoDB: Started; log sequence number 0 6973081


[Note] Recovering after a crash using /appli/log/mysql-bin
[Note] Starting crash recovery...
[Note] Crash recovery finished.
[Note] /usr/local/mysql/5.1.35/bin/mysqld: ready for

En revanche, MyISAM noffre pas de mcanismes automatiques pour assurer la


cohrence des donnes. Cependant, avec loption myisam_recover, vous avez la possibilit de vrifier toutes les tables MyISAM chaque dmarrage du serveur.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

148

MySQL 5 Audit et optimisation

Si des tables corrompues sont dtectes, linformation se retrouvera encore une fois
dans le journal des erreurs :
090814 11:28:29 [ERROR] /usr/local/mysql/5.1.35/bin/mysqld: Table './test/City'
is marked as crashed and should be repaired
090814 11:28:29 [Warning] Checking table: './test/City'
090814 11:28:29 [Warning] Recovering table: './test/City'

Une requte sur une table MyISAM identifie comme corrompue (marked as
crashed), va renvoyer une erreur au client ; de plus cette information sera inscrite dans
le journal des erreurs :
090814 11:05:09 [ERROR] /usr/local/mysql/5.1.35/bin/mysqld: Table './
test/City' is marked as crashed and should be repaired
090814 11:05:09 [ERROR] /usr/local/mysql/5.1.35/bin/mysqld: Incorrect
key file for table './test/City'; try to repair it
090814 11:05:09 [ERROR] Couldn't repair table: test.City

ATTENTION Effets de bord de loption myisam_recover


Avec loption myisam_recover, le serveur MySQL risque de mettre beaucoup plus de temps pour
dmarrer.

Le journal des requtes lentes


La dure dexcution dune requte est un paramtre qui sert souvent de mtrique
dans lvaluation des performances dune base de donnes. Dans limaginaire collectif, plus les requtes sont rapides, plus la base de donnes est performante. Bien
que la ralit soit un peu moins triviale, une requte dont la dure dexcution est
trop longue est parfois la consquence dun mauvais schma, dun serveur mal rgl
ou tout simplement dindex mal ou pas utilis du tout.
MySQL vous offre la possibilit didentifier ce type de requtes grce son journal
des requtes lentes.

Principe de fonctionnement
Pour activer le journal des requtes lentes (car il ne lest pas par dfaut), il suffit de
placer dans le fichier de configuration, dans la section [mysqld] loption
slow_query_log. Il est de plus conseill, mme si cela nest pas obligatoire, de spcifier son nom (et ventuellement son chemin) laide de loption general_log_file.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Exploiter les journaux de MySQL


CHAPITRE 5

149

Au redmarrage du serveur, toutes les requtes plus lentes que le paramtre


long_query_time y seront insres. La valeur de long_query_time est de 10 secondes
par dfaut ; il est videmment possible de lui donner une autre valeur, avec une prcision de lordre de la microseconde.
Une autre option, bien pratique, permet de journaliser les requtes qui nutilisent pas
dindex ; il sagit de log_queries_not_using_indexes. Ces requtes seront inscrites
dans le journal des requtes lentes, mme si leur dure dexcution nest pas plus
longue que long_query_time :
Activer le journal des requtes lentes
[mysqld]
# Activer la journalisation des requtes lentes
slow_query_log
slow_query_log_file = /appli/log/mysql-slow.log
long-query-time = 2
log_queries_not_using_indexes

ATTENTION Effets de bord de loption log_queries_not_using_indexes


Votre journal peut devenir trs verbeux. Parfois, il est moins coteux loptimiseur de choisir danalyser
entirement la table (full table scan) que dutiliser un index. Par consquent, les requtes journalises
avec loption log_queries_not_using_indexes, ne seront pas forcment toutes des requtes
problmatiques. Aucun des auteurs de ce livre ne lactive habituellement.

Deux autres filtres peuvent vous intresser. Tout dabord, min_examined_row_limit


permet de dfinir le nombre denregistrements minimal que doit examiner la requte
pour quelle puisse tre stocke dans le journal. Ce paramtre peut vous permettre
dobtenir une journalisation moins verbeuse, donc un fichier qui grossit moins vite.
Ensuite, log-slow-admin-statements server vous donne la possibilit denregistrer
les longues commandes dadministration, telles que OPTIMIZE TABLE, ALTER TABLE...
Vous venez de le voir : activer le journal implique de modifier le fichier de configuration
et par consquence un redmarrage du serveur MySQL. Cette manipulation peut donc
tre assez gnante dans un environnement de production. partir de MySQL 5.1, le
journal peut tre activ dynamiquement ( chaud) avec la commande SET GLOBAL.
Comme pour tous les changements chaud cette modification nest pas persistante,
cest--dire quen cas de redmarrage du serveur, la nouvelle valeur est perdue. Pour
rendre ce changement permanent, une astuce consiste changer le paramtre dynamiquement et le placer dans le fichier de configuration, comme expos ci-dessus.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

150

MySQL 5 Audit et optimisation

Attention cependant ne pas vous tromper dans la syntaxe du paramtre, parce qu


la moindre erreur, le serveur ne redmarerra pas !
mysql> SET GLOBAL slow_query_log=ON;

Voici un exemple de journal des requtes lentes :

# 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;

Comme vous pouvez le constater, la requte nest pas la seule information contenue.
On y retrouve dautres informations utiles telles que :
le moment et lheure de linsertion de la requte dans le fichier ;
lutilisateur qui a excut la requte ;
le temps dexcution de la requte ;
la dure pendant laquelle la ressource (la table), est verrouille. noter que ce
temps dattente nest pas comptabilis dans la dure de la requte ;
le nombre denregistrements renvoys par la requte ;
le nombre denregistrements traits ;
le timestamp o la requte a t enregistre dans le fichier ;
la requte lente proprement dite. Lordre des requtes dans le journal des requtes
lentes ne correspond pas forcment leur ordre dexcution.
La structure du fichier est finalement assez simple. En revanche, dans lenvironnement de production, il peut devenir assez volumineux et y rechercher une information peut savrer fastidieux.
MySQL fournit un script Perl, nomm mysqldumpslow. Cet outil facilite lanalyse
du journal des requtes lentes en regroupant les requtes par type et en donnant quelques informations, comme le temps dexcution ou encore le nombre de fois que ce
type de requtes apparat dans le journal. Cette dernire faon de classer les commandes est intressante car il faut garder lesprit quune requte longue nest pas
forcement un problme (tche de maintenance, table bien indexe mais particulirement volumineuse) si elle sexcute rarement. Cela dit, une requte plus rapide mais
qui sexcute trs souvent peut tre une excellente candidate loptimisation.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Exploiter les journaux de MySQL


CHAPITRE 5

151

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

Par dfaut, mysqldumpslow va classer les informations du journal par types de


requtes. Cest--dire quil va remplacer les valeurs numriques par la lettre N (number)
et les valeurs chanes de caractres par la lettre S (string). Il donne galement :
le nombre doccurrences ;
les dures moyennes et totales dexcution ;
les dures moyennes et totales des verrous ;
la moyenne et le total du nombre denregistrements traits ;
le compte utilisateur.
Vous trouverez plus de prcisions sur mysqldumpslow et notamment limpact des diffrentes options
dans la documentation de MySQL :
B http://dev.mysql.com/doc/refman/5.1/en/mysqldumpslow.html

ALTERNATIVE Autres outils danalyse


Dautres outils permettent danalyser les journaux des requtes lentes : mysqlsla, mysql_slow_log_filter
et mysql_slow_log_parser :
B http://hackmysql.com/mysqlsla
B http://www.mysqlperformanceblog.com/files/utils/mysql_slow_log_filter
B http://www.mysqlperformanceblog.com/files/utils/mysql_slow_log_parser

Quel que soit loutil utilis, les instructions SELECT identifies peuvent tre optimises avec la commande EXPLAIN afin de vrifier que les index sont correctement utiliss et pertinents.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

152

MySQL 5 Audit et optimisation

Cependant, il faut noter quamliorer la vitesse des commandes SELECT en ajoutant


des index sur une table peut avoir comme effet collatral un ralentissement des performances dcriture de cette table. En ce qui concerne les requtes UPDATE et DELETE,
une astuce consiste prendre leur clause WHERE et la placer la suite dun SELECT *.
mysql> UPDATE client SET client_name = 'karen' WHERE id = 4 /* requte
optimiser */
mysql> EXPLAIN SELECT * FROM client WHERE id = 4 /* astuce
d'optimisation */

Journaliser dans une table


Activer ou dsactiver la journalisation requiert une intervention dans le fichier de
configuration et un redmarrage du serveur. En dautres termes, ces changements
seffectuent froid. partir de MySQL 5.1.6, toutes ces manipulations peuvent
soprer chaud. De plus, MySQL vous donne la possibilit de journaliser les
requtes lentes dans la table systme mysql.slow_log. Le paramtre log_output
permet de choisir entre stocker les donnes 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 trs proche de celle du fichier journal des
requtes lentes. Cependant la prcision du temps est moins fine dans la table que
dans le fichier (par exemple, 1,053634 seconde dans le fichier sera reprsent par
00:00:01 dans la table). Notez que cette table nest accessible quen lecture. Pour la
vider, utilisez la seule commande possible ici : TRUNCATE TABLE.
mysql> SET GLOBAL slow_query_log = 'ON';
-- active le journal des requtes lentes
mysql> SET GLOBAL log_output = 'TABLE';
-- sauvegarde les informations du journal des requtes lentes dans la table
mysql.slow_log
mysql> SET GLOBAL log_queries_not_using_indexes = 'OFF';
-- dsactive la journalisation des requtes 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:01
lock_time: 00:00:00
rows_sent: 1
rows_examined: 211479

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Exploiter les journaux de MySQL


CHAPITRE 5

153

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 entirement la table

Le journal gnral des connexions et requtes


Le journal gnral (general log) permet denregistrer toute lactivit du serveur. Il
stocke les informations relatives la connexion et la dconnexion des clients ainsi
que toutes les requtes et toutes les commandes qui arrivent au processus mysqld,
quelles soient valides ou non.
Lintrt dun tel journal se situe particulirement dans les phases doptimisation, pendant laudit du serveur ou encore lorsquon souhaite identifier un problme venant de
lapplication. Ce fichier peut grossir trs rapidement sur une machine qui subit une
forte charge. Par consquent, il peut, de par sa lourdeur, rapidement devenir inexploitable. En effet, rares sont les diteurs de texte qui permettent de manipuler avec aisance
des fichiers de plusieurs dizaines ou centaines de mgaoctets.
Un autre inconvnient, et non des moindres, vient du fait que lactivation du journal
gnral reprsente une charge de travail supplmentaire pour la machine, essentiellement au niveau des E/S. Cette surcharge dpend bien videmment de lapplication et
des caractristiques de la machine. Nanmoins celle-ci peut tre estime, lorsque la journalisation seffectue dans un fichier, environ 30 %. Il est donc fortement conseill de ne
lactiver que de faon ponctuelle, dans les phases daudit, doptimisation, de dbogage...
Une utilisation assez originale consiste placer des commentaires dans des requtes.
Les dveloppeurs connaissent les bienfaits des ces commentaires qui permettent de
documenter leur code. Un autre intrt est de sen servir pour tracer les requtes qui
deviennent ainsi plus faciles reprer dans la jungle de votre journal :
mysql> SELECT /*!99999 liste des villes de France */ name FROM City
WHERE countrycode ='fra';
shell> cat mysql.log
Time Id Command Argument
090908 21:18:31 1 Connect daz@localhost on world
1 Query show databases

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

154

MySQL 5 Audit et optimisation

1 Query show tables


1 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'

linstar du journal des requtes lentes, il est possible de stocker ces informations dans
une table systme (mysql.general_log) et le journal peut tre activ ou dsactiv
chaud respectivement grce aux commandes SET GLOBAL general_log = 'ON' et SET
GLOBAL general_log = 'OFF'. Le chemin et le nom du journal sont indiqus par la
variable general_log_file, sinon le nom par dfaut du fichier est
nom_de_la_machine.log et il est situ dans le rpertoire de donnes data. Il est galement possible, pour une session, de lactiver ou le dsactiver avec le paramtre
sql_log_off.
Cest le mme paramtre, utilis avec le journal des requtes lentes, log_output, qui
va permettre de choisir la destination du contenu du journal dans une table, un
fichier, dans une table et dans un fichier ou pas de journalisation (respectivement
'TABLE', 'FILE', 'FILE,TABLE' et 'NONE'). Le stockage de ces donnes dans la table
mysql.general_log, entrane une surcharge denviron 50 % pour le serveur.

Exemples dutilisations de la journalisation gnrale ?


Ce journal peut vous aider analyser plus finement le fonctionnement (ou les dysfonctionnements) de votre application. Certains lutilisent par exemple pour dfinir
la frquence des diffrents types de requtes de leur application, calculer des ratios
des requtes SELECT simples par rapport aux SELECT complexes (qui pourraient tre
simplifies), mais galement pour reprer les requtes les plus frquentes qui ncessitent donc un temps dexcution le plus court possible, ou enfin pour reconstituer
lhistorique dun serveur quelques instants avant un arrt brutal, etc.
Un autre intrt de la journalisation gnrale consiste rcuprer des requtes en vue de
gnrer un jeu de tests raliste ou pour juger de leur niveau doptimisation avec la commande EXPLAIN. Certains clients sensibles la scurit des donnes sen servent pour
tracer les utilisateurs, en dautres termes savoir qui a fait quoi et quand (cependant seul
lidentifiant id de la connexion se trouve dans le journal). De faon plus gnrale, vous
pourrez y suivre toutes les requtes et commandes non stockes dans les autres journaux.
Il existe un outil danalyse pour le journal gnral : mysqlsla (documentation et tlchargement ladresse : http://hackmysql.com/mysqlsla).

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Exploiter les journaux de MySQL


CHAPITRE 5

155

Voici une petite astuce pour changer le journal (tire de la documentation de MySQL) :
shell>
shell>
shell>
shell>

mv ma_machine.log ma_machine-old.log
mysqladmin flush-logs
cp ma_machine.log /sauvegarde/
rm ma_machine-old.log

La journalisation binaire
Les trois types de journaux tudis prcdemment ont comme point commun dtre
au format texte. Ce nest pas le cas du journal binaire qui, comme son nom lindique,
est au format binaire. Il a principalement deux buts : permettre le fonctionnement de
la rplication (cette partie est dtaille au chapitre 8) et remettre la base en tat aprs
un incident avec un niveau de restauration trs fin.
Il remplit ses diffrents rles en enregistrant toutes les requtes dcritures valides
qui arrivent sur le serveur MySQL. Notez que, contrairement au journal gnral, la
requte y est certes inscrite la fin de son excution, mais avant que les verrous ne
soient relchs. Ceci assure que lordre des requtes dans le journal binaire est bien
lordre dans lequel elles ont t valides. Les requtes de lectures comme SELECT,
SHOW ntant pas pertinentes pour une restauration des donnes ne sont donc pas
stockes. Une exception cependant : les requtes du genre CREATE TABLE SELECT
ou encore INSERT SELECT *, elles, sont stockes (sauf si le paramtre
binlog_format est fix ROW).
linstar des autres journaux, activer la journalisation binaire implique un surcot
pour le serveur. Autant tre clair, ce surcot denviron 1 % est ngligeable par rapport
aux avantages quapporte son activation. Il est possible dagir avec le paramtre
sync_binlog sur le nombre daccs disques causs par la journalisation binaire.
Lorsque ce paramtre vaut 0 (sa valeur par dfaut), MySQL ne synchronise pas le
cache du journal binaire avec son fichier. En dautres termes, il y a un gain de performance, car les accs disque sont minimiss ; en revanche, il y a plus de risques de
pertes de donnes en cas darrt brutal, puisque les dernires transactions valides
nauront sans doute pas eu le temps dtre crites sur le disque, et donc de devenir
persistantes. Sauf contraintes de performances particulires, nous vous conseillons de
choisir sync_binlog = 1.
REMARQUE Loption sync_binlog peut avoir un impact sur les performances
Si vous fixez sync_binlog =1, testez et surveillez le serveur aprs avoir rgl sa valeur. Il peut ne
plus tre en mesure de tenir de fortes charges.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

156

MySQL 5 Audit et optimisation

Lactivation du journal seffectue dans le fichier de configuration avec loption logIl nest cependant pas possible de lactiver chaud. En revanche, une fois que
vous lavez activ, vous avez la possibilit, mais seulement pour la session courante,
de le dsactiver sans redmarrer le serveur grce la variable sql_log_bin. Cela peut
tre utile, par exemple, pour excuter une requte de maintenance sur un serveur et
ne pas vouloir la journaliser.

bin.

mysql> SET SESSION sql_log_bin = 'OFF';


mysql> OPTIMIZE TABLE client;
mysql> SET SESSION sql_log_bin = 'ON';

Le journal binaire se reconnat facilement grce son extension qui est compose de
6 chiffres. Le tout premier journal cr se termine par .000001, le suivant par
.000002, puis .000003, et ainsi de suite. Cest un fichier dit incrmental : le serveur
ferme le fichier courant pour en ouvrir un autre. Ce changement de numros a lieu
lorsquune des 3 conditions suivantes survient :
1 si la commande FLUSH LOGS est execute ;
2 si la taille du fichier atteint la valeur de la variable max_binlog_size (taille maximale de 1 Go) ;
3 si le serveur MySQL redmarre.
La commande SHOW BINARY LOGS permet dobtenir la liste de tous les journaux
binaires du serveur. SHOW MASTER STATUS affiche un tableau avec le nom du journal
binaire courant ainsi que dautres informations utiles, notamment pour la rplication
(consultez le chapitre 8 traitant de la rplication). Il ny a pas de processus automatique, tel un garbage collector, pour supprimer les anciens fichiers. Vous disposez
cependant de deux mthodes pour y parvenir. Utilisez la commande PURGE BINARY
LOGS qui permet de purger des journaux binaires soit en se basant sur leurs numros
soit sur leur date de cration. Lautre mthode consiste employer le paramtre serveur expire_logs_days en lui fournissant un nombre de jours. Ce dernier peut tre
dfini dynamiquement.
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 */

La commande RESET MASTER est une autre commande utile, beaucoup plus radicale,
car elle permet de rinitialiser la journalisation binaire, cest--dire de supprimer tous
les fichiers et de repartir avec un journal en .000001.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Exploiter les journaux de MySQL


CHAPITRE 5

157

Visualiser le journal peut tre effectu avec la commande SHOW BINLOG EVENTS IN.
Lautre mthode est dutiliser mysqlbinlog. Cest galement loutil employ pour restaurer une base partir des journaux binaires ou pour effectuer du Point In Time
Recovery (PITR).
TRANCHE DE VIE La technique de Point In Time Recovery en pratique
Imaginez quun dveloppeur imprudent supprime, par mgarde, sur le serveur de
production, la table contenant les clients de votre application 12 heures. La dernire sauvegarde a t effectue 3 heures du matin et linformation de lincident
remonte aux oreilles de ladministrateur des bases de donnes 13 heures. La procdure classique, aprs avoir remont les bretelles du dveloppeur, est de restaurer la
dernire sauvegarde (en esprant quelle soit valide). Rsultat : plus de 10 heures de
transactions de perdues !
Grce aux journaux binaires, aprs avoir restaur la sauvegarde, vous pourrez remonter jusqu la requte prcdent lincident (la commande DROP TABLE de 12 heures),
en rejouant tout simplement les requtes du journal. Plus intressant encore, il est
tout autant possible de rejouer les requtes survenues aprs lincident, cest--dire de
12 13 heures. Il faut juste prendre soin de ne pas rejouer linstruction DROP TABLE.
Bien entendu, les requtes concernant la table des clients ayant chou aprs
12 heures ne sont pas dans le journal et ne sont donc pas restituables.

Les donnes du journal sont stockes de 3 faons diffrentes :


sous la forme de requtes (STATEMENT) ;
sous la forme de donnes gnres par les enregistrements (ROW) ;
sous un format qui mlange les deux formes prcdentes en fonction du contexte
et du type de requtes (MIXED).
Le choix est effectu laide du paramtre binlog_format et peut tre modifi dynamiquement pour la session comme pour tout le serveur. Le mode de journalisation
historique est STATEMENT. Il est prouv depuis les versions 3.23 de MySQL et est
donc naturellement le mode prfr des administrateurs de base de donnes. Cependant, il prsente linconvnient de ne pas permettre la journalisation des requtes
contenant des instructions non dterministes. Par exemple, excuter une requte
contenant la fonction uuid() gnre un avertissement (warning) de la part du serveur, car en cas de rplication ou de restauration en mode STATEMENT, MySQL
rejouera la requte et le rsultat sera fatalement diffrent. En revanche, cela naurait
pas pos de problme en mode ROW. Notez quen mode MIXED, MySQL passe automatiquement en ROW pour ce type de requtes.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

158

MySQL 5 Audit et optimisation

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)

Pour tre complet, le format STATEMENT a pour avantage dtre en gnral plus petit et
moins gourmand en espace disque et en transfert rseau que le format ROW. Comme
nous lavons vu, il est galement plus mature ; cest donc ce format de journalisation
que nous vous conseillons. Cependant, toutes les requtes ne peuvent pas tre rpliques et la structure des tables doit tre la mme.
Du format de journalisation choisi dpendent la lisibilit des vnements dans le
journal binaire et donc la facilit avec laquelle le PITR ou toute autre manipulation
du contenu du journal va pouvoir seffectuer. Examinez comment MySQL journalise
la requte dcriture suivante :
INSERT INTO `Ville` VALUES (2974,'Paris','FRA',2125246);

REMARQUE Taille du journal binaire en fonction du mode de journalisation


La taille des journaux binaires dpend galement du type de requtes et non simplement du format de
journalisation. Si lapplication mne beaucoup de requtes qui modifient peu de donnes, les fichiers en
mode ROW seront alors plus petits.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Exploiter les journaux de MySQL


CHAPITRE 5

159

Avec binlog_format='STATEMENT' :
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)
...

Avec binlog_format='ROW' :
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

Cependant, avec loption verbose de mysqlbinlog, la sortie, malgr le format ROW, est
un peu plus lisible :
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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

160

MySQL 5 Audit et optimisation

### @1=2974
### @2='Paris'
### @3='FRA'
### @4=2125246
# at 273
...

Tableau 51 Rcapitulatifs 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 rplication

Les requtes non dterministes ne


sont pas rpliques

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 lie la
rplication

Les versions partir de 4.1.3

Seulement les versions partir


de 5.1.5

Bonnes pratiques
Ce chapitre a prsent les principaux journaux serveur ainsi que leurs diffrentes utilisations. Cependant les activer nest pas anodin car ils peuvent avoir un impact non
ngligeable sur les performances du serveur MySQL. Une bonne faon de voir les
choses est de se demander, pour chacun dentre eux, si vous en avez lutilit. Pour
vous aider choisir, voici la configuration que nous vous recommandons :
Activer le journal binaire : il servira pour la restauration des donnes, PITR et
autres sauvegardes incrmentales ainsi que pour la rplication.
Activer le journal des requtes lentes, utile pour dmasquer les requtes candidates loptimisation. Prenez garde ne pas fixer une valeur long_query_time trop
petite sous peine daugmenter la charge de travail du serveur.
Ne pas activer le journal gnral, sauf dans les phases daudit ou doptimisation.
Cest le journal le plus coteux pour le serveur.
Un autre point trs important est de penser protger laccs vos fichiers. Ces derniers tant capables de stocker les requtes telles quelles, des informations sensibles
comme les mots de passe peuvent tre rcupres par des personnes mal intentionnes.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Exploiter les journaux de MySQL


CHAPITRE 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'

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

6
Optimiser sa base de donnes :
du schma aux requtes
Les performances de votre application auront un impact fort sur la qualit de service
et sur la satisfaction des utilisateurs. tre plus rapide, offrir de meilleurs services ou
tout simplement tre moins cher sont des critres qui peuvent vous permettre de
garder une longueur davance sur vos concurrents. Dans beaucoup de secteurs dactivits, cest le client qui dcide in fine de la prennit du service. Par consquent, vous
vous devez de le choyer car un client mcontent est difficile reconqurir. Vous
devez alors tre en mesure danticiper, didentifier et de rgler tout problme sur la
base de donnes. Vous devez galement tre capable de la paramtrer finement afin
doptimiser ses performances parce quelle est un lment crucial, quil faut comprendre et dompter ds sa conception. Enfin, il vous faut laccompagner pour laider
grandir travers lvolution de votre application.

Conception de la base de donnes


Un immeuble avec de piteuses fondations sera plus vulnrable aux intempries ou
lpreuve du temps. Ce principe vident peut tre transpos la base de donnes. En
effet une conception bcle, souvent ralise dans un souci de gain de temps, ou tout
simplement pour cause dincomptences risque de vous emmener dans des chemins
sinueux qui dbouchent trs souvent vers une impasse technique ou financire. Une
conception mal pense peut engendrer une multitude de problmes allant de requtes

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

164

MySQL 5 Audit et optimisation

difficilement optimisables au manque dvolutivit du schma en passant par les problmatiques de cohrence des donnes.
Il ny a pas de schmas idaux ; en revanche, il est trs facile den crer un mauvais.
Les causes peuvent alors tre multiples.
Les tables sont cres au fur et mesure des besoins, sans vision densemble.
Lutilisation dun framework, bien quutile au dveloppement pour conomiser du
temps et de largent, peut crer un schma gnrique peu ou pas adapt aux
besoins de performances du systme.
Le cahier des charges a volu et lapplication est utilise dune faon diffrente
de celle prvue lors de lexpression des besoins.
Les prvisions de charges et de volumtries ont t msestimes et il y a plus de
trafic ou de donnes que prvu...

Normalisation/dnormalisation
Le salut est dans la modlisation et la normalisation. Ces deux points pourraient faire
lobjet dun ouvrage part entire mais nous ne les aborderons que dans les grandes
lignes.
Modliser est un processus qui permet de structurer et dorganiser les donnes. Ses
objectifs sont de maintenir lintgrit rfrentielle, de sassurer que les donnes restent faciles maintenir et ne sont pas redondantes. Pour modliser, il faut commencer par crer un modle conceptuel de donnes (MCD) en dessinant les entits
et leurs relations. Ce diagramme est une carte qui reprsente le mtier et savre trs
utile pour changer avec les autres acteurs du projet. Le MCD conduit ensuite
crer le modle logique de donnes (MLD). Ce modle reprsente le plan, la cartographie des donnes. Enfin, la construction du modle physique de donnes (MPD)
consiste transformer le modle logique pour ladapter au SGBDR cible.
BON SAVOIR La normalisation
La normalisation a t cre par Edgar Frank Codd, dans les annes 1970. Elle est base sur le principe
mathmatique de la thorie des ensembles. Son but est notamment dliminer tout doublon au niveau
des donnes et dassurer leur intgrit. Il y a huit degrs de normalisation, appels formes normales,
mais respecter les trois premires formes suffit pour tre normalis (3FN ou 3NF en anglais). Cette tape
est trs importante pour garantir la robustesse de la base de donnes. tre normalis permet doptimiser
les jointures qui comptent parmi les oprations les plus coteuses, en minimisant le nombre de donnes
traites. Avec un schma normalis, la slection du plan dexcution optimal, par loptimiseur, est
facilite : il y a moins de donnes analyser et les requtes de mises jour nont quune occurrence
traiter au lieu de plusieurs.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

165

Il ny a cependant pas que des avantages : un schma normalis contient souvent


beaucoup de tables et une information est souvent rpartie sur plusieurs dentre elles,
ce qui peut avoir un impact non ngligeable sur les performances. Cest la raison pour
laquelle, une fois la phase de normalisation termine, il est parfois ncessaire de
dnormaliser une partie du schma pour esprer de meilleures performances. Un
vieux matre DBA a dit un jour : Normalisez jusqu ce que cela fasse mal, dnormalisez jusqu ce que cela marche ! .
OUTILS Logiciels de modlisation
Un bon nombre doutils existe pour vous aider concevoir les diffrents modles :
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/

En dnormalisant, le but recherch est donc la performance. Une des techniques les
plus utilises est dajouter de la redondance. Pour cela, il existe plusieurs mthodes,
exposes ci-aprs.

Ajouter des colonnes dans une table


Ajouter une cl primaire fonctionnelle (client_id) avec une taille dun cot

moindre que celle de la cl primaire candidate (code). Cela peut permettre de


minimiser les I/O (vous trouverez davantage de dtails dans quelques paragraphes). Notez, dans lexemple qui suit, lajout de la contrainte dunicit sur le
champ code pour assurer lintgrit des donnes.
Table originale
mysql> CREATE TABLE client (
code char(255) NOT NULL,
nom char(50) NOT NULL,
PRIMARY KEY (code));

Table dnormalise
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));

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

166

MySQL 5 Audit et optimisation

Ajouter une colonne calcule TTC, en plus de la colonne HT, qui contient le

rsultat de HT + TVA.
Table originale
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));

Table dnormalise
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));

Ajouter une colonne de type ENUM en remplacement dune colonne cl trangre.


Table originale
mysql> CREATE TABLE pays (
code char(3) NOT NULL,
nom char(60) NOT NULL,
continent_id tinyint unsigned NOT NULL,
PRIMARY KEY (code));

Table dnormalise
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));

Cration de tables dagrgation


La cration de tables dagrgation (data snapshot ou resume tables), cest--dire
de tables qui contiennent les rsultats dune (ou plusieurs) requte sur dautres tables,
permet dconomiser le temps de calcul du rsultat.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

167

Cration de schmas orients


Il sagit de crer des schmas orients OLAP (Online Analytical Processing), entrepts
de donnes comme le schma en toile ou le flocon de neige.
Le rapport normalisation/dnormalisation va galement dpendre du type dapplication, oriente OLTP ou OLAP (entrepts de donnes).
Tableau 61 OLTP vs OLAP

OLTP

OLAP

Normalis

Oui, avec une structure complexe (3NF)

Peu ou pas, avec une structure multidimension

Index

Peu

Beaucoup

Jointures

Beaucoup

Quelques unes

Doublons

Non (ou peu)

Oui

Tables dagrgation

Rare

Commun

Des types de donnes ajusts


Un autre point prendre en compte est le type des donnes. MySQL propose une
large panoplie de types pour stocker les nombres (tinyint, integer, bigint...),
chanes de caractres (char, varchar, text), nombres rels (float, double), etc.
Lintrt de ce large choix est de pouvoir optimiser le stockage des donnes. Les critres sont fonction de la plage de valeurs des donnes stocker et de lespace occup
par chaque type.
Voici nos recommandations particulires.
Placez systmatiquement NOT NULL pour toutes les colonnes qui ne stockent pas
de valeurs NULL.
Ces dernires induisent des traitements supplmentaires et compliquent la tche
de loptimiseur. En indiquant que la colonne ne contiendra pas de valeurs NULL,
vous affranchissez le serveur de ce surcot. NULL doit donc tre un choix !
Utilisez le type adquat.
Ne stockez pas vos entiers en tant que chanes de caractres ('1' la place de 1),
la conversion a un cot.
Utilisez la bonne taille de type.
Pour stocker lge dune personne, TINYINT UNSIGNED suffit et est quatre fois
moins coteux que INT (http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html).
Nutilisez pas CHAR(255) si CHAR(50) suffit. Au-del du gain de place vident, des
donnes plus petites prendront moins de place en mmoire (buffers, caches, tables

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

168

MySQL 5 Audit et optimisation

temporaires) et le serveur pourra en stocker davantage, ce qui a pour consquence


de minimiser les I/O.
Les types de donnes des cls trangres doivent tre identiques ceux des cls
primaires.
Cette rgle doit tre tendue aux champs des critres de jointures. La jointure
fonctionnera mais MySQL sera alors oblig de convertir lun des deux champs
dans le type de lautre.
Attention aux jeux de caractres.
Une table MyISAM statique (fixed) en utf-8 occupera environ trois fois plus
despace que la mme table en latin-1. En dynamique les tailles seront quivalentes.
Il existe une commande pour vous aider choisir le type optimal : il sagit de
PROCEDURE ANALYSE. Cette procdure qui sutilise avec une requte SELECT va analyser
le contenu dune table pour chacune des colonnes choisie, et afficher un rapport contenant des statistiques ainsi que le type optimal suggr. Dans lexemple qui suit, la procdure analyse les colonnes customer_id, first_name et email de la table customer.
Gardez lesprit que le type optimal propos nest quune suggestion un instant
donn : vous devez vous demander sil est applicable dans votre contexte. Par
exemple, la procdure propose pour la colonne first_name, une liste numre de
toutes les valeurs prsentes au moment de lanalyse (ENUM('AARON','ADAM',...) )
comme type optimal. Dans ce cas de figure, cela na pas de sens car la liste des clients
est amene voluer. Le type varchar est donc bien mieux adapt.
MTHODE Un type optimal un moment donn
Gardez lesprit que le type optimal propos nest quune suggestion un instant donn : vous devez
vous demander sil est applicable dans votre contexte. Par exemple, la procdure propose pour la
colonne first_name, une liste numre de toutes les valeurs prsentes au moment de lanalyse
(ENUM('AARON','ADAM',...) ) comme type optimal. Dans ce cas de figure, cela na pas de sens
car la liste des clients est amene voluer. Le type varchar est donc bien mieux adapt.

Affichage des rsultats de la commande PROCEDURE ANALYSE()


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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

169

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: AARON.SELBY@sakilacustomer.org
Max_value: ZACHARY.HITE@sakilacustomer.org
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

Les jointures
Avant daller plus loin, un rappel sur les jointures nous parat opportun.
Une base de donnes relationnelle permet dorganiser et de stocker des donnes sous
la forme de tables lies entre elles par des relations. Dans de nombreux cas, une
information est rpartie sur plusieurs tables et pour la rcuprer en une seule requte,
il faut effectuer une jointure. La jointure est une opration qui consiste a combiner
(joindre) les enregistrements de deux tables pour en crer une nouvelle et la joindre
une autre, ainsi de suite jusqu la dernire, puis lafficher.
Prenons comme exemple les deux tables
suivante :
membres:
| Pascal
| Arnaud
| Olivier
| Xavier
| Muriel

|
1
|
2
|
2
|
3
| NULL

membres

et

profession

avec la structure

|
|
|
|
|

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

170

MySQL 5 Audit et optimisation

profession;
| 1 | architecte
| 2 | dba
| 3 | cto
| 4 | dveloppeur

|
|
|
|

Avec linstruction INNER


jointure sont retourns.

JOIN

seuls les enregistrements qui satisfont la condition de

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
|
+---------+-------------+

Les syntaxes quivalentes sont :


SELECT m.nom, p.description FROM membre AS m

Le critre de jointure (id) ayant le mme nom, la clause USING peut tre utilise ;
SELECT m.nom, p.description FROM membre AS m, profession AS p WHERE p.id
= m.id;

Cette variante est plus utilise, mais elle est moins claire.
Lopration LEFT OUTER JOIN renvoie les enregistrements qui satisfont la condition
de jointure ainsi que tous les enregistrements de la premire table ( gauche, do le
mot LEFT).
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
|

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

171

fonctionne suivant le mme principe que LEFT, la diffrence que


ce sont tous les enregistrements de la table de droite qui sont renvoys. Rarement utilis, on lui prfre LEFT car il suffit dinverser lordre des tables.

RIGHT OUTER JOIN

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
|
+---------+-------------+

Le produit cartsien est un type de jointure qui peut tre trs coteux, car avec deux
tables qui contiennent respectivement n et m enregistrements, la requte renvoie
n m lignes.
mysql> SELECT m.nom, p.description FROM membre AS m, profession AS p;
+---------+--------------+
| nom
| description |
+---------+--------------+
| Pascal | architecte
|
| Pascal | dba
|
| Pascal | cto
|
| Pascal | dveloppeur |
| Arnaud | architecte
|
| Arnaud | dba
|
| Arnaud | cto
|
| Arnaud | dveloppeur |
| Olivier | architecte
|
| Olivier | dba
|
| Olivier | cto
|
| Olivier | dveloppeur |
| Xavier | architecte
|
| Xavier | dba
|
| Xavier | cto
|
| Xavier | dveloppeur |
| Muriel | architecte
|
| Muriel | dba
|
| Muriel | cto
|
| Muriel | dveloppeur |
+---------+--------------+

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

172

MySQL 5 Audit et optimisation

MySQL supporte galement les oprateurs suivants :


CROSS JOIN : pour MySQL, CROSS JOIN et INNER JOIN sont identiques, ce qui
diffre de la norme SQL ANSI ;
STRAIGHT_JOIN : est similaire INNER JOIN. La seule diffrence est que la table
gauche sera toujours lue avant celle de droite. Cela permet de forcer loptimiseur
dans le cas o il ne choisirait pas le plan dexcution optimal.
Il existe trois algorithmes pour effectuer des jointures, nested loops, merge join et hash
join. Pour grer les jointures, MySQL nimplmente que le premier.
Lalgorithme de boucles imbriques (Nested loops) est le plus simple des algorithmes de
jointure. Pour chaque enregistrement, MySQL analyse tous les lments dfinis par le
critre de jointure et ne garde que les enregistrements qui correspondent. videmment,
cet algorithme est trs peu performant sil doit traiter un grand nombre de valeurs. Pour
lamliorer, il faut absolument disposer dun index sur le critre de jointure.
Voici lalgorithme :
Pour tous les lments (e1) de T1 faire :
Pour tous les lments (e2) de T2 faire :
si e1 et e2 satisfont la condition de jointure alors garder
lensemble e1,e2.

Les autres types sont :


Merge join (Sort-Merge Join) : les relations sont tries en fonction des attributs
utiliss par la jointure. Il faut ensuite rcuprer seulement ceux qui satisfont la
condition.
Hash join : consiste crer une table de hachage (hash table) partir des attributs de
jointure et y rcuprer tous les lments voulus ; il est en effet plus performant de
raliser cette opration avec un index hash quavec un B-tree (voir plus loin).

Les index
Lorsquil reoit une requte, loptimiseur doit trouver la mthode la plus performante
pour lexcuter. Dans le cas dune requte de lecture, pour pouvoir slectionner et
renvoyer le rsultat, il choisit entre utiliser lindex, sil existe et sil est pertinent, ou
parcourir tous les enregistrements de la table, cest--dire faire un full table scan. En
rgle gnrale, utiliser lindex se rvle plus performant que le parcours complet de la
table car moins de donnes sont analyses et les I/O sont minimiss. Limpact ne sera
pas forcment le mme pour les requtes dcriture, car il faut mettre jour les donnes et lindex.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

173

Index B-tree
Les algorithmes de gnration dindex dans MySQL sont implments par les
moteurs de stockage et pour la plupart drivs du B-tree qui est une structure contenant les donnes tries sous la forme dun arbre binaire quilibr (balanced). Lintrt
de cet algorithme est quil est optimis pour minimiser les accs disque.
Figure 61

Arbre binaire quilibr (B-tree).

Pour fixer les ides, si une table compte 10 millions dentres, un full table scan les
analysera toutes ; alors quavec un arbre binaire le nombre denregistrements analyss
(N) sera de lordre de 23 (O(log2N)) grce une recherche dichotomique. Cest
donc un gain non ngligeable par rapport une recherche linaire. La recherche
linaire sera parfois utilise par loptimiseur sur des petites tables. Pour des tables
plus importantes, la recherche dichotomique est souvent plus intressante.
B.A.-BA
La recherche dichotomique est une technique algorithmique utilisable uniquement avec des structures de
donnes ordonnes.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

174

MySQL 5 Audit et optimisation

Derrire ces chiffres thoriques, dautres facteurs entrent en compte, notamment lis
aux disques. Dans certains cas, rechercher les donnes par lindex peut tre plus coteux quune lecture squentielle.
Pour illustrer ce point, imaginez que le technicien de la compagnie dlectricit doive
passer chez tous les habitants dun immeuble pour rcuprer le relev du compteur.
Sil dcide de sacquitter de sa tche en commenant par tous les habitants du rez-dechausse, puis tous les habitants du premier tage et ainsi de suite jusquau dernier
tage, il sera plus performant que sil procde par ordre alphabtique. Ce qui pourrait
donner dans ce dernier cas : monter chez Borghino au huitime tage, puis descendre
au premier pour aller chez Dasini, monter nouveau, mais au neuvime cette fois,
pour aller chez Gadal...
Un autre inconvnient concerne les requtes dcritures qui risquent dtre ralenties :
en plus de devoir crire la donne, il faut galement crire dans lindex au bon
endroit, car rappelez-vous quil est tri.
En fonction de lapplication, vous pouvez donc tre amen optimiser les performances des requtes de lectures (cest en gnral le cas car beaucoup dapplications en
effectuent une majorit) mais cest parfois le cas inverse ; pensez alors aux inconvnients des index.
Lalgorithme B-tree est implment par le moteur de stockage MyISAM. Cest le
fichier qui a pour extension .MYI qui contient tous les index de chacune des tables. Les
index y sont stocks et tris comme expos prcdemment et, dans les feuilles de
larbre, un pointeur permet daccder aux donnes qui correspondent la valeur du
champ index (.MYD). Le principe est le mme pour tout les index, excepts les index
fulltext.
BON SAVOIR Index Fulltext (Plaintext)
Fulltext est un type dindex utile pour rechercher des mots dans de gros volumes de textes. Il ne fonctionne que sur les tables MyISAM et ne peut tre cr que sur des colonnes de types texte (char,
varchar, et text).
Son utilisation est diffrente des autres index : la recherche est effectue avec la fonction MATCH() qui
permet de slectionner la colonne dans laquelle le mot est cherch et la fonction AGAINST() qui elle
permet de spcifier les mots recherchs. Les enregistrements retourns sont automatiquement tris par
une notion de pertinence.
Nhsitez pas consulter la documentation pour plus dinformations :
B http://dev.mysql.com/doc/refman/5.1/en/fulltext-natural-language.html
Une alternative est le projet libre Sphinx, bas entre autres sur Lucene :
B http://www.sphinxsearch.com/

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

175

Figure 62

B-tree du moteur MyISAM

Index B+tree
InnoDB implmente une variante du B-tree, appele B+tree. Cet algorithme est spcialis dans le stockage de volumes de donnes trop importants pour tenir entirement en mmoire. En gnral les feuilles sont stockes sur le disque alors que les
autres nuds restent en mmoire. De plus, contrairement B-tree les enregistrements sont stocks dans les feuilles, les autres nuds ne contiennent que les index.
Figure 63

Index B+tree

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

176

MySQL 5 Audit et optimisation

Lautre diffrence majeure avec MyISAM est la notion dindex en grappe (clustered
index). La cl primaire sert construire larbre B+tree sauf que dans les feuilles on
trouve, non pas un pointeur vers les donnes comme avec MyISAM, mais les enregistrements qui correspondent la valeur de la cl primaire. InnoDB a donc besoin
dune cl primaire pour fonctionner. Sil nen trouve pas dans la structure de la table,
il en cre une en interne sous la forme dun entier de 6 octets.
Pour les index secondaires (autre que la cl primaire), le principe est presque le
mme. Ils sont reprsents galement par un B+tree, sauf que dans les feuilles on ne
retrouve pas les enregistrements, mais la valeur de la cl primaire correspondante.
Une seconde recherche, sur la cl primaire, est donc ncessaire.
Cela a deux incidences immdiates :
les enregistrements des tables InnoDB sont tris par rapport la cl primaire. Si
par exemple vous voulez insrer un gros volume de donnes, 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 dernire doit
tre la plus petite possible, car une mauvaise cl primaire sur une table InnoDB
aura un impact ngatif sur la taille des index secondaires et sur toutes les recherches indexes de cette table.
Figure 64

Index en grappe dInnoDB

InnoDB implmente galement lalgorithme hash adaptative, qui permet de gnrer


automatiquement une table de hachage en interne, lorsque le moteur dtecte que des
valeurs dindex sont accdes frquemment. Ce mcanisme est gr par le moteur et
vous naurez donc pas la main dessus, contrairement au moteur de stockage Memory,
qui utilise lui aussi un algorithme de hachage. Cest son algorithme par dfaut : tout
index cr sur une table Memory sera donc une table de hachage, sauf si vous spcifiez le contraire.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

177

BON SAVOIR La table de hachage


On peut se reprsenter une table de hachage par un tableau associatif non ordonn qui permet une association cl/donne. Laccs une donne a lieu en transformant la cl en hash, grce une fonction de
hachage.

Index hash
Cet algorithme prsente la particularit dtre performant pour les recherches dgalits avec les signes = ou <=>. En revanche, il ne fonctionne pas pour les recherches
par intervalles ou pour les ingalits (BETWEEN, <, >=...) parce que les donnes ne sont
pas tries dans la table de hachage. Pour les mmes raisons, loptimiseur ne pourra
pas sen servir pour optimiser la clause ORDER BY. Un autre de ses inconvnients est
quil nest pas trs efficace sil y a beaucoup de doublons.
Figure 65

Index hash de Memory

Depuis MySQL 4.1, il est possible de contourner ces limitations, en mettant un


index B-tree. Pour chaque index de la table, vous avez donc la possibilit de choisir
entre un hash et un B-tree. Si la table ne reoit que des requtes dgalits, optez
pour un index hash sur les colonnes ayant un index unique (primary key et unique
index). En prsence de requtes dingalits ou de beaucoup de doublons, optez pour
un index B-tree. Et rien ne vous empche, pour une mme colonne, de placer un
index hash et un index B-tree si ncessaire (surindexation).
Attention, la surindexation est en gnral viter : elle augmente en effet la taille de
lindex et ajoute un surcot au processus de mise jour des index.
Dans lexemple qui suit, les tables t_myisam et t_memory nont quune seule
diffrence : leur moteur de stockage (respectivement MyISAM et Memory). La
commande EXPLAIN est utilise pour comparer les diffrents plans dexcution.
EXPLAIN est expose plus en dtails un peu plus loin dans ce chapitre.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

178

MySQL 5 Audit et optimisation

La cl primaire de t_myisam est en B-tree alors que celle de t_memory est en hash :
mysql> SHOW INDEX FROM t_myisam \G
*************************** 1. row ***************************
Table: t_myisam
Key_name: PRIMARY
Column_name: ID
Cardinality: 4079
Index_type: B-tree
...
mysql> SHOW INDEX FROM t_memory \G
*************************** 1. row ***************************
Table: t_memory
Key_name: PRIMARY
Column_name: ID
Cardinality: 4079
Index_type: HASH
...

Une recherche sur la cl primaire permet dutiliser lindex sur t_myisam.


t_memory

se comporte de faon identique :

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:

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

179

Une recherche dingalit utilise la cl primaire sur t_myisam mais pas sur t_memory
du fait de lalgorithme hash :
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

Ajout dun index B-tree sur la colonne id (la cl primaire) de la table t_memory
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: ID
Cardinality: 4079
Index_type: HASH
*************************** 2. row ***************************
Table: t_memory
Key_name: idx_btree_id
Column_name: ID
Cardinality: NULL
Index_type: B-tree

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

180

MySQL 5 Audit et optimisation

Malgr lajout de lindex B-tree, lindex hash (PRIMARY) continue dtre utilis pour la
recherche dgalit. En revanche, lindex B-tree (idx_btree_id) est employ pour la
recherche 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 62 Les types dalgorithmes de gnration dindex des moteurs de stockage

MyISAM
B-tree

InnoDB

Oui

Memory
la demande

B+tree

Oui

Hash

Automatique

Oui

ALTERNATIVE
Notez que MyISAM implmente galement dautres types dalgorithmes comme Rtree pour les index
gomtriques (GIS) ou Fulltext pour la recherche de mots dans du texte.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

181

Optimisation des requtes


Avec le schma, lautre point cl dune base de donnes performante et volutive est
le code SQL. Moins coteux modifier que le schma, loptimisation des requtes
diminuera les temps de traitements, permettra dabsorber une charge plus importante, et vous fera raliser des conomies sur le matriel tout en diminuant le risque
que la base de donnes soit le goulet dtranglement de votre application.

Connatre loptimiseur pour mieux le comprendre


B.A.-BA La slectivit
Avec MySQL, la pertinence dindexer une colonne va dpendre de sa proportion plus ou moins grande
denregistrements identiques (doublons) savoir sa slectivit ou cardinalit (cardinality). Plus elle sera
grande, plus il sera intressant de mettre un index. La formule est :
Slectivit = Nombre denregistrements/Nombre denregistrements distincts.

Le meilleur rsultat pour un index est une slectivit de 1 (100 % de valeurs distinctes), ce qui signifie
que tous les lments sont diffrents. Cest 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/

Lorsquune requte SQL arrive sur le serveur, aprs les diffrentes tapes de vrification des droits, elle est analyse syntaxiquement (vrifier que les colonnes et les tables
existent), puis transforme en un format binaire et rcrite dans le but de produire un
arbre danalyse (parse tree). Ensuite, loptimiseur va, laide de cet arbre, chercher le
plan dexcution optimal pour lenvoyer au moteur dexcution de requtes du
moteur de stockage.
Pour calculer le plan dexcution, loptimiseur se base sur plusieurs facteurs : le
nombre denregistrements des tables, le nombre dlments dans les index, la slectivit des index et les colonnes utilises.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

182

MySQL 5 Audit et optimisation

BON SAVOIR Optimiseurs base de rgles ou de cot (cost based ou rules based)
Dans lunivers de la base de donnes il existe des optimiseurs bass sur le cot (cost based) ou bass sur
des rgles (rules based). MySQL utilise la premire mthode : il calcule le cot daccs aux donnes en se
basant sur le cot des I/O, des cycles processeurs, les cots lis aux statistiques de la base de donnes
(nombre denregistrements, distribution des donnes, plages de valeurs...) et les cots danalyse de la
requte. Son principal avantage est de lui permettre de calculer le plan dexcution optimal en fonction
de la distribution et de la volumtrie des donnes.
Le calcul du cot comprend notamment le cot dun accs disque et son unit est la lecture alatoire
dune page de 4 Ko. Les paramtres pris en compte dans ce calcul sont :
les statistiques sur les donnes ;
- le nombre de pages par tables/index ;
- la slectivit des tables/index ;
- la taille des enregistrements et des index ;
- la distribution des index ;
le schma ;
- lunicit de certains champs (cls primaires) ;
- les champs NULL.
De leur ct, les optimiseurs utilisent des rgles syntaxiques pour valuer les diffrents plans.

La commande EXPLAIN pour analyser lexcution des requtes


Dans un monde idal, toutes les requtes devraient tre optimales. Les tables ne
devraient comporter que des index utiliss, les requtes utiliseraient les bons index
quand cela est ncessaire, elles ne renverraient que les donnes dont on a besoin
(colonnes et enregistrements) et le tout avec un temps dexcution satisfaisant ! Malheureusement cela nest pas toujours le cas. Il est cependant possible de sen approcher en analysant le plan dexcution des requtes avec la commande EXPLAIN.
Celle-ci ne fonctionne quavec des requtes de type SELECT et permet de savoir dans
quel ordre les tables sont traites, de quelles manires les donnes sont rcupres et
davoir une estimation du nombre denregistrements retourns. Elle nest pas aussi
complte que les commandes quivalentes sur dautres SGBD car elle na pas le
mme niveau de dtail. Cependant, les informations fournies donnent une ide assez
prcise du plan dexcution choisi par loptimiseur.
On y remarque les manques suivants :
aucune information nest disponible sur les dclencheurs (triggers), les procdures
stockes, les fonctions utilisateurs (UDF) ;
les rsultats peuvent tre imprcis si les statistiques ne sont pas jour (ANALYZE
TABLE met jour les statistiques) ;
on ne peut pas savoir si un tri est effectu en mmoire ou sur disque (disponible
avec SHOW SESSION STATUS LIKE 'Created_tmp%';) ;

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

183

la notion de cot napparat pas (disponible avec SHOW SESSION STATUS LIKE
'Last_query_cost';).

PRATIQUE Visualiser le plan dexcution dun DELETE ou dun UPDATE


Impossible par dfaut (EXPLAIN naccepte que les commandes SELECT), visualiser le plan dexcution
des DML UPDATE ou DELETE ncessite une petite ruse. Lastuce consiste remplacer les commandes
DELETE ou UPDATE par une clause SELECT. Une petite rcriture de la requte est prvoir mais le
jeu en vaut la chandelle. Par exemple, le plan dexcution de la requte :
DELETE FROM ma_table WHERE id=972

peut tre visualis avec :


EXPLAIN SELECT * FROM ma_table WHERE id=972;

EXPLAIN se place juste avant le mot-cl SELECT et produit un tableau avec les colonnes
suivantes :
id : nombre entier qui permet didentifier la ou les requtes SELECT ;
select_type : nature du SELECT (simple, union, sous-requte, table drive...) ;
table : nom de la table utilise par le plan dexcution ;
type : stratgie daccs aux donnes choisie par loptimiseur. Cette partie est
dtaille plus loin ;
possible_keys : liste des index choisis par loptimiseur lors de lvaluation des
diffrents plans dexcution ;
Key : nom de lindex choisi par loptimiseur. En cas de problmes de performance,
si ce champ vaut NULL, vrifiez que la table est correctement indexe. Si cest le
cas, essayez de rcrire la requte ;
key_len : taille en octets de lindex choisi. Il est prfrable quelle soit petite ;
ref : colonne ou constante choisie par lindex pour accder aux donnes de la
table ;
rows : estimation du nombre de lignes que doit analyser loptimiseur. La prcision
de ce nombre dpend de la fracheur des statistiques (mises jour avec la commande ANALYZE TABLE) ;
Extra : informations complmentaires pouvant tre utiles pour la comprhension
du plan dexcution choisi par loptimiseur (voir page suivante).

Voici la liste des diffrentes valeurs que peut prendre la colonne type, classes du
moins performant au plus performant :
ALL : tous les enregistrements de la table sont parcourus (full table scan). En rgle
gnrale, il faut viter dutiliser ce type daccs. Cependant, si la table est petite, si
lindex nest pas assez slectif, si il ny a pas de clauses ON ou WHERE ou si la majeure

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

184

MySQL 5 Audit et optimisation

partie des enregistrements de la table doit tre lue, loptimiseur peut choisir
deffectuer un full table scan malgr la prsence dindex.
INDEX : quivalent ALL mais pour les index (full index scan). En gnral, meilleur
que le type prcdent car lindex est souvent plus petit que les donnes.
RANGE : lindex est parcouru sur un intervalle de valeurs (limited index scan). Ce
plan daccs est choisi quand des oprateurs tels que BETWEEN, >, <=... sont utiliss
dans la clause WHERE de la requte. On peut le retrouver galement avec des oprateurs de conditions multiples comme IN ou LIKE.
UNIQUE_SUBQUERY et INDEX_SUBQUERY : concernent les sous-requtes lorsquelles
retournent des valeurs uniques ou non.
INDEX_MERGE : le rsultat de plusieurs index est utilis pour former un unique
ensemble de donnes. Jusqu la version MySQL 5, lorsque loptimiseur avait le
choix entre plusieurs index pour une requte, il ne pouvait en choisir quun seul.
Une astuce consiste simuler lindex merge en dcomposant la requte en plusieurs requtes et en les unissant avec la clause UNION ALL :

SELECT count(*) FROM table WHERE nom = 'Jean' UNION ALL SELECT count(*)
FROM table WHERE taille > 170;

REF_OR_NULL : un index non unique et acceptant les valeurs NULL est utilis pour la

recherche sur plusieurs enregistrements.


REF : un index non unique est utilis pour la recherche (index lookup) sur plusieurs

enregistrements.
EQ_REF : la cl primaire ou un index unique est utilis.
CONST : loptimiseur sait quau plus un enregistrement de la table sera lu. Cest le

cas lorsquil sagit dune cl primaire, dun index unique ou lorsque la table na
quun seul enregistrement.
SYSTEM : la table ne contient quun seul enregistrement et en mmoire.
Les informations donnes par la colonne Extra peuvent indiquer un besoin damlioration de la requte. Voici les trois indications qui doivent retenir particulirement
votre attention :
Using join buffer : le join buffer est un tampon (buffer) spcial utilis pour amliorer le temps dexcution des jointures nemployant pas dindex. En dautres termes, il sagit dun produit cartsien, cest--dire de la multiplication de tous les
enregistrements de la premire table par ceux de la seconde. Si cette indication
apparat, placez un index sur les critres de jointure.
Using filesort : indique que les donnes sont tries par MySQL durant lexcution de la requte.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

185

REMARQUE Attention la fonction RAND()


La requte suivante permet dobtenir un enregistrement choisi au hasard dune table :
SELECT * FROM City ORDER BY rand() LIMIT 1.

Cest une trs mauvaise faon de procder, car comme vous pouvez le constater, elle est trs coteuse
(Extra : Using temporary; Using filesort).

Using temporary : indique quune table temporaire doit tre cre par MySQL

pour stocker un rsultat durant lexcution de la requte. Cette information apparat


souvent lorsque les clauses ORDER BY ou GROUP BY sont prsentes. En revanche, la
commande nindique pas si la table est cre sur disque ou en mmoire. Pour obtenir cette information, excutez la requte (sans la commande EXPLAIN) puis lancez
juste aprs la commande SHOW SESSION STATUS LIKE 'Created_tmp%';.
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 zro */
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
|
+-------------------------+-------+

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

186

MySQL 5 Audit et optimisation

OUTILS Reprsentation graphique du plan dexcution avec Maatkit


Maatkit propose un script Perl pour obtenir une reprsentation graphique des requtes EXPLAIN.
B http://www.maatkit.org/

Voici quelques conseils au cas o le rsultat dune commande EXPLAIN sur une
requte problmatique ne serait pas satisfaisant :
ajouter un index pertinent et tester nouveau ;
rcrire la requte ;
scinder la requte en plusieurs requtes plus simples ;
ajouter des filtres dans la clause WHERE pour diminuer le nombre de lignes
traiter ;
forcer loptimiseur modifier lordre des tables ;
contraindre loptimiseur utiliser un index prcis ou lempcher dutiliser lindex
quil a choisi ;
stocker le rsultat dans une table (temporaire), pour ne pas lexcuter chaque
fois ;
excuter le traitement hors de la base de donnes.
chaque nouvelle version majeure de MySQL, loptimiseur est amlior. En rgle
gnrale ses choix sont plutt bons. Toutefois, vous avez la possibilit dinfluencer
loptimiseur en lui ordonnant dutiliser ou non tel ou tel index :
USE INDEX : emploie lindex pass en argument. MySQL ne lutilisera pas si le
cot de lindex est plus important que celui dun full table scan ou sil est dans
limpossibilit de le faire ;
FORCE INDEX : utilise lindex pass en argument. MySQL exploitera alors lindex
sauf si cela lui est impossible ;
IGNORE INDEX : nutilise pas lindex pass en argument.
Il est galement possible, dans le cas de jointures internes, de fixer lordre des tables
(STRAIGHT_JOIN). Cependant, comme expos prcdemment, le plan dexcution
dpend notamment du nombre denregistrements ; il peut donc voluer. La vrit du
jour nest pas forcment celle de demain. Nous vous le dconseillons sauf si vous tes
sr de vous...

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

187

BON SAVOIR Optimisation des index et rorganisation des tables avec ANALYSE TABLE et
OPTIMIZE TABLE
Pour maximiser les chances dobtenir un plan dexcution optimal, les statistiques des tables doivent tre
jour : cest le rle de la commande ANALYZE TABLE.
Vous devez savoir quun verrou en lecture dune dure quivalente un full table scan, est plac sur les
tables MyISAM durant lopration. Cependant, comme MyISAM maintient automatiquement les statistiques sur le nombre denregistrements que contient la table, chaque requte INSERT et DELETE, il
nest pas ncessaire dexcuter souvent cette commande.
Le fonctionnement dInnoDB est quelque peu diffrent. Avec ce moteur, les statistiques sont mises jour
chaque fois quun seizime des donnes a chang. Par exemple, si une table contient 100 000 enregistrements, les statistiques seront mises jour aprs que 100 000/16=6 250 donnes auront chang. Cette
faon doprer est plus rapide que pour une table MyISAM quivalente ; de plus elle est totalement
chaud, cest--dire sans aucun verrou.
Une autre faon de mettre les statistiques jour est dutiliser OPTIMIZE TABLE. En fait, cette commande lance une opration ANALYZE TABLE dans loptique de rquilibrer lindex et ses blocs en le
recrant. Ce procd est plus lourd que la simple mise jour des statistiques, car elle rorganise galement les donnes en plaant un verrou en lecture sur la table, quel que soit son moteur.

Exemple doptimisation dun plan dexecution


La table rental_daz inspire de la table rental de la base de donnes sakila, contient
16 049 enregistrements et possde la structure suivante :
mysql> SHOW CREATE TABLE rental_daz \G
*************************** 1. row ***************************
Table: rental_daz
Create 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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

188

MySQL 5 Audit et optimisation

Plan dexcution de la requte suivante


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: range
possible_keys: rental_date
key: rental_date
key_len: 8
ref: NULL
rows: 2744
Extra: Using where

Lindex rental_date est utilis. Visualisons le cot de la requte :


mysql> SHOW STATUS LIKE 'Last_query_cost';
+-----------------+-------------+
| Variable_name
| Value
|
+-----------------+-------------+
| Last_query_cost | 3842.609000 |
+-----------------+-------------+

Son cot est denviron 3 842. Influenons loptimiseur pour lempcher dutiliser
lindex rental_date et visualisons le cot de la nouvelle requte :
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: ALL
possible_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 |
+-----------------+-------------+

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

189

Une opration full table scan est alors effectue et loptimiseur nutilise donc pas
lindex, ce qui est a priori plus coteux. Cependant, lestimation du cot de cette
requte est moins leve que pour la premire (qui elle utilise lindex rental_date) !
Le client de test mysqlslap permet de confirmer ou non les rsultats, en donnant une
dure dexcution :
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

mysqlslap confirme bien que full table scan est, dans ce cas prcis, plus performant
que la recherche par intervalles sur lindex. On se trouve dans un cas o loptimiseur
ne choisit pas le plan dexcution le plus performant.

Indexer les premiers caractres dune colonne


Comme expos prcdemment, la taille des index peut affecter les performances des
requtes ; elle doit tre la plus petite possible. Cela peut se grer soit en utilisant des
types de champs qui consomment moins de place (tinyint, enum, char(20)...) ou
alors, pour les champs de type chane de caractres (CHAR, VARCHAR, TEXT) en nindexant
pas toute la longueur de la colonne mais seulement les n premiers caractres, avec n
assez grand pour que la slectivit de lindex reste grande ; en dautres termes, il ne faut
pas que les doublons soient trop nombreux.
Par exemple, pour la colonne nom CHAR(255), indexer les 25 premiers caractres avec
INDEX(nom(25)) donne un index 10 fois plus petit que INDEX(nom).

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

190

MySQL 5 Audit et optimisation

Index couvrant (covering index)


Lorsque toutes les colonnes de lindex sont rfrences par les clauses JOIN et WHERE
dune requte SELECT, linformation se trouve entirement dans lindex et aucune
rfrence aux enregistrements nest alors ncessaire. Cela a pour consquence de
minimiser les I/O.

Prfixe dindex (leftmost prefix indexes)


Vous pouvez profiter du fait que MySQL permet lutilisation des premires colonnes
dun index multiple pour viter den crer de nouveaux.
Un index

sur les colonnes a, b et c, peut remplacer


dans les cas suivants (leftmost prefixing) :

INDEX(a,b,c)

INDEX(a,b)

INDEX(a)

et

SELECT * FROM T WHERE a=X


SELECT * FROM T WHERE a=X AND b=Y
SELECT * FROM T WHERE a=X AND b=Y AND c=Z

BON SAVOIR Pas de prfixes dindex pour les index hash


Pour pouvoir utiliser un prfixe dindex sur une table Memory, il faut que lalgorithme des index soit en
B-tree. Les donnes ntant pas tries dans une table de hachage, loptimiseur ne peut alors effectuer
quun full table scan.

Taille des index


La taille des index doit tre la plus petite possible, surtout dans le cas de la cl primaire dInnoDB. Les index de type entier sont de bons candidats. vous dajuster
en fonction de vos besoins : tinyint, smallint, int...

Rcapitulatif des bonnes pratiques doptimisation des requtes


Voici un rcapitulatif sur les bonnes pratiques suivre pour limiter les problmes et
optimiser des requtes.
Avant de crer votre requte, se demander si elle est utile
Avez-vous besoin de connatre en temps rel le nombre dutilisateurs connects sur le
forum ? Si la rponse est non, actualisez les donnes toutes les n minutes ou lorsque
cela est ncessaire.
Lutilisateur a-t-il besoin de savoir que sa recherche renvoie 9 564 234 rsultats ?
Demandez-lui daffiner sa recherche ou affichez une approximation (comme le fait
un clbre moteur de recherche).

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser sa base de donnes : du schma aux requtes


CHAPITRE 6

191

Les donnes ont-elles leur place dans la base ?


Le contenu statique, les images, les vidos, les fichiers binaires... peuvent souvent
tre placs en dehors de la base de donnes. Cependant, les risques dincohrences
augmentent car il est facile deffacer un fichier et doublier de mettre jour lenregistrement correspondant.
Ramener seulement les enregistrements ncessaires
Le surplus de donnes provoque un surcot pour le serveur, pour le rseau et pour le
client.
Jeux dessais
Testez vos requtes avec des jeux de donnes ralistes, proches de la production. En
effet, loptimiseur MySQL ragit diffremment si une table contient peu denregistrements ou si elle en stocke des millions.
Superviser sa base de donnes
Lvolution de la volumtrie ou de la charge peut modifier les performances de vos
requtes.
Tester et valider ses changements avant de les appliquer en production
La requte qui fonctionne sur le poste du dveloppeur et qui met genou le serveur
de production, un grand classique...
Utiliser les types de champs les plus petits possible
Davantage dinformations seront alors charges en mmoire, ce qui minimisera les I/O.
Prter une attention particulire aux colonnes de jointures
Les types de donnes courts acclrent la comparaison.
Les colonnes jointes doivent de prfrence tre du mme type de donnes ; cest en
gnral plus performant.
Penser aux summary tables
Utilisez des tables temporaires, Memory ou MyISAM, pour leurs performances en
lecture, en tant que cache de donnes pour viter dexcuter plusieurs fois les requtes
coteuses. En revanche, les donnes ne seront pas forcment jour.

Dcouper les requtes complexes en plusieurs plus simples.


crire du SQL revient crire une phrase dans une langue. Plus la phrase est petite
et simple plus elle est facilement comprhensible par le serveur.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

192

MySQL 5 Audit et optimisation

Import massif de donnes


Prfrez aux oprations INSERT la commande LOAD DATA INFILE ou le client mysqlimport pour importer dans les tables de gros volumes de donnes.
Pour les tables MyISAM, dsactivez les index : DISABLE

KEYS / ENABLE KEYS.

Pour les tables InnoDB, dsactivez les contraintes si vous tes sr de vos donnes :
UNIQUE_CHECKS=0, FOREIGN_KEY_CHECKS=0.
Les enregistrements des tables InnoDB tant tris dans lordre de la cl primaire,
triez vos donnes dans cet ordre avant de les importer dans la table.
Attention aux mythes
SELECT count(*) ne cote rien : cest vrai, mais seulement pour les tables en
MyISAM et sans clause WHERE.

La clause LIMIT nest pas une clause miracle. Bien utilise, elle limitera le nombre
denregistrements sur le client ; en revanche, elle naura pas forcment un impact sur
le traitement de la requte.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

7
Optimiser son serveur mySQL

Bien configurer votre serveur MySQL nest pas forcment ais. Il vous faut une
bonne dose dexprience saupoudre dune pince de bon sens. Le compromis entre
performance et rapidit trouv un instant t ne sera pas forcment bon t+1 et ne
sera pas bon non plus pour une autre application. En effet, comme on a pu le voir
dans les chapitres prcdents, les performances vont dpendre du schma, des
moteurs de stockage, du type de requtes, de la volumtrie des donnes, de la charge,
et de bien dautres critres, ce qui vous oblige, tout dabord, bien connatre lapplication. Ensuite, la liste des options du serveur MySQL est trs importante et senrichit chaque nouvelle version. Les connatre toutes nest pas une ncessit, mais
connatre certaines dentre elles est incontournable. Nous les avons slectionnes
pour vous. Ces options vont tre affines grce la supervision et lanalyse des
variables dtats (status) associes.

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 dutiliser au mieux ces zones de mmoire pour minimiser les I/O. Elles ne
doivent videmment pas tre trop petites (cest le cas des paramtres par dfaut de

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

194

MySQL 5 Audit et optimisation

MySQL) mais elles ne doivent pas tre trop grandes non plus. Une erreur courante
est de penser que qui peut le plus, peut le moins ; on peut rpondre cela que le trop
est lennemi du plus...
Figure 71

Les principales variables


du serveur MySQL

En effet, en allouant un cache/buffer trop grand, vous gaspillez de la mmoire qui


peut tre utile pour un autre cache/buffer ou qui peut pousser la machine utiliser sa
zone de swap. Un autre inconvnient est quallouer un gros buffer est en gnral plus
coteux que pour un petit !
VOCABULAIRE Cache et buffer (tampon)
Un tampon (buffer) est une zone de mmoire utilise dans le but de stocker de faon temporaire les donnes intermdiaires dun calcul ou excution. Un cache est une zone de mmoire o linformation est
stocke pour y tre relue de nombreuses fois, dans le but de minimiser les accs des couches plus coteuses telles que le disque dur. Les donnes sont donc en thorie amenes tre stockes plus longtemps dans un cache que dans un buffer.
Cela dit, les notions de cache et de buffer sont, dans la terminologie MySQL, identiques. Le
key_buffer en est un bon exemple : stockant les index des tables MyISAM destins tre souvent
relus, il devrait plutt sappeler cache_buffer !

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7

195

Les variables de session


Certaines options du serveur se modifient au niveau de la session, ce qui est trs pratique car elles peuvent tre ajustes par rapport aux besoins spcifiques de chaque
client. Cest le cas des six variables qui suivent.

read_buffer_size
Ce buffer est allou entirement en une seule fois lorsque le client en a besoin. Il sert
lors des oprations de parcours exhaustif (full table scan). En gnral, ce type de plan
dexcution est viter (consultez au chapitre prcdent la section sur la commande
EXPLAIN), mais vous devez augmenter cette variable si lapplication effectue beaucoup
de lectures squentielles.
La variable dtat select_scan est surveiller. Elle indique le nombre de jointures
ayant ralis un scan exhaustif sur la premire table. Les full table scan sur les tables
seules sont galement comptabilises car pour MySQL toute opration SELECT est
une jointure, mme sur une unique table !

read_rnd_buffer_size
Ce buffer est allou en fonction des besoins du client. Il sert lors des lectures ordonnes et peut donc tre utile pour les commandes GROUP BY.

sort_buffer_size
Reprsente la taille du buffer allou pour les commandes GROUP BY/ORDER
allou entirement en une seule fois lorsque le client le demande.

BY.

Il est

Les variables dtat surveiller sont sort_merge_passes et Created_tmp_files.


On peut dcomposer la rcupration du rsultat dune requte SELECT qui effectue un
tri en 3 phases.
1 La clause WHERE permet de rcuprer les enregistrements.
2 Les enregistrements sont tris.
3 Les enregistrements sont lus dans lordre du tri.
La variable sort_merge_passes est affecte lors du tri la phase 2. Le tri seffectue
en mmoire dans le buffer contrl par sort_buffer_size puis, une fois les donnes
tries, survient la phase 3. Si le buffer est trop petit, les enregistrements dj tris et
les autres vont tre stocks dans un fichier temporaire cr sur le disque, qui sera
donc utilis en lieu et place du buffer. Cependant, ce fichier doit tre tri son tour ;
MySQL cre alors un deuxime fichier temporaire pour y stocker les enregistrements
enfin tris. Cest ce deuxime tri qui incrmente la variable sort_merge_passes.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

196

MySQL 5 Audit et optimisation

Bien entendu, les tris sur disque sont coteux. Il faut donc tenter de les viter en augmentant la valeur de sort_buffer_size qui peut diminuer le nombre de
sort_merge_passes et de Created_tmp_files.

join_buffer_size
Ce buffer est utilis notamment lors des jointures sans index. La priorit est donc
doptimiser la jointure en ajoutant des index. Cependant, si cela ne savre pas possible, augmentez cette valeur si la variable dtat superviser Select_full_join est
leve. Il faut savoir quun buffer est utilis par jointure ce qui implique, quen cas de
jointures multiples, plusieurs buffers puissent tre employs.
Select_full_join indique le nombre de jointures sans index effectues (produit
cartsien) : il faut donc viter den raliser.

tmp_table_size et max_heap_table_size
est une variable au nom explicite qui permet bien de fixer la taille
maximale au-del de laquelle les tables temporaires en mmoire cres par MySQL
(avec le moteur Memory) se transforment en table MyISAM en migrant les donnes
sur le disque. Paralllement, il existe une variable nomme max_heap_table_size qui
permet de fixer la taille maximale des tables avec pour moteur de stockage Memory
(Heap est lancien nom de Memory).
tmp_table_size

Il est important de connatre la limite des tables temporaires en mmoire cres par
MySQL : cest la plus petite de ces deux valeurs. Le plus simple est de leur donner la
mme valeur.
Les

deux

variables

dtat superviser sont created_tmp_tables et


Si leur ratio (tables temporaires/tables temporaires sur
disque) est lev, augmentez tmp_table_size et max_heap_table_size.

created_tmp_disk_tables.

Notez quune valeur de created_tmp_disk_tables leve peut indiquer une utilisation de BLOB ou TEXT, deux types non supports par le moteur de stockage Memory.
Les tables temporaires seront alors obligatoirement en MyISAM donc sur disque.

Les variables globales au serveur


Les variables suivantes concernent le serveur tout entier.

Le cache de table
Il est charg de mettre en cache la structure des tables (.frm). Loption est
table_definition_cache. Leurs descripteurs de fichiers sont galement mis en
cache, loption est table_open_cache.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7

197

Les variables dtat 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

table_open_cache

(en units par seconde) est important, augmentez alors


et table_definition_cache.

Le cache de thread
Un thread est utilis pour chaque connexion. Le rle du cache de thread
(thread_cache_size) est alors de le garder en mmoire aprs la dconnexion du client,
en attente dune prochaine connexion. Sa taille se dfinit en nombre de threads.
Les variables dtat superviser sont :
threads_cached : nombre de threads dans le cache ;
threads_connected : nombre de connexions actuelles ;
threads_created : nombre total de threads crs ;
threads_running : nombre de threads actifs ;
connections : nombre de connexions au serveur (russie ou non).
Figure 72

Le cache de thread

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

198

MySQL 5 Audit et optimisation

Il faut que threads_created augmente lentement ; plusieurs stratgies 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 units par seconde, threads_created/uptime) est important.

Table_locks_immediate et Table_locks_waited
Les verrous permettent dassurer la cohrence des donnes mais peuvent tre un frein
lobtention de bonnes performances. En effet, plus longtemps une table sera verrouille, plus le temps dexcution des requtes qui lui sont adresses sera long. Si la
valeur de la variable Table_locks_waited est leve et que vous rencontrez des problmes de performances, plusieurs pistes sont examiner.
Optimisez vos requtes pour que les verrous soient plus courts.
Si vous utilisez des tables MyISAM, fixez concurrent_insert 2 (vous trouverez
plus de dtails ci-aprs).
Utilisez un moteur de stockage qui emploie le verrou niveau enregistrements
(InnoDB).
Rpliquez des tables pour que des traitements se fassent sur un autre serveur.
Partitionnez les tables horizontalement ou verticalement pour fragmenter voire
parallliser les traitements.

Aborted_clients
Il sagit du nombre de connexions fermes non proprement. Les causes peuvent tre :
des problmes de rseau ;
une valeur max_allowed_packet trop faible.

Aborted_connects
Cest le nombre de connexions au serveur MySQL qui ont chou. Les causes peuvent
tre :
des problmes de rseau ;
un mauvais mot de passe ou nom dutilisateur ;
une tentative de connexion un schma inexistant ;
une tentative dattaque.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7

199

Les handlers
Dans la terminologie MySQL, les handlers sont les vnements de linterface entre
le serveur et les moteurs. Les variables dtat handler_* sont trs utiles pour optimiser les requtes.
: comptabilise le nombre de lectures de la premire valeur de
lindex. Une valeur leve peut indiquer un grand nombre de full index scan.

handler_read_first

handler_read_key : indique le nombre denregistrements rcuprs grce lindex.


Une valeur leve signale une bonne utilisation de lindex.
handler_read_next : rvle une lecture ordonne de lindex (une valeur, la suivante,
puis la suivante...). Cest un indicateur de lecture dindex par intervalles ou de full
index scan.
handler_read_prev

traire (ORDER

: comptabilise le nombre de lectures de lindex dans lordre con-

BY DESC).

et handler_read_rnd_next fournissent le nombre denregistrements et le nombre denregistrements suivants lus dans le fichier de donnes. Ces
deux variables sont clairement des indicateurs de mauvaises performances, car elles
sont souvent la consquence de full table scan ou de full join (jointures sans index).

handler_read_rnd

Le rapport handler_read_rnd_next/handler_read_rnd vous donne une estimation


de la taille moyenne dun full table scan. Il faut alors optimiser votre requte ou votre
schma.
Ces variables peuvent tre utilises en complment de la commande EXPLAIN et de la
variable dtat last_query_cost pour mieux comprendre le plan dexcution et optimiser une requte.

Exemple doptimisation dune requte


Structure de la table city
mysql> SHOW CREATE TABLE city \G
*************************** 1. row ***************************
Table: city
Create Table: CREATE TABLE `city` (
`ID` 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 (`ID`),
KEY `Idx_population_cc` (`Population`,`CountryCode`)
) ENGINE=MyISAM

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

200

MySQL 5 Audit et optimisation

Affichage du plan dexcution


mysql> EXPLAIN SELECT avg(Population) FROM city GROUP BY CountryCode\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: c
type: index
possible_keys: NULL
key: Idx_population_cc
key_len: 7
ref: NULL
rows: 4079
Extra: Using index; Using temporary; Using filesort
mysql> SHOW STATUS LIKE Last_query_cost\G
*************************** 1. row ***************************
Variable_name: Last_query_cost
Value: 4963.520924

Le champ Extra : using index indique que MySQL utilise un index couvrant
(covering index), cest--dire que linformation est entirement accessible en parcourant lindex (pas daccs au fichier de donnes). Le champ type : index signale que
loptimiseur effectue un full index scan. Avec Using temporary et Using filesort
une table temporaire est cre et un tri effectu.
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
|
+----------------------------+-------+
Handler_read_first, Handler_read_key

index scan. Handler_read_rnd et


scan sur la table temporaire.

et Handler_read_next indiquent ici un full


traduisent un full table

Handler_read_rnd_next

Handler_update donne une indication sur le nombre de mises jour dans la table
temporaire ( cause du tri).

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7
Handler_write

201

comptabilise le nombre de lignes insres dans la table temporaire.

Ces deux derniers paramtres confirment donc la cration de la table temporaire et


lopration de tri.
Pour obtenir plus dinformations sur le tri
mysql> SHOW SESSION STATUS LIKE sort%;
+-------------------+-------+
| Variable_name
| Value |
+-------------------+-------+
| sort_merge_passes | 0
|
| sort_range
| 0
|
| sort_rows
| 232
|
| sort_scan
| 1
|
+-------------------+-------+
Sort_rows

est le nombre denregistrements tris dans la table temporaire.

Sort_scan

est le nombre de tris effectus.

mysql> SHOW SESSION STATUS LIKE created%;


+-------------------------+-------+
| Variable_name
| Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0
|
| Created_tmp_files
| 0
|
| Created_tmp_tables
| 1
|
+-------------------------+-------+
Created_tmp_tables est le nombre de tables temporaires cres. La bonne nouvelle
est que la table temporaire est place en mmoire (Created_tmp_disk_tables=0).

Avec KEY `Idx_cc_population` (`CountryCode`,`Population`) un index plus pertinent, la structure de la table city est la suivante :
mysql> SHOW CREATE TABLE city \G
*************************** 1. row ***************************
Table: city
Create Table: CREATE TABLE `city` (
`ID` 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 (`ID`),
KEY `Idx_cc_population` (`CountryCode`,`Population`)
) ENGINE=MyISAM

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

202

MySQL 5 Audit et optimisation

mysql> EXPLAIN SELECT AVG(Population) FROM city GROUP BY CountryCode\G


*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: c
type: index
possible_keys: NULL
key: Idx_cc_population
key_len: 7
ref: NULL
rows: 4079
Extra: Using index
mysql> SHOW STATUS LIKE Last_query_cost\G
*************************** 1. row ***************************
Variable_name: Last_query_cost
Value: 4963.520924

Loptimiseur estime que le cot de la requte est le mme quavec le prcdent index.
Cependant, lindex Idx_cc_population(CountryCode,Population) optimise les performances de la requte car il ny a plus, dans la colonne Extra, ni Using temporary
ni Using filesort.
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
|
+----------------------------+-------+
Handler_read_first

et Handler_read_next valident le full index scan.

mysql> SHOW SESSION STATUS LIKE 'sort%';


+-------------------+-------+
| Variable_name
| Value |
+-------------------+-------+
| sort_merge_passes | 0
|
| sort_range
| 0
|

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7

203

| 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
|
+-------------------------+-------+

Pas de tris ni de table(s) temporaire(s). Avec lindex


est donc plus performante.

Idx_cc_population,

la requte

Les droits des utilisateurs


MySQL permet une gestion trs fine des droits. La granularit des permissions va de
linstance la colonne en passant par les tables et les schmas. La principale rgle est
que lapplication ne doit pas avoir tous les droits, pour des raisons videntes de scurit.
Un dcoupage des rles sur le serveur de production peut ressembler ceci :
Tous les droits pour ladministrateur de linstance (root). Seul le DBA possde ce
mot de passe ; il a le droit de crer les utilisateurs et les divers objets (schmas,
tables, procdures stockes...).
Pour lapplicatif qui ne fait que lire, les droits de lecture sur les tables (ou schmas) de lapplication : GRANT SELECT ON appli.* TO user_appli@%
IDENTIFIED BY mot_de_passe;.
Pour lapplicatif qui modifie les donnes, les droits de modification sur les tables
(ou schmas) de lapplication : GRANT INSERT, DELETE, UPDATE ON appli.* TO
user_appli@% IDENTIFIED BY mot_de_passe;.
Pour la rplication : GRANT REPLICATION SLAVE ON *.* TO user_appli@%
IDENTIFIED BY mot_de_passe;.
Noubliez pas quil faut scuriser le mot de passe : il doit tre compos dun mlange
de chiffres, de lettres minuscules et majuscules, de caractres non alphabtiques et il
doit comporter plus de 8 caractres.
Dune manire gnrale, il ne faut donner lutilisateur que les droits pour quil fasse
ce quil doit faire et surtout pas plus. Une attention particulire doit tre porte aux
droits SUPER qui permet de changer des variables de configurations serveur chaud,

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

204

MySQL 5 Audit et optimisation

FILE qui autorise dcrire et de lire des fichiers sur le serveurs et


autorise de donner ses droits un autre utilisateur.

GRANT OPTION

qui

vitez de crer des utilisateurs avec pour host un Fully Qualified Domain Name ou
FQDN (comme mysql1.eyrolles.com) ; prfrez une adresse IP (comme
213.244.11.247).
Avec un FQDN, chaque connexion le serveur devra demander au DNS de
rsoudre ladresse. Cela a un impact sur la dure de connexion (qui peut tre non
ngligeable ; lun des auteurs de cet ouvrage a constat sur lune de ses machines un
surcot dune deux secondes chaque connexion dun client sur le serveur car le
DNS tait particulirement lent). Loption skip-name-resolve dsactive la
recherche de noms par DNS.

Optimisations pour InnoDB, MyISAM et MEMORY


Optimisation InnoDB
La structure en grappe de lindex dInnoDB lui permet de stocker en mmoire aussi
bien ses index que ses donnes. Cest la variable innodb_buffer_pool_size qui contrle la taille de ce cache (cest dailleurs plus un cache quun buffer). Cette variable
est extrmement importante pour les performances des tables InnoDB, car comme
vous vous en doutez, plus sa taille est importante, plus les I/O sont minimiss. Sur
un serveur ddi, avec seulement des tables InnoDB pour votre application (sans
prendre en compte les tables systme qui sont en MyISAM et doivent absolument le
rester), on peut le monter, si ncessaire, jusqu 80 % de la RAM.
Pour ses propres journaux, InnoDB permet de grer leurs tailles, leur nombre et la
taille de leur buffer.
permet de spcifier la taille des journaux. Des fichiers de
grande taille diminuent les I/O mais augmentent les temps de restauration. 128 Mo
est en gnral une bonne valeur.

innodb_log_file_size

innodb_log_buffer_size

dfinit la taille du buffer des journaux. Entre 1 et 8 Mo

sont en gnral suffisants.


est le nombre de journaux dInnoDB. La valeur par
dfaut est 2. Il ny a pas de raisons de la changer dans la plupart des cas.
innodb_log_files_in_group

Les valeurs prconises sont, bien entendu, affiner en fonction de vos applications.
InnoDB tant ACID, chaque transaction valide (COMMIT) conduit un accs disque
pour la flusher, cest--dire lcrire sur le disque et donc la rendre persistante (ou

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7

205

durable, la lettre D de ACID). Ce comportement peut tre modifi en empchant le


flush chaque COMMIT pour limiter les I/O et ainsi gagner en performance. Il y aura
alors un flush par seconde environ, lors des checkpoints dInnoDB. Linconvnient
est que, dans le pire des cas, vous pourrez perdre une seconde de transactions. La
variable est innodb_flush_log_at_trx_commit. Elle peut prendre trois valeurs :
0 : accs disque seulement lors des checkpoints. Il y a un risque de perdre des
transactions en cas darrt brutal de MySQL ou de la machine hte.
1 : le comportement par dfaut. Chaque transaction valide est crite sur le disque.
2 : accs disque lors des checkpoints. Il y a un risque de perdre des transactions en
cas darrt brutal de la machine hte (mais pas de linstance mysqld de MySQL).
Le cache du dictionnaire des tables en InnoDB est paramtrable avec loption
La taille usuelle varie entre 8 et 16 Mo, valeur
augmenter si la commande SHOW ENGINE INNODB STATUS vous le demande ou si vous
grez un trs grand nombre de tables InnoDB.
innodb_additional_mem_pool_size.

Loption innodb_flush_method permet de configurer la manire dont InnoDB interagit avec le systme de fichiers. La liste complte des valeurs quelle peut prendre est
disponible dans la documentation. Nous vous conseillons O_DIRECT ou la valeur par
dfaut, notamment si vous travaillez sous environnement MS Windows.

Optimisation MyISAM
Contrairement InnoDB, le moteur MyISAM ne stocke que ses index dans un
cache : le key_buffer. Le moteur laisse le soin au systme dexploitation de grer les
enregistrements. Le cache dindex de MyISAM a nanmoins le mme but que les
autres caches, celui de minimiser les I/O. Loption qui permet de le paramtrer est
key_buffer_size. Le buffer nest pas allou entirement dun seul coup mais en
fonction des besoins. Sur un serveur ddi, qui ne contient que des tables MyISAM,
il peut reprsenter aux alentours de 30 % de la RAM voire jusqu 50 % mais pas
plus, car le systme dexploitation risque de swaper. Une bonne mthode est de calculer la taille des index des tables MyISAM (.MYI) du serveur.
Pour mesurer son efficacit, il faut surveiller les variables dtat key_reads, qui reprsentent le nombre de blocs de lindex lus sur le disque, et key_read_requests, qui
donnent le bloc de lindex lu dans le key_buffer.
On obtient donc : Hit

ratio = 100 - ((key_reads * 100)/key_read_requests)

Cette valeur doit tre suprieure 99,97 %. Dans le cas contraire, revoyez votre
schma, optimisez vos requtes et/ou augmentez key_buffer_size dans la limite des
30 50 % pour un serveur ddi avec seulement des tables MyISAM.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

206

MySQL 5 Audit et optimisation

Si certaines des tables sont plus critiques que dautres et doivent absolument placer
leurs index dans le cache, vous avez la possibilit de crer dautres caches que vous
pourrez ddier une ou plusieurs tables. Il vous revient de les paramtrer correctement pour que les index y tiennent entirement. Si cest ncessaire, vous pouvez galement prcharger les index dans le cache, ce qui vitera aux premires requtes
daller les chercher sur le disque.

Cache dindex multiples


Extrait de la section [mysqld] du fichier my.cnf
[mysqld]
key_buffer_size=2G # taille du cache dindex commun
cache_idx_table1_table2.key_buffer_size=1G; # Cration dun cache
dindex appel cache_idx_table1_table2 avec une taille de 1 Go
cache_idx_table3.key_buffer_size=500M; # Cration dun cache dindex
appel cache_idx_table3 avec une taille de 500Mo
init_file=/usr/mysql/data/mysqld_init.sql# fichier dinitialisation qui
contient les ordres pour assigner les tables dans leurs caches
respectifs et pour pr-charger les index.

Contenu du fichier mysqld_init.sql


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;

Le moteur de stockage MyISAM implmente le verrou niveau table, ce qui rend ce


type de tables peu performantes dans un environnement avec beaucoup de lectures et
dcritures. Il est cependant possible de parallliser SELECT et INSERT grce loption
concurrent_insert. Elle prend trois valeurs :
0 : les requtes INSERT se comportent comme les autres requtes dcriture ; elles
doivent attendre que la commande SELECT se termine pour relcher le verrou en
lecture sur la table ;
1 : la valeur par dfaut. Si une opration SELECT est en cours sur la table, la commande INSERT peut tre effectue seulement sil ny a pas de trous (causs par des
instructions DELETE) dans la table, cest--dire si SHOW TABLE STATUS a la colonne
Data_free qui vaut 0. La priorit est donc de boucher les trous ;
2 : les requtes INSERT ne sont pas gnes par les SELECT. Les trous ne seront pas
bouchs et les tables auront besoin dtre entretenues avec la commande OPTIMIZE
TABLE, sil y a des DELETE, pour boucher les trous.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7

207

Optimisation Memory
Les donnes et les index des tables qui ont pour moteur de stockage Memory sont
stocks uniquement en mmoire (seule la structure est persistante car un fichier .frm est
cr). Les avantages dun tel moteur sont la rapidit daccs aux donnes et les deux algorithmes dindex hash et B-tree quil implmente (consultez la section Les index ,
page 172).
Au rayon des inconvnients, outre le risque de perdre toutes les donnes larrt du
serveur, vous devez faire attention ce que donnes et index nutilisent pas toute la
mmoire disponible. Avec loption max_heap_table_size vous pouvez dfinir la taille
maximale de toutes les tables Memory du serveur. Attention, cette option nest pas
rtroactive, les tables Memory dj cres ne sont pas affectes. Il vous faudra alors les
recrer en effectuant soit une commande ALTER TABLE ...ENGINE =Memory, soit une
opration CREATE TABLE ou alors TRUNCATE TABLE (qui supprime la table et la recre).
Il est possible de fixer la taille maximale individuellement, avec loption
Elle se place dans la syntaxe de cration ou de modification de la table.

MAX_ROWS.

ATTENTION Limiter la taille des tables


max_heap_table_size est une limite par table. Il est tout fait possible de saturer la mmoire en
crant une multitude de tables.

Si vous voulez vous assurer que les tables Memory contiennent des donnes ds le
dmarrage du serveur MySQL, vous pouvez utiliser loption init-file qui va lire un
fichier contenant des requtes SQL au dmarrage. Dans ce fichier, vous pourrez
insrer des requtes pour charger les donnes (LOAD DATA INFILE, INSERT INTO
SELECT). Cest trs utile en cas darrt brutal.
RAPPEL Limitations du moteur Memory
Le moteur de stockage Memory ne supporte pas les types de champs TEXT et BLOB. De plus, tous ses
enregistrements sont de taille fixe, cest--dire quune colonne de type VARCHAR(255) sera stocke
comme un CHAR(255) qui utilise (en gnral) plus despace.

Le cache de requtes (query cache)


Le cache de requtes ou query cache est un systme de cache mmoire interne
MySQL, transparent pour lapplication, qui ne stocke que les requtes SELECT et leur
rsultat.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

208

MySQL 5 Audit et optimisation

Figure 73

Le cache de requtes

Pour des raisons de performance, les requtes sont haches avant dtre stockes dans le
cache. La fonction de hachage est la fonction MySQL password(). Linconvnient de
cette mthode est que les requtes doivent tre strictement identiques (mme casse,
mmes espaces...) pour une utilisation optimale du cache. Bien quelles renvoient le
mme rsultat, les trois requtes suivantes sont diffrentes pour le cache de requtes :
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 */

En vrifiant les valeurs de hachage respectives, on obtient :


mysql> SELECT PASSWORD('SELECT nom, prenom FROM client WHERE
client_id=123');
+----------------------------------------------------------------+
| PASSWORD('SELECT nom, prenom FROM client WHERE client_id=123') |
+----------------------------------------------------------------+
| *79210368274F82B25F2CABB01CEF24CE7FED24BD
|
+----------------------------------------------------------------+

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7

209

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
|
+----------------------------------------------------------------+

En cas de modifications dune table dont les donnes sont dans le cache, toutes les
requtes en relation avec cette table sont invalides ; le cache de requtes est toujours
jour. Il nest donc en gnral pas pertinent de placer en cache les requtes SELECT sur des
tables trs souvent modifies. Le cache de requtes est en revanche utile lorsque :
les modifications sur les tables ne sont pas trs frquentes ;
il y a beaucoup de requtes de lectures identiques ;
les tables sont en MyISAM, un peu moins pour InnoDB cause de limplmentation du MVCC ;
vous utilisez plusieurs petites tables au lieu dune seule volumineuse ;
si vous envoyez vos critures par lots (type batch), linvalidation naura lieu quune fois.
Il est difficile de savoir de prime abord si le cache de requtes va avoir un impact
positif ou non. Son efficacit est li au type de requtes SELECT, leur frquence et
la frquence des critures dans les tables... Le gain nest pas vident et est loin dtre
systmatique, car pour chaque requte qui arrive sur le serveur, MySQL doit en plus
de lanalyser, la hacher, vrifier si elle est prsente dans le cache et tout ceci a un cot.
Une requte qui renvoie un gros rsultat peut tre intressante placer dans le cache
si sa dure dexcution est longue. Mais si elle doit prendre de la place en vinant un
grand nombre de requtes, ces dernires causeront des accs disque supplmentaires
pour tre nouveau insres dans le cache.
Vous pouvez calculer le taux defficacit du cache de requtes avec la formule
suivante : Qcache_hits/(Qcache_hits + Com_select). Bien entendu, plus le rsultat
est lev, plus le cache est intressant. Cependant, mme un rsultat de 50 % pourrait signifier quil apporte un gain... Finalement, la seule vraie rgle que lon peut
vous donner, qui est de plus tout le temps valable, est de tester !

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

210

MySQL 5 Audit et optimisation

Gestion du cache de requtes


Le cache de requtes nest pas utilisable par dfaut, car la variable query_cache_size
vaut 0. Pour lactiver, il faut lui donner une taille en octets dans le fichier de configuration. Vous pouvez cependant lactiver chaud avec la commande SET GLOBAL
query_cache_size. Assurez-vous galement que la variable query_cache_type est
diffrente de OFF.
Il peut prendre trois valeurs :
ON : les requtes SELECT sont mises en cache. Une certain nombre de critres doivent cependant tre respects :
la clause SQL_NO_CACHE ne doit pas tre prsente dans la requte SELECT ;
le rsultat renvoy doit tre infrieur la valeur de query_cache_limit ;
la requte ne doit pas contenir de fonctions non dterministes (now, rand,
current_date...).
DEMAND : ne stocke que les requtes contenant la clause SQL_CACHE.
OFF : dsactive le cache. Notez que la mmoire nest dsalloue que si
query_cache_size = 0.
Pour une optimisation maximale, il est parfois ncessaire de choisir explicitement les
requtes qui iront dans le cache. Dans ce cas, rglez query_cache_type DEMAND et
slectionnez vos requtes en ajoutant la clause SQL_CACHE.
Le cache peut tre dfragment avec la commande FLUSH QUERY CACHE. Elle ne le
videra pas. Si cest ce que vous recherchez, utilisez alors la commande RESET QUERY
CACHE. FLUSH TABLES vide galement le cache de requtes, comme si vous redmarriez le serveur.
ATTENTION Taille du cache de requtes
Les phases dinvalidation peuvent tre assez coteuses. Il est donc recommand de ne pas donner une
taille trop importante au cache de requtes (128 256 Mo maximum).

Les variables dtat surveiller sont :


Qcache_free_blocks : nombre de blocs libres ;
Qcache_free_memory : mmoire libre ;
Qcache_hits : nombre de fois quil a servi ;
Qcache_inserts : nombre de requtes insres ;
Qcache_lowmem_prunes : nombre de requtes supprimes par manque de place ;
Qcache_not_cached : nombre de requtes impossibles placer en cache ;
Qcache_queries_in_cache : nombre de requtes dans le cache ;
Qcache_total_blocks : nombre de blocs de mmoire.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7

211

Le partitionnement
Le partitionnement est un type darchitecture qui consiste diviser une table en plusieurs parties. Cette technique de conception peut tre une solution pour augmenter
les performances de votre application notamment si le volume de donnes est important. Les tables peuvent tre partitionnes verticalement, cest--dire dcoupes dans
le sens des colonnes, ou horizontalement, dcoupes cette fois dans le sens des enregistrements. MySQL ne gre automatiquement que le partitionnement horizontal
depuis la version 5.1 ; cest donc ce type que nous allons voquer ci-aprs.
Figure 74

Les diffrents types de partitionnement

Loptimiseur sait sur quelles partitions se trouve chaque enregistrement. Il se peut


alors, si les donnes recherches ne se trouvent pas sur toutes les partitions, que le
temps de rponse dune recherche sen trouve amlior. Ce mcanisme sappelle le

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

212

MySQL 5 Audit et optimisation

pruning ; en dautres termes, cest la facult danalyser seulement les partitions qui
contiennent les enregistrements recherchs.
La clause PARTITIONS de la commande
analyses par loptimiseur.

EXPLAIN

permet de connatre les partitions

Visualisation des partitions parcourues par le plan dexcution sur deux scnarios
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

MySQL propose quatre types de partitionnement. Il se dfinit au niveau de la structure de la table, lors de la cration ou en modifiant sa structure :
RANGE : permet de spcifier des intervalles de valeurs ;
LIST : est une division des donnes sous forme de listes de valeurs ;
HASH : est lutilisation dune cl de hachage pour rpartir les donnes de faon
homogne ;
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, cest--dire la ou les colonnes choisies pour tre

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7

213

partitionnes, doit tre de type entier ou compose dune fonction qui retourne un entier
ou une valeur NULL. Cette limitation ne sapplique cependant pas pour le partitionnement par KEY. Si la table possde un index unique ou une cl primaire, la cl de partition
doit tre au moins une partie de cet index unique (ou cl primaire).

Le partitionnement par RANGE


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

Pour chaque partition, la valeur doit tre strictement infrieure la borne. Par
exemple, dans la partition p_id_moins_de_128 seront stockes les valeurs comprises
entre 64 et 127. Lordre des partitions est important : elles ne peuvent tre dfinies
que de la plus petite la plus grande et la clause MAXVALUE, qui permet de spcifier la
borne maximale de toutes les partitions, ne peut tre que la dernire de la liste.
Le plus important dans le partitionnement est le choix de la cl de partitionnement.
Ce choix seffectue principalement en fonction du type de requtes excutes sur la
table. Lalgorithme RANGE est trs utile pour partitionner des dates. Mais les types
datetime et timestamp de MySQL ne sont pas des entiers. Il faut donc utiliser une
fonction sur cette colonne qui renvoie un entier ou la valeur NULL.
La fonction YEAR() est toute indique : elle extrait lanne dune date et la retourne
sous la forme dun entier. Une autre fonction recommande est TO_DAYS(). Elle
prend une date en entre et retourne un entier qui reprsente le nombre de jours
depuis lanne 0. La fonction peut galement tre place lors de la dfinition de
chaque partition. Notez que la valeur NULL est considre comme tant infrieure
tous les nombres entiers. En dautres termes, si le champ a des valeurs NULL, ces dernires iront dans la premire partition.
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));

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

214

MySQL 5 Audit et optimisation

Le partitionnement par LIST


PARTITION BY LIST (nature_message) (
PARTITION p_undef VALUES IN (NULL),
PARTITION p_faux VALUES IN (0),
PARTITION p_vrai VALUES IN (1));

Pour partitionner par LIST, il faut indiquer les valeurs acceptes pour chaque partition. Lalgorithme LIST permet demployer la valeur NULL comme valeur de partitionnement. En revanche, si vous essayez dinsrer un nombre qui nest pas dans la liste
des valeurs permises dune des partitions, une erreur sera lance par MySQL. Ce
mcanisme permet de renforcer la cohrence des donnes dans le SGBDR.

Le partitionnement par HASH


PARTITION BY HASH (id_ville) PARTITIONS 4 ;

Il faut indiquer le nombre de partitions crer. Lalgorithme de partitionnement


HASH est idal pour les valeurs squentielles, comme les AUTO_INCREMENT. En effet, il
permet de distribuer de faon homogne les donnes dans les diffrentes partitions. La
distribution des donnes sur les partitions est assez simple : cest un modulo (le reste de
la division entire). Si vous disposez de trois partitions, p0, p1 et p2, un enregistrement
ira dans p0, le suivant dans p1, le suivant dans p2, le suivant dans p0, etc.
Le calcul effectu par MySQL est le suivant :
IF(ISNULL(valeur_partition), 0, ABS(valeur_partition)) MOD
nbr_de_partitions

Lalgorithme HASH a une variante, LINEAR HASH, qui a pour effet de rendre
plus rapide les tches de maintenance sur les tables partitionnes (suppression,
fusion, ajout...). En contrepartie, la distribution des donnes sur les diffrentes partitions est moins homogne.

Le partitionnement par KEY


PARTITION BY KEY (isbn) PARTITIONS 3 ;

Comme pour le type HASH, il faut indiquer le nombre de partitions crer. Ce partitionnement permet lui aussi de distribuer de faon homogne les donnes dans les
diffrentes partitions. Il se diffrencie nanmoins par la possibilit donne lutilisateur de choisir plusieurs colonnes ou aucune comme critre de partitionnement

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Optimiser son serveur mySQL


CHAPITRE 7

215

condition quelles appartiennent toutes la cl primaire (ou un index unique), ou


alors que la table ne contienne pas de cl primaire ou dindex unique.

Partitionner sur diffrents disques


Les tables MyISAM peuvent stocker leurs partitions des endroits diffrents de celui
du rpertoire de donnes par dfaut. Ceci est valable pour les fichiers de donnes
(.MYD) mais galement pour les fichiers dindex (.MYI). Cette possibilit est bien pratique en cas de fortes charges et/ou de gros volumes de donnes, pour rpartir les donnes et la charge de votre application sur plusieurs disques. Notez que cette fonctionnalit nest disponible que pour MyISAM mais pas en environnement MS Windows.

Partitionner sur diffrents disques avec MyISAM


La 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 `idx_message_id` (`message_id`)
) ENGINE = MYISAM
PARTITION 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 leves partir de MySQL 5.5. Il est par exemple possible de partitionner une
table en fonction de plusieurs colonnes qui peuvent tre de type entier, chane (char, varchar), DATE
ou DATETIME.
B http://dev.mysql.com/doc/refman/5.5/en/partitioning.html

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

8
La rplication MySQL

Les architectures modernes doivent faire face de plus en plus frquemment diverses
problmatiques telles que le dimensionnement, la tolrance aux pannes ou encore la
continuit de services. Une des rponses apportes par les systmes de gestion de
bases de donnes est la possibilit de pouvoir gnrer et grer plusieurs copies des
donnes (ou rpliques). MySQL implmente, depuis la version 3.23.15, une solution
de rplication native, gratuite et plutt simple mettre en uvre, qui se nomme tout
simplement MySQL replication.

Introduction la rplication
Avant de prsenter les diffrents mcanismes de la rplication, dfinissons quelques
termes qui seront employs dans ce chapitre.
La rplication est un procd qui consiste recopier des donnes sur plusieurs serveurs.
Une rplication peut tre synchrone : un serveur A envoie des donnes un serveur B
et doit attendre que ce dernier finisse son traitement et le prvienne (avec un accus de
rception, par exemple), pour quil puisse poursuive. Une rplication peut galement
tre asynchrone : dans ce cas, le serveur A nattend pas de rponse du serveur B pour
continuer. Les serveurs rpliqus sont de deux types : le matre, qui contient les donnes de rfrence, et lesclave, qui sy approvisionne.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

218

MySQL 5 Audit et optimisation

La rplication MySQL est asynchrone, ce qui permet dobtenir de bonnes performances. En revanche, au moment o ces lignes sont crites, il nexiste aucun mcanisme intgr dans MySQL qui permette de sassurer que les rpliques contiennent
exactement les mmes donnes. Cependant, des alternatives existent comme la rplication semi-synchrone de la MySQL Replication Team (http://forge.mysql.com/wiki/ReplicationFeatures/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).
Figure 81

Architectures de rplication

La rplication est compose dun seul serveur matre et dun ou plusieurs serveurs
esclaves. Si en thorie il ny a pas de limite au nombre desclaves, en pratique les contraintes sont dordre conomique et physique (nous reviendrons sur ce dernier point
ultrieurement). Toute modification de donnes doit seffectuer sur le matre car
linformation ne peut circuler que dans un seul sens, du matre vers lesclave. En

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

219

dautres termes, si des critures sont excutes sur un esclave, les rpliques ne seront
plus identiques. Une consquence de cette limitation est que le matre peut devenir
un goulot dtranglement cause des requtes dcritures. Autre point pineux, la
rcupration des donnes du matre par lesclave est ralise par un seul thread, ce qui
peut entraner en cas de forte charge sur le matre ou sur lesclave, ou si ce dernier est
moins performant, des retards de rplication.
La rplication offre une grande diversit darchitectures, du simple un matre et un
esclave des chanes de serveurs.

Intrt de la rplication
Une application reste rarement fige ; ses fonctionnalits peuvent changer au gr des
besoins du client ou de nouvelles contraintes. Il suffit par exemple que votre application web gagne en popularit, pour que la base de donnes qui ne se faisait pas
remarquer jusque-l, commence montrer des signes dessoufflement et ce, parce
que le volume des donnes a considrablement augment et/ou que la charge des
requtes sest dmultiplie. Pensez aux cots lis une rupture de service qui peuvent
se chiffrer en centaines de milliers deuros... est-ce cela la ranon du succs ?
Si vous vous reconnaissez dans ce portrait robot dune success story annonce, cest que
vous avez srement besoin dune architecture de base de donnes qui rponde aux
problmatiques de haute disponibilit, de capacits de dimensionnement, de redondance gographique ou alors qui vous permette doprer des sauvegardes chaud. La
rplication de MySQL est ce dont vous avez besoin car elle propose des solutions
ces diffrentes problmatiques.

Le dimensionnement horizontal (scale out)


Cest la possibilit dassumer une augmentation de la charge des requtes de lecture,
en la rpartissant sur plusieurs esclaves. Aucun bnfice pour les requtes dcriture
parce quelles doivent toutes seffectuer sur le matre.

La sauvegarde chaud (hot backup)


Un des serveurs esclaves peut servir de serveur de sauvegarde, ce qui permet de raliser des sauvegardes chaud, cest--dire sans impact sur lapplication. Attention
toutefois, une rplique ne peut tre considre comme une sauvegarde. Une requte
malheureuse sur le matre (DROP TABLE, DELETE/UPDATE sans clause WHERE) sera
rplique sur les esclaves, y compris celui ddi la sauvegarde. De plus, la rplica-

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

220

MySQL 5 Audit et optimisation

tion ne contient, nativement, aucun mcanisme qui permette de sassurer que toutes
les rpliques contiennent exactement les mmes donnes.

Le basculement automatique (Failover)


En cas de panne du serveur actif, lapplication peut tre bascule sur le serveur passif
(actif/passif du point de vue de lapplication car le serveur MySQL fonctionne sur les
deux machines). La continuit de service est alors assure. Notez que la rplication
tant asynchrone, certaines prcautions doivent tre prises. Ce point est discut ultrieurement dans ce chapitre.

Redondance gographique
La rplication est asynchrone. Ainsi, elle offre la possibilit, sans pnaliser les performances du serveur matre, de rpartir ses donnes diffrents endroits (villes, pays,
continents...). Cest un bon moyen de rduire les risques lis aux sinistres et, pour les
clients, dtablir des bases de donnes locales accessibles uniquement en lecture pour
les donnes rpliques. Notez quil est toujours possible dutiliser ces serveurs
MySQL locaux, en criture sur des tables elles aussi locales, ces dernires ne faisant
pas partie de la rplication.

Le cas du dcisionnel
Les esclaves nont pas besoin dtre connects en permanence au matre. Il est donc
possible dactiver et de dsactiver la rplication souhait pour alimenter un entrept
de donnes (data warehouse). De plus, la granularit de la rplication tant la table,
ces dernires peuvent tre rparties sur plusieurs serveurs pour amliorer les performances des requtes complexes. Ce point est discut ultrieurement dans ce chapitre.

Tester une nouvelle version de MySQL


La rplication offre une compatibilit ascendante : il est donc pratique de mettre en
place un serveur de tests comme rplique, pour sassurer du bon fonctionnement de
votre application avec une nouvelle version du serveur ou plus simplement pour
tester de nouveaux moteurs de stockage. La version de la rplique doit tre suprieure
ou gale celle du matre.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

221

lintrieur de la rplication
Le processus de rplication est assez simple : lessentiel du travail est ralis par
lesclave qui se connecte sur le serveur matre avec un compte utilisateur qui possde
le droit REPLICATION SLAVE et linforme de sa prsence. Les tapes du processus (voir
figure 8-2) sont :
1. Une requte dcriture arrive sur le matre.
2. Elle est stocke dans son journal binaire.
3. 6. io_thread la rcupre et la copie sur lesclave dans le journal relais (relay
log).
7. Enfin, sql_thread lexcute sur lesclave. La requte est rplique.
Les informations relatives la rplication sont rendues persistantes grce des
fichiers crs sur lesclave :
master.info contient les informations relatives au io_thread comme le nom du
journal binaire du matre, la position dans ce journal, le nom du compte utilisateur de rplication, les informations relatives au serveur matre, etc.
relay-log.info contient les informations relatives au sql_thread comme le nom
et la position dans le relay-log, le nombre doctets lus du journal binaire du matre, etc.
Figure 82

Les dtails de la rplication

Mise en place de la rplication


Mettre en place une architecture de rplication est une opration assez basique. La
procdure est dtaille dans la documentation officielle de MySQL (http://

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

222

MySQL 5 Audit et optimisation

dev.mysql.com/doc/refman/5.1/en/replication.html). En substance, il faut configurer les deux


types de serveurs, le matre et lesclave comme expliqu ci-aprs.

Configuration du matre
1 Activez le journal binaire dans le fichier de configuration.
2 Donnez une valeur unique (parmi toutes les rpliques) au paramtre server-id.
Section mysqld issue du fichier de configuration MySQL
[mysqld]
log-bin = mysql-bin
server-id =1

3 Crez un utilisateur qui sera employ uniquement pour la rplication. Il ne doit

possder que le droit


tches de rplication.

REPLICATION SLAVE,

qui lui permet de neffectuer que les

mysql> GRANT REPLICATION SLAVE ON *.* TO replic_user@% IDENTIFIED BY


P455w0Rd;

ATTENTION Mot de passe en clair


Le mot de passe de lutilisateur est stock en clair dans le fichier master.info. Ce dernier doit donc
tre protg et cest une raison supplmentaire de ne donner que le droit REPLICATION SLAVE
lutilisateur de rplication.

4 Aprs redmarrage du serveur MySQL pour que les nouvelles informations pla-

ces dans le fichier de configuration soient prises en compte, vrifiez que tout sest
bien droul.
Vrification du paramtrage du serveur matre
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

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

223

mysql> SHOW GRANTS FOR replic_user@%;


*************************** 1. row ***************************
Grants for replic_user@%: GRANT REPLICATION SLAVE ON *.* TO
replic_user@% IDENTIFIED BY PASSWORD
*24C0571BAA4117CC0452B2CD186A3DD9D9B3920F

5 La dernire tape consiste effectuer une sauvegarde du matre en la synchroni-

sant avec les journaux binaires. Elle sera restaure sur lesclave pour initialiser la
rplication. Le but est dobtenir, un instant t, deux serveurs avec exactement les
mmes donnes. Plusieurs mthodes sont possibles (copie physique froid,
LVM, etc.). Lune dentre elles est lutilisation du client texte mysqldump qui permet de raliser des sauvegardes logiques (des dumps) HOT si la base ne compte
que des tables InnoDB ou WARM (avec un verrou en lecture) dans le cas contraire. Cest loption --master-data qui permet la synchronisation de la sauvegarde avec les journaux binaires, en rajoutant, dans le dump, la commande CHANGE
MASTER TO MASTER_LOG_FILE=mysql-bin.xxxxxx, MASTER_LOG_POS=xxx. Cette
commande est utilise par le serveur esclave pour paramtrer la rplication. Nous
y reviendrons dans quelques lignes.
shell> mysqldump ----lock-all-tables ----master--data ----flush--logs
----routines ----all--databases --u user_dump --p >
sauvegarde_totale.sql

Si vous utilisez un autre moyen de sauvegarde, vous devez verrouiller la base et rcuprer
les informations relatives au journal binaire avec la commande SHOW MASTER STATUS.
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 rcuprer le journal et sa position */
/* Effectuer la sauvegarde ! */
mysql> UNLOCK TABLES;
/* Et ne surtout pas oublier de dverrouiller */

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

224

MySQL 5 Audit et optimisation

BON SAVOIR Filtrage des donnes rpliques


Vous pouvez choisir de ne rpliquer que les donnes de certaines bases. Le filtre peut prendre place sur le
serveur matre. Il consiste demander au serveur de ne stocker dans le journal binaire que les transactions concernant les tables appartenant aux bases slectionnes avec le paramtre binlog-do-db ou
alors de lui demander dignorer les transactions concernant les bases avec binlog-ignore-db. La
liste des bases filtres peut tre visualise avec la commande SHOW MASTER STATUS.

Attention, le filtre ne fonctionne pas pour les DDL si les requtes dcriture sont
excutes depuis un autre schma. Pour les DML, le mode de journalisation ROW
permet de saffranchir de cette limitation.
Dans le fichier de configuration du serveur matre, on prcise de ne pas stocker dans
le journal binaire les requtes dcritures concernant les schmas mysql et test.
[mysqld]
binlog-ignore-db = mysql
binlog-ignore-db = test

La connexion au schma mysql et la cration de la table t1 (DDL) dans le schma


sur le serveur matre sont ralises de la manire suivante :

test

mysql_master> USE mysql


mysql_master> CREATE TABLE test.t1(i int);

La table est quand mme cre sur le serveur esclave. Le filtre ne fonctionne pas car
la requte nest pas excute dans le schma test du matre.
mysql_slave> SHOW TABLES IN test;
+----------------+
| Tables_in_test |
+----------------+
| t1
|
+----------------+

Diffrente cause, mme effet : le filtre ne fonctionne toujours pas, pour une DML
cette fois.
mysql_master>

INSERT INTO test.t1 (i) VALUES (97224);

mysql_slave> SELECT * FROM test.t1;


+-------+
| i
|
+-------+
| 97224 |
+-------+

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

225

En revanche, si la requte est excute depuis le schma test du matre, la donne de


la table rplique de lesclave nest pas modifie. Dans ce cas, le filtre fonctionne :
mysql_master> USE test
Database changed
mysql_master> UPDATE t1 SET i=93;
mysql_slave> SELECT * FROM test.t1;
+-------+
| i
|
+-------+
| 97224 |
+-------+

Configuration de lesclave
1 Donnez une valeur unique au paramtre server-id (diffrente de celle du matre

et des autres esclaves).


[mysqld]
server-id=10
Restaurer la sauvegarde du matre sur lesclave :
shell> mysql -u user_restore -p < sauvegarde_totale.sql

2 Configurez la rplication, en donnant lesclave toutes les informations ncessai-

res pour quil puisse se connecter au matre et surtout la bonne position dans le
bon journal binaire :
MASTER_HOST : adresse IP ou nom dhte du serveur matre ;
MASTER_USER : compte que va devoir utiliser lesclave pour se connecter au serveur matre ;
MASTER_PASSWORD : mot de passe du compte utilisateur de rplication ;
MASTER_PORT : port du serveur matre ;
MASTER_LOG_FILE : nom du journal binaire du matre, dans lequel les donnes
ont t insres aprs la sauvegarde restaure sur lesclave ;
MASTER_LOG_POS : position dans le journal binaire du matre.
Si vous avez utilis mysqldump avec loption master-data, vous navez pas besoin de
renseigner ces deux derniers paramtres car ils sont configurs lors de la restauration.
Dans le cas contraire, il faut y mettre les valeurs de la commande SHOW MASTER
STATUS excute prcdemment sur le matre.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

226

MySQL 5 Audit et optimisation

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 mthode de configuration


Il existe une autre manire de configurer la rplication. Elle consiste mettre les informations suivantes
master-host, master-user, master-password et master-port dans le fichier de configuration. Mais cette mthode est obsolte et ne sera plus gre par MySQL dans les futures versions.

3 Et enfin, dmarrez la rplication :


mysql> START SLAVE;

REMARQUE Mettre jour lesclave avant le matre


Il est conseill dutiliser les mmes versions de MySQL pour toutes les rpliques. Nanmoins, en cas de
versions majeures diffrentes, lesclave doit employer la version ayant le chiffre le plus lev. Lune des
raisons est que si le format des journaux binaires est mis jour sur le matre dune version du serveur
MySQL plus rcente que celle de lesclave, ce dernier pourrait ne pas tre capable de dchiffrer le nouveau format.

Configuration avance de lesclave


Plusieurs paramtres permettent daffiner la configuration du serveur esclave. Avec
loption slave_compressed_protocol, il est possible de compresser le flux des donnes entre le matre et lesclave au format gzip, mais au prix dune charge processeur
plus importante.
Nous avons vu que la rplication seffectue du matre vers lesclave et que si une criture a lieu sur ce dernier, les deux rpliques ne sont plus identiques, ce qui peut
entraner une cassure de la rplication. Pour rduire les risques, il est possible de
placer lesclave en lecture seule avec loption read_only = 1. Malgr tout, les clients
ayant le droit SUPER pourront y crire.
La rplication se met en route automatiquement chaque dmarrage du serveur
MySQL. Ce comportement peut tre modifi avec loption skip-slave-start. Nous
vous conseillons dactiver cette option car, en cas darrt imprvu du serveur, il est plus
prudent de mener quelques investigations afin de sassurer que les donnes sont dans
un tat cohrent, avant de redmarrer. Vous devrez alors utiliser START SLAVE.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

227

Comme vous le savez, le journal binaire stocke toutes les requtes dcritures reues
par le serveur. Les donnes rpliques sont des requtes dcritures et il est donc
naturel de penser quelles sont leur tour stockes dans le journal binaire de lesclave.
Ce nest pourtant pas le cas par dfaut. Pour que cela se produise, il faut activer
loption log_slave_updates sur le serveur esclave.
Les options report_host et report_port permettent respectivement de rcuprer le
nom dhte et le port de lesclave sur le matre. Cest pratique lorsque larchitecture
de rplication comporte beaucoup de serveurs.
MySQL permet de ne rpliquer que les donnes de certaines tables. Le filtre peut
fonctionner sur le matre, comme nous lavons vu au paragraphe prcdent ; cependant, il peut galement oprer sur lesclave.
replicate-do-db (replicate-ignore-db) permet de rpliquer (ou de ne pas
rpliquer) les tables dun schma.
replicate[-wild]-do-table (replicate[-wild]-ignore-table) sert rpliquer
(ou ne pas rpliquer) cette table.
Ce type darchitecture sert notamment lorsquon dsire rpartir des donnes
(schmas, tables) sur diffrents serveurs, ou encore si vous ne souhaitez pas rpliquer
les tables systme qui contiennent les utilisateurs. Attention tout de mme, comme
pour les variables binlog-ignore-db et binlog-ignore-db sur le serveur matre, des
prcautions lies au contexte dexcution des requtes et au mode de journalisation
doivent tre prises. Voir la documentation officielle pour plus de dtails.
Filtrage de la rplication sur le serveur esclave
[mysqld] # serveur esclave parisien
replicate-do-db = fournisseur
replicate-do-db = paris_client
[mysqld] # serveur esclave lyonnais
replicate-do-db = fournisseur
replicate-do-db = lyon_client

Commandes de la rplication
Une fois larchitecture de rplication mise en place, il faut sassurer de son bon fonctionnement et pouvoir dtecter les problmes. MySQL fournit un ensemble de commandes pour la grer et la superviser.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

228

MySQL 5 Audit et optimisation

Sur lesclave
La commande RESET SLAVE efface les fichiers master.info et relay-log.info et rinitialise les fichiers relais, en mettant jour relay-bin.index et en supprimant les
index relay-bin.xxxxxx pour reprendre la numrotation .000001 (relaybin.000001). Elle sert principalement rinitialiser la rplication lors dun Failover,
aprs une erreur de rplication, etc.
ATTENTION Consquences dun RESET SLAVE
Attention lutilisation de la commande RESET SLAVE. Une fois excute, lesclave naura plus
aucune information sur son matre, ni sa position dans le journal binaire, ni dans le journal relais. Il vous
faudra alors remettre en place une rplication avec la commande CHANGE MASTER TO.

permet darrter et dmarrer la rplication. Nanmoins, une


gestion plus fine des threads est possible en ajoutant, ces deux commandes, le nom
de celui que lon veut manipuler, io_thread ou sql_thread. Cest souvent utile pour
sassurer que lesclave sarrte un point prcis (lors dun changement de matre par
exemple) ou pour essayer de corriger un problme de rplication.

[START | STOP] SLAVE

mysql> STOP SLAVE io_thread ;/* arrte seulement le thread IO */


/* attendre que le sql_thread termine sa tche */
mysql> STOP SLAVE sql_thread;/* arrte seulement le thread SQL */

Une autre possibilit, mais seulement pour la commande START SLAVE, est de pouvoir dmarrer et surtout programmer larrt du sql_thread, en sassurant que les vnements du journal binaire du matre ou du journal relais de lesclave sont excuts
jusqu une certaine position. Cest particulirement utile pour synchroniser deux
serveurs, comme le permet la fonction MASTER_POS_WAIT.
Synchronisation de deux serveurs avec la clause UNTIL de la commande START SLAVE SQL_THREAD
/* sur le matre */
mysql_master> FLUSH TABLES WITH READ LOCK;
mysql_master> SHOW MASTER STATUS \G
*************************** 1. row ***************************
File: mysql-bin.000019
Position: 121068330
/* sur lesclave */
mysql_slave> START SLAVE SQL_THREAD UNTIL MASTER_LOG_FILE = mysqlbin.000019, MASTER_LOG_POS =121068330;

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

229

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

Une autre alternative consiste utiliser la fonction MASTER_POS_WAIT.


Synchronisation de deux serveurs avec la fonction master_pos_wait
/* sur le matre */
mysql_master> FLUSH TABLES WITH READ LOCK;
mysql_master> SHOW MASTER STATUS \G
*************************** 1. row ***************************
File: mysql-bin.000019
Position: 121068330
/* sur lesclave */
mysql_slave> START SLAVE;
mysql_slave> SELECT MASTER_POS_WAIT(mysql-bin.000019, 121068330);
/* rend la main quand lesclave a rattrap son retard sur le matre */
mysql_slave> STOP SLAVE;
mysql_slave> SHOW SLAVE STATUS \G
*************************** 1. row ***************************

Slave_IO_Running: No
Slave_SQL_Running: No

Exec_Master_Log_Pos: 121068330

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

230

MySQL 5 Audit et optimisation

Pour superviser la rplication, une commande suffit : SHOW SLAVE STATUS. Elle rcupre notamment les informations concernant le matre et lesclave contenues dans les
journaux 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 rcupr toutes les donnes du
journal binaire du matre ;
Slave_IO_Running et Slave_SQL_Running : si une de ces deux valeurs vaut No, la
rplication est arrte. Ces deux paramtres sont surveiller, car cest grce eux
que vous vous apercevrez que la rplique ne fonctionne pas normalement (ou plus
du tout) ;
Read_Master_Log_Pos : position, dans le journal binaire, du dernier vnement lu
et ramen sur lesclave par io_thread ;
Exec_Master_Log_Pos : position du dernier vnement, du journal relais, excut
par sql_thread ;
Master_Log_File : nom du dernier journal binaire du matre ;
Relay_Master_Log_File : nom du journal binaire dans lequel io_thread a lu son
dernier vnement.
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 matre. Il
=
Exec_Master_Log_Pos ainsi que
faut pour cela que Read_Master_Log_Pos
Master_Log_File = Relay_Master_Log_File.

quelques mots sur la variable Seconds_Behind_Master, qui estime le nombre de

secondes de retard qua lesclave sur le matre. Ce temps est calcul en comparant la
valeur du timestamp du serveur esclave avec celui enregistr au moment de lcriture
des vnements dans le journal binaire (consultez le chapitre 5 sur les journaux pour
plus dexplications). Ce nombre peut tre imprcis cause de plusieurs raisons
(rseau instable, une transaction trs longue, etc.) ; il faut donc le prendre pour ce
quil est, cest--dire une estimation. Cependant, des outils de meilleure prcision
existent, comme le script mk-heartbeat du maatkit (http://www.maatkit.org/) ;
Last_Error indique lerreur courante ayant caus larrt de la rplication. Vous
retrouverez ces informations dans le journal des erreurs.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

231

La commande SHOW SLAVE STATUS


mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 23.24.25.1
Master_User: replic_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000017
Read_Master_Log_Pos: 31135551
Relay_Log_File: mysql-relay-bin.000047
Relay_Log_Pos: 31135684
Relay_Master_Log_File: mysql-bin.000017
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 31135551
Relay_Log_Space: 31135684
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:

Une autre faon de sassurer du bon fonctionnement des threads io_thread et


sql_thread est dexcuter la commande SHOW STATUS LIKE Slave_running. Elle
=
retournera la valeur ON si et seulement si Slave_IO_Running
YesetSlave_SQL_Running = Yes.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

232

MySQL 5 Audit et optimisation

De plus, si vous avez renseign dans le fichier de configuration de lesclave les paramtres report-host et report-port, alors il est possible de consulter ces informations avec la commande SHOW VARIABLES LIKE report%;
Enfin, la commande
de sql_thread.

SHOW PROCESSLIST

permet de connatre ltat de

io_thread

et

Visualiser ltat de io_thread et de sql_thread


mysql> SHOW PROCESSLIST \G
*************************** 1. row ***************************
Id: 12
User: system user
Host:
db: NULL
Command: Connect
Time: 91
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 13
User: system user
Host:
db: madinina
Command: Connect
Time: 87
State: update
Info: INSERT INTO utilisateur VALUES (2101913295,Florian,15,
852645)

Sur le matre
Sur le serveur matre, deux types dinformations vont tre utiles : les donnes lies
aux connexions esclaves et celles du journal binaire.
SHOW SLAVE HOSTS permet dobtenir des informations (server_id, nom dhte,
port...) des esclaves connects aux matres, sous rserve que les paramtres
report_host, report_port... soient renseigns dans le fichier de configuration des
esclaves. Les renseignements concernant les threads sont disponibles avec la commande SHOW PROCESSLIST.

ASTUCE Dconnexion dun serveur esclave


Les commandes SHOW PROCESSLIST et SHOW SLAVE HOSTS ne permettent pas de sapercevoir
quun esclave vient de se dconnecter. Pour forcer MySQL mettre jour leurs informations, excutez la
commande FLUSH PRIVILEGES.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

233

SHOW GRANTS FOR peut tre galement utile notamment pour sassurer que le compte
esclave ne possde que les droits strictement ncessaires, cest--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 dtailles dans le chapitre 5,
sur les journaux de MySQL.
ATTENTION RESET MASTER peut casser la rplication
Une attention particulire doit tre porte la commande RESET MASTER qui efface tous les journaux
binaires. Elle doit tre utilise avec prcaution en cas de rplication, car le risque de la casser est lev.

Problmes lis la rplication


Les performances et la fiabilit de la rplication samliorent chaque nouvelle version. Malheureusement, vous serez confront un jour ou lautre un problme
venant dun arrt brutal de serveur ou dune erreur de manipulation. Il vous faudra
ds lors trouver lorigine du problme et le corriger en laissant les donnes dans un
tat cohrent. Dans ce paragraphe, nous allons essayer de vous donner des mthodes
et astuces afin dtablir un diagnostic pertinent dans loptique de rparer votre rplication dans les plus brefs dlais.
En cas de soucis, le premier rflexe est de consulter le journal des erreurs. La probabilit dobtenir une indication sur la nature du problme et un dbut de piste dinvestigation est plutt leve.
En cas de problmes lors du premier lancement de la rplication, vrifiez les points
suivants :
1 Le journal binaire est-il activ sur le matre ?
2 Le server-id est-il unique sur chacune des rpliques ?
3 Lutilisateur de rplication a-t-il le droit REPLICATION SLAVE. Son mot de passe
est-il correct ?
4 La connexion au serveur matre avec le compte de rplication 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 ? Vrifiez 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 vnements de
la rplication (placez log-slave-updates dans le fichier de configuration) ?

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

234

MySQL 5 Audit et optimisation

Les problmes les plus couramment rencontrs sont la plupart du temps lis aux
threads io_thread et sql_thread.

IO_THREAD stopp
Si le thread io_thread est stopp, cela peut tre d un problme de connexion avec
le matre. Vrifiez la connexion de lesclave sur le matre (nom dhte, port...), la prsence de lutilisateur de rplication, ses droits, le parefeu...
shell> tail -n1 mysql-error.err
091015 18:14:06 [ERROR] Slave I/O: error connecting to master
msandbox@127.0.0.1:23150 - retry-time: 60 retries: 86400, Error_code:
1045

Autre piste : io_thread ne trouve pas le journal binaire car il a t malencontreusement effac, corrompu... Utilisez la commande SHOW SLAVE STATUS afin de vrifier
les informations de connexions (nom de journal binaire, la bonne casse, le bon
numro). En cas de corruption du fichier, vous avez toujours la possibilit dutiliser mysqlbinlog ou votre diteur hexadcimal prfr pour essayer de rcuprer les
transactions (consultez le point PITR du chapitre 5, page 157). Cependant, il est
souvent plus simple de rinitialiser la rplication en repartant dune sauvegarde du
matre. De plus, si vous ne rcuprez pas toutes les transactions, le matre et lesclave
peuvent ne plus tre cohrents.
shell> tail -n1 mysql-error.err
091015 18:07:43 [ERROR] Error reading packet from server: File ./mysqlbin.000025 not found (Errcode: 2) ( server_errno=29)

SQL_THREAD stopp
Si le thread sql_thread est stopp, cest probablement cause dun problme de
requtes sur lesclave. SHOW SLAVE STATUS indiquera lerreur dans son champ
Last_Error. ne pas confondre avec Last_IO_Error et Last_SQL_Error qui montrent lerreur prcdente. Une requte excute sur le matre mais qui ne sexcute pas
sur lesclave peut signifier que les deux bases de donnes ne contenaient pas les mmes
donnes ou la mme structure. Le matre et lesclave ont-ils t correctement synchroniss lors de linitialisation de la rplication ? Y a-t-il eu des critures sur lesclave ?
Il est possible de rendre le serveur esclave en lecture seule grce au paramtre readLa rparation dpendra de lampleur de la tche. Vous avez la possibilit de
rparer manuellement, en excutant les requtes directement sur lesclave pour corriger la situation et en ignorant ensuite la requte qui choue avec la variable globale
only.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

235

sql_slave_skip_counter.

Cette variable ne fonctionne que si sql_thread est arrt.


Attention tout de mme, car mal utilis lesclave risque de ne pas avoir les mmes
donnes que le matre.

Ignorer une requte avec la (dangereuse) commande sql_slave_skip_counter


mysql_slave> SHOW SLAVE STATUS \G
*************************** 1. row ***************************

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;
mysql_slave> SHOW SLAVE STATUS \G
*************************** 1. row ***************************

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Last_Errno: 0
Last_Error:

DANGER Ignorer les erreurs peut provoquer des incohrences


sql_slave_skip_counter permet dignorer des requtes du journal binaire. La valeur usuelle
indiquer est 1. Il est possible de devoir excuter plusieurs fois cette commande pour ignorer plusieurs
vnements. Dans certains cas, une valeur suprieure 1 est requise. Vous trouverez plus dinformations
dans la documentation de MySQL.
B http://dev.mysql.com/doc/refman/5.1/en/set-global-sql-slave-skip-counter.html
Une alternative est de fixer slave-skip-errors=all. Dans ce cas, io_thread continuera en cas derreurs.
Cela est dangereux car le risque de trouver lesclave dans un tat incohrent est trs grand. Il est galement possible dignorer seulement un type derreur. Il suffit pour cela de remplacer le mot cl all par le
code MySQL de lerreur ignorer. Cette technique est tout aussi dconseille, les risques tant les mmes
que ceux exposs prcdemment.

L encore, la correction manuelle peut tre particulirement coteuse. Si vous tes


dans ce cas de figure, il ne vous reste alors plus qu rinitialiser la rplication en
reprenant les tapes exposes auparavant, cest--dire effectuer une sauvegarde du
serveur matre en la synchronisant avec le journal binaire, la rejouer sur lesclave, voquer la commande CHANGE MASTER TO puis lancer la rplication avec SLAVE START.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

236

MySQL 5 Audit et optimisation

Autres types de problmes, ceux lis une corruption des journaux binaires ou relais.
Ces problmes peuvent survenir aprs un arrt brutal ou tre la consquence dun
bogue (situation rencontre sur danciennes versions, lors dune charge importante de
transactions dans le journal binaire). Vous pouvez essayer de limiter les risques en configurant le matre avec les valeurs sync_binlog et innodb_flush_log_at_trx_commit
1. Lactivation de ces deux paramtres peut avoir impact non ngligeable sur les
performances ; effectuez des tests avant de les changer. Comme souvent, il vous faudra
trouver le bon compromis en testant. Dans ce cas, rinitialiser la rplication est plus
simple que dessayer de rparer en rejouant les bonnes requtes et en ignorant les mauvaises avec sql_slave_skip_counter.
Les journaux binaires ne sont pas purgs automatiquement par dfaut (consultez le
chapitre 5 traitant des journaux). Vous devez donc utiliser une procdure de surveillance de lespace disque ainsi quune procdure de suppression de ces journaux.
Dans le cas contraire, si le serveur se retrouve en manque despace disque, la base sera
fige, en attente dune libration future de place sur le disque et une erreur sera note
dans le journal des erreurs. En thorie, une fois que MySQL saperoit quil y a de
nouveau de la place, la rplication repart comme si rien ne stait pass. En pratique
le risque est grand de devoir rinitialiser la rplication.
shell> tail mysql-error.err
090723 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 secs
090723 2:33:26 [ERROR] Error writing file /usr/local/mysql/log/mysqlslow.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

En cas derreur Disk is full writing, MySQL vrifie toutes les minutes si de
lespace disque t libr et inscrit, si ce nest pas le cas, toutes les dix minutes, un
message derreur dans le journal des erreurs.
BON SAVOIR Tables temporaires et rplication
La cration de tables temporaires (CREATE TEMPORARY TABLE) nest pas recommande pour la
rplication. En effet, leur dure de vie tant la session, en cas de redmarrage de lesclave, la table existera encore sur le matre, mais plus sur lesclave.
Dautres problmes potentiels connus sont rpertoris dans la documentation de MySQL :
B http://dev.mysql.com/doc/refman/5.1/en/replication-features.html

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

237

Architectures de rplication avances


Une des forces de la rplication est sa grande modularit. Pour rpondre des
besoins aussi varis que la rpartition de la charge, la haute disponibilit et bien
dautres, vous devrez aller au-del de la simple architecture un matre, un esclave .
Nous allons vous prsenter quelques topologies de rplications parmi les plus utilises. Bien entendu, cette liste est loin dtre exhaustive, mais elle vous donnera un
aperu de ltendue des possibilits et, nous lesprons, des ides pour implmenter la
rplication votre convenance. Attention toutefois, plus votre architecture est complexe, plus son entretien et la rsolution des problmes risquent dtre coteux.
REMARQUE MySQL Cluster
MySQL Cluster est la solution haute disponibilit de MySQL et de partage de la charge pour les requtes
de lectures et dcritures. Ses principaux avantages sont :
moteur transactionnel ;
Failover automatique et rapide ;
diffrentes tches de maintenance online (sauvegarde, ajout de nuds, changement de structure) ;
synchronisation automatique des nuds sur leur rplique ;
pas de Single Point Of Failure (SPOF) ;
architecture shared nothing (chaque nud du cluster peut avoir ses propres ressources matrielles) ;
cluster faible cot.
Elle prsente les inconvnients suivants :
relativement complexe mettre en place ;
utilisation de moteur NDB qui a certaines limitations (pas dindex Fulltext, pas de cls trangres) ;
ncessit dadapter lapplication larchitecture MySQL Cluster ;
pas adapt aux requtes complexes (jointures sur plus de 3 tables, sous-requtes) ;
pas adapt aux gros volumes de donnes (les index doivent se trouver entirement en mmoire).

Dual master en actif/passif


Figure 83

Rplication circulaire
actif/passif

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

238

MySQL 5 Audit et optimisation

Les objectifs de cette architecture sont :


haute disponibilit ;
sauvegarde chaud ;
partage de la charge des requtes de lecture.
Le principe de la rplication dual master est dutiliser deux serveurs qui se rpliquent
mutuellement et forment une boucle logique. Le fonctionnement est le mme que la
rplication simple : on a donc bien un serveur matre et un serveur esclave qui rpliquent leurs donnes, du matre vers lesclave. La nuance vient du fait que lesclave est
galement matre du premier serveur. En consquence, les donnes peuvent galement tre rpliques dans lautre sens. Cependant, il ny a pas de risque quune
requte rplique boucle indfiniment dun serveur lautre, car chaque requte (ou
transaction) est prfixe par lidentifiant du serveur (server_id) du matre et ne peut
donc pas tre rplique nouveau sur ce dernier.
Cette architecture peut tre implmente en mode actif/passif ou en mode actif/actif.
Nous voquerons dans ce chapitre le premier mode ; le second sera dtaill au chapitre suivant.
Tout dabord, les notions dactif et passif sont considrer du point de vue de lapplication. Linstance MySQL active est connue et vue par lapplication alors que la passive,
elle, ne lest pas. Toutefois, dans ce cas, les deux instances de MySQL fonctionnent.
La topologie dual master sadapte bien aux applications qui ont t conues pour communiquer avec une seule instance de MySQL parce quil sagit dune configuration avec
une seule base de donnes (n clients et 1 serveur MySQL). En dautres termes, lapplication ne connat quune machine la fois. Les besoins de retoucher le code sont ici
trs faibles. La deuxime machine, la passive, joue le rle de spare, cest--dire quelle
prend le relais au cas o la premire machine ne serait plus accessible : on obtient donc
une architecture de haute disponibilit. Autre avantage, la deuxime machine peut galement servir rcuprer une partie de la charge des requtes des lectures de lapplication. Dans ce cas, ce nest plus strictement une configuration actif/passif, et cela augmente la complexit du code. Enfin, cette machine peut galement tenir le rle de
serveur de sauvegardes, ce qui permet deffectuer des sauvegardes chaud. Bien videment, en cas de besoin, rien nempche de rajouter des esclaves.
DANGER Une rplique nest pas une sauvegarde
Ne compter que sur la rplication pour mener des sauvegardes est trs risqu. En effet, comme expos
au dbut de ce chapitre, une requte dcriture malheureuse sur le matre sera rplique sur les esclaves.
De plus, la rplication ne contient aucun mcanisme qui permette de sassurer que toutes les rpliques
contiennent exactement les mmes donnes.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

239

Configuration
Le plus simple est dutiliser deux machines quasi identiques, cest-a-dire de mme
journal binaire, mme utilisateur de rplication et mme mot de passe. Le paramtre
log_slave_updates peut tre activ. Ce dernier a pour inconvnient de produire une
surcharge sur le serveur car il va journaliser les requtes rpliques. En revanche, il
apporte une scurit supplmentaire pour les donnes en gardant une copie des journaux binaires du serveur actif sur le serveur passif. Cette copie est utile pour raliser
du PITR ou des sauvegardes incrmentales (consulter le chapitre 5 sur la journalisation) sans impact sur lapplicatif. Noubliez pas le paramtre skip_slave_start.
Nous vous conseillons dactiver le mode lecture seule (read-only) sur le serveur
passif. Ce changement peut seffectuer dynamiquement avec SET GLOBAL read_only
=ON.
Disposer de deux machines de configuration si proche offre un autre avantage : lors
du passage sur le deuxime serveur, il nest pas ncessaire de repasser sur le premier
(failback) une fois que ce dernier est nouveau disponible.
Lidentifiant des serveurs (server-id) doit videmment tre unique sur chacun des
nuds.
OUTILS Supervision des serveurs
La rplication MySQL ne soccupe pas de la supervision des serveurs. Vous devez utiliser un systme qui
permettra de dtecter labsence dune machine ou du service MySQL, mais galement dinitier le basculement de lapplication du serveur lactif (qui ne rpond plus) vers le serveur passif (qui devient alors
actif). Un programme comme Pacemaker (successeur dheartbeat version 2) vous aidera grer cette
partie.
B http://clusterlabs.org/wiki/Main_Page

Exemple : switchover pour une mise jour online des serveurs MySQL
Soit A le serveur actif et B le passif.
1 Sur B, arrtez le thread io_thread (STOP SLAVE io_thread).
2 Laissez le thread sql_thread terminer la rplication. Supervisez avec SHOW SLAVE
STATUS, puis arrtez sql_thread : STOP SLAVE sql_thread.
3 Arrtez le serveur B (cest la phase la plus dlicate car si A tombe le service nest
plus assur).
4 Rcuprez 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 prcaution, en prenant les fichiers master.info et relay-log.info).
5 Mettez jour le serveur MySQL sur B.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

240

MySQL 5 Audit et optimisation

6 Assurez-vous que B est toujours paramtr pour tre un esclave (et galement un

matre).
7 Dmarrez B et vrifiez que tout sest bien pass dans le journal des erreurs.
8 Lancez la rplication avec START SLAVE et vrifiez que tout fonctionne correctement avec SHOW SLAVE STATUS (en cas de souci, reportez-vous aux informations
glanes lors de ltape 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 rcuprer le numro du journal binaire et la position.
10 Laissez le serveur B rattraper son retard au niveau de la rplication (cela peut
prendre du temps). Utilisez la fonction master_pos_wait avec comme paramtres
le numro et la position du journal binaire de A (tape 9) : SELECT
master_pos_wait(mysql-bin.xxxxxx,N);. La fonction rendra la main une fois
lesclave jour.
11 Une fois B jour, excutez 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 quil soit esclave de B et quil 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 redmarrez pas le serveur A, il est possible que vous ayez besoin
de tuer les requtes dcritures verrouilles par la commande FLUSH TABLES WITH
READ LOCK de ltape 9. Vous pourrez les voir avec SHOW PROCESSLIST. Relchez
ensuite les verrous (UNLOCK TABLES).
Dans le mme ordre dide, dautres manipulations sont possibles comme un changement de structures des tables, une modification dindex ou une optimisation dune
table volumineuse ou toute autre opration longue et coteuse. Il faut les excuter sur
le serveur passif et ensuite permuter.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

241

ALTERNATIVE Commencer par le matre


Il est parfois ncessaire de stopper le serveur actif en premier. Dans ce cas :
1. Arrtez les mises jour sur lactif.
2. Rcuprez le numro et la position du journal binaire.
3. Assurez-vous que le passif est jour.
Le passif devient actif et il peut recevoir les requtes dcritures.

Rcapitulatif
Les avantages de larchitecture dual master en actif/passif sont :
simplicit de mise en uvre, pas (ou peu) de retouche sur un code existant ;
cots faibles, ne ncessite que deux machines ;
haute disponibilit ;
partage de la charge des requtes de lecture possible ;
possibilit de redondance gographique ;
basculement manuel (switchover) dans le but deffectuer des tches online (mise
jour de versions, changement de structure, installation de patches) ;
basculement automatique coupl un systme de gestion de la haute disponibilit
(possible).
Ses inconvnients sont :
rplication asynchrone, aucune assurance que les donnes sont exactement les
mmes sur les deux instances ;
ncessit dun systme externe de gestion de la haute disponibilit ;
pas de partage de la charge possible pour les requtes dcritures.

Dual master en actif/actif


Les objectifs de cette architecture sont :
haute disponibilit ;
partage de la charge des requtes de lectures ;
sauvegarde chaud possible.
Cette architecture est quasiment identique la rplication circulaire actif/passif.
Lapplication peut rpartir ses requtes de lectures sur les deux machines mais peut
en plus y crire et cest l que le bt blesse. Une croyance populaire veut que cette
architecture permette de rpartir la charge des requtes dcritures sur les deux
machines. Ce nest malheureusement pas le cas car toutes les requtes excutes sur
une machine seront galement excutes sur lautre. Il faut donc admettre que la

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

242

MySQL 5 Audit et optimisation

rplication ne rpond tout simplement pas aux problmatiques de partages de la


charge des requtes dcritures !
Figure 84

Rplication circulaire
actif/actif

La possibilit dcrire sur les deux machines peut poser deux types de problmes au
niveau de :
la violation des contraintes dunicit des valeurs ou des objets de la base de
donnes ;
lordre dexcution des requtes.
Examinons en premier lieu la violation des contraintes dunicit. Il est possible que
les mmes objets (schmas, tables...) soient crs sur les deux serveurs avant quils ne
soient rpliqus, ce qui entrane une rupture de la rplication au moment o le thread
sql_thread excute la requte. Ce problme peut tre contourn en interdisant
votre application dexcuter des instructions CREATE SCHEMA/DATABASE/TABLE ou des
commandes DROP.
De la mme manire, les tables tant prsentes sur les deux serveurs, une mme
donne crite dans le champ ayant une contrainte dunicit, des deux cts avant
rplication, entrane elle aussi larrt du sql_thread. Le cas trivial est celui des cls
primaires avec une clause auto_increment. Ce problme peut galement tre contourn en rglant des pas dincrments diffrents, comme expliqu ci-dessous.
Extrait des sections [mysqld] des deux serveurs
[mysqld] # sur le serveur A
auto_increment_increment = 10
auto_increment_offset
= 1
[mysqld] # sur le serveur B
auto_increment_increment = 10
auto_increment_offset
= 2

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

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 nemploiera certainement pas que des cls primaires auto_increment. Vous utilisez peut-tre galement des index de type unique
et, dans ce cas, il ny a pas de solution miracle. Toutefois, une possibilit est de concevoir lapplication pour quelle crive une partie des donnes sur la machine A et
lautre partie sur la machine B. Les problmes de violations des contraintes dunicit
des valeurs ou des objets seront levs au prix dune augmentation de la complexit du
code. En revanche, en cas de panne dune des deux machines, les critures sur les
tables concernes ne pourront plus seffectuer. Un dernier point prendre en compte
galement, toujours en cas de panne dune des deux machines, est quil faut vous
assurer que le serveur qui reste soit dimensionn pour absorber la charge de lecture
de deux machines (on peut galement y ajouter la charge des requtes dcritures de
la machine en panne au cas o vous lautoriseriez).
Le problme de lordre dexcution des requtes peut tre encore plus contraignant :
avec la journalisation SBR, des requtes ne sexcutant pas dans le mme ordre sur les
deux serveurs peuvent donner des rsultats diffrents. Par exemple, soit la table T1
qui contient un n-uplet de valeur 1. Sur le serveur A, en ajoutant 5, cela donne 6.
Avant que la requte de mise jour soit rplique, une autre requte multiplie par 2
la valeur du n-uplet de T1 sur le serveur B, ce qui produit donc 2. Aprs rplication
de ces deux requtes UPDATE sur B pour la premire (5+2) et sur A pour la seconde
(6 2), une simple requte de lecture sur la table T1 renvoie les valeurs 12 et 7, respectivement les serveurs A et B. On se retrouve donc avec deux serveurs qui nont
plus les mmes donnes !
Figure 85

Problme de lordre
des requtes

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

244

MySQL 5 Audit et optimisation

Avec la journalisation RBR, les serveurs ne se retrouveront pas dans cet tat incohrent. En prenant les valeurs de lexemple prcdent, vous obtiendrez la mme valeur
sur les deux serveurs, cest--dire soit 6, soit 2 (tout dpend de la rapidit dexcution
des requtes sur chaque serveur).

Rcapitulatif
Les avantages de larchitecture dual master en actif/actif sont :
haute disponibilit ;
cots faibles, ne ncessite que deux machines ;
partage de la charge des requtes de lectures possible ;
possibilit de redondance gographique ;
basculement manuel (switchover) dans le but deffectuer des tches online (mise
jour de versions, changement de structure, installation de patches) ;
basculement automatique coupl un systme de gestion de la haute disponibilit
(possible).
Ses inconvnients sont :
problme des champs auto_increment;
problme des cls uniques ;
problme de lordre des requtes, sauf en RBR ;
pas de partage de la charge possible pour les requtes dcritures ;
des contraintes au niveau du code de lapplication ;
ncessit dun systme externe de gestion de la haute disponibilit ;
rplication asynchrone, aucune assurance que les donnes soient exactement les
mmes sur les deux instances.

Rplication circulaire (nombre de rplications > 2)


La rplication circulaire est une extension de larchitecture dual master : elle utilise n
(n>2) serveurs qui forment une boucle logique. Les contraintes sont les mmes mais
multiplies par le nombre de nuds.
Lintrt de telles architectures nest pas forcment vident sauf si les diffrentes contraintes ne vous posent pas de problmes.

Esclave relais
Les objectifs de cette architecture sont :
partage de la charge des requtes de lectures ;

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

245

Possibilit de redondance gographique.

linstar des connexions clientes, chaque esclave consomme de la mmoire sur le


matre. Cette surcharge vient du thread cr qui excute la commande Binlog Dump
charge de lire les vnements du journal binaire. De plus, dans certains cas, les
esclaves peuvent galement tre la source dune augmentation des I/O du matre (si
une multitude desclaves attaquent des vnements diffrents dans les journaux
binaires du matre).
Pour ces raisons, si vous avez besoin de beaucoup desclaves, vous ne pourrez peuttre pas tous les connecter au mme matre sous peine de voir ses performances se
dgrader. La solution consiste alors implmenter une architecture arborescente,
cest--dire un matre la racine, un pool desclaves dans les feuilles et, entre les
deux, un ou plusieurs niveaux de serveurs la fois matres et esclaves.
Larchitecture esclave relais est une variante compose dun matre en racine, un
matre/esclave (lesclave relais) en niveau intermdiaire et n esclaves dans les feuilles.
Lesclave relais permet dpargner au matre la charge des esclaves. En dautres
termes, son unique rle est de lire les donnes du matre pour que les esclaves les
rcuprent. Notez que rien ne vous empche dutiliser plusieurs esclaves relais.
Figure 86

Architecture esclave relais

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

246

MySQL 5 Audit et optimisation

De faon classique, lapplication va effectuer ses critures sur le matre, quelques lectures galement lorsque cela est ncessaire et uniquement des lectures sur les esclaves.
On voit donc que pour lapplication lesclave relais nexiste pas !
Ce petit dtail est dune grande importance pour cette topologie. En effet, la rplication offre beaucoup de liberts, notamment au niveau de la structure des tables ; il est
par exemple possible de stocker les tables en InnoDB sur le matre parce que vous aurez
un fort besoin de cohrence (intgrit rfrentielle, transactions) et de les enregistrer en
MyISAM sur lesclave, tout simplement parce ce quelles ne seront, pour lapplication,
accdes quen lecture. Sur le matre, vous pouvez envisager de crer peu dindex pour
ne pas ralentir les critures, alors que sur lesclave, toutes les combinaisons dindex pertinentes seront requises pour que les requtes de lectures soient efficaces.
Le schma nest pas le seul bnficiaire de cette souplesse ; le matre peut tre paramtr pour scuriser les critures (transactions, journaux) au dtriment de la performance alors que, sur les esclaves, ce sera le contraire, pour le serveur MySQL comme
pour le matriel.
Pour en revenir lesclave relais, y stocker des donnes ne prsente donc dintrt ni
pour lapplication, ni mme pour les esclaves, car seuls les journaux binaires les intressent. Il est donc possible dutiliser sur lesclave relais le moteur de stockage Blackhole (consultez le chapitre 3 sur les moteurs de stockage) qui, comme les autres
moteurs, stocke les vnements dans son journal binaire mais nenregistre pas les
donnes ce qui permet dconomiser des I/O.
Linconvnient est que ce type darchitecture rend tout basculement difficile du fait
de la spcialisation des diffrents nuds.

Configuration
Pour la configuration des serveurs composant larchitecture esclave relais, on retrouve
les trois familles : le matre, lesclave relais et les esclaves.
Pour le matre (M), la priorit est dassurer la cohrence et la scurit des donnes :
Le moteur de stockage par dfaut est InnoDB.
Le serveur MySQL sera paramtr pour assurer au maximum la persistance disque des donnes et des vnements du journal binaire.
Sur le matre, des cls primaires, uniques et trangres sont prsentes.
Le stockage des donnes seffectue en RAID 1+0 si possible.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

247

Extrait de la section [mysqld]


[mysqld]
default_storage_engine = InnoDB
innodb_flush_log_at_trx_commit = 1
innodb_support_xa = 1
sync_binlog = 1

Pour lesclave relais (R), le moteur de stockage par dfaut est Blackhole.
Le fichier de configuration contient entre autres :
[mysqld]
default_storage_engine = Blackhole
sync_binlog = 1
log_slave_updates
skip_slave_start
read_only

Enfin, pour les esclaves (E), la priorit est axe sur la performance.
moteur de stockage par dfaut : MyISAM ;
possibilit de rajouter des index (simple, Fulltext) ;
stockage des donnes : RAID 5.
Le fichier de configuration contient entre autres :
[mysqld]
default_storage_engine = MyISAM
sync_binlog
= 0
delay_key_write
= ON
skip_slave_start
read_only

Rcapitulatif
Les avantages de larchitecture esclave relais sont :
partage de la charge des requtes de lectures ;
possibilit de redondance gographique ;
optimisation personnalise de chacun des nuds.
Ses inconvnients sont :
cot ;
complexit ;
tats davancement des esclaves potentiellement diffrents ;
pas de partage de la charge possible pour les requtes dcritures ;

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

248

MySQL 5 Audit et optimisation

des contraintes au niveau du code de lapplication ;


basculement manuel complexe ;
pas de basculement automatique ;
rplication asynchrone, aucune assurance que les donnes soient exactement les

mmes sur les deux instances.

Partitionnement adapt au dcisionnel


Les objectifs de cette architecture sont :
base de donnes rplique et partitionne (ventuellement sur diffrents sites) ;
partage de la charge des requtes de lectures ;
possibilit de faire du dcisionnel.
Le matre est utilis de faon classique dans un environnement OLTP alors que
lesclave contient des donnes destines tre traites dans un environnement dcisionnel pour une utilisation de type (pseudo) OLAP (consultez la remarque sur la
modlisation du chapitre 6 traitant de loptimisation). Sur le matre, le schma est
donc normalis avec des tables en InnoDB, alors que sur lesclave le schma est
dnormalis en MyISAM, avec des donnes redondantes, dans des tables dagrgations alimentes par des dclencheurs (triggers) et des procdures stockes (en plus
des tables rpliques). Pour ne pas pnaliser les requtes de lectures sur les esclaves
cause des verrous en criture niveau table, les donnes ne sont pas rpliques en
temps rel, mais quune fois par jour, la nuit durant les heures de fermeture des
bureaux. De plus seules les donnes de type A sont rpliques sur le site A ; mme
principe pour le site B.
Figure 87

Architecture dcisionnelle
partitionne

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

249

Configuration
Sur le matre, la configuration est la suivante :
Le moteur de stockage par dfaut est InnoDB.
Le serveur MySQL sera paramtr pour assurer au maximum la persistance disque des donnes et des vnements du journal binaire.
Des cls primaires, uniques et trangres sont prsentes.
Le stockage des donnes seffectue en RAID 1+0 si possible.
Le fichier de configuration contient entre autres :
[mysqld]
default_storage_engine
innodb_flush_log_at_trx_commit = 1
innodb_support_xa
= 1
sync_binlog
= 1

= InnoDB

Sur lesclave :
Moteur de stockage par dfaut : MyISAM.
Ajout dindex pertinents (simple, Fulltext...).
Seules les donnes utiles sont rpliques grce la directive replicate_wild_do_table.
Stockage des donnes : RAID 5.
Le fichier de configuration contient entre autres :
[mysqld]
replicate_wild_do_table = A.%
default_storage_engine
= MyISAM
sync_binlog
= 0
delay_key_write
= ON
skip_slave_start
read_only

Mme principe pour le deuxime esclave avec replicate_wild_do_table=B.%


Pour le dmarrage et larrt de la rplication, utilisez
[io_thread|sql_thread].

START

SLAVE

STOP

SLAVE

Pour disposer dune haute disponibilit, il est possible dajouter un serveur pour
constituer un dual master.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

250

MySQL 5 Audit et optimisation

Rcapitulatif
Les avantages de larchitecture partitionne sont pour le dcisionnel :
partage de la charge des requtes de lectures ;
partitionnement des donnes ;
possibilit de rplication sur diffrents sites ;
possibilit de faire du dcisionnel.
Ses inconvnients sont :
pas de dimensionnement pour les requtes dcritures ;
des contraintes au niveau du code de lapplication ;
complexit de mise en uvre ;
rplication asynchrone, aucune assurance que les donnes soient exactement les
mmes sur les deux instances.

Bonnes pratiques
Voici les principaux paramtres auxquels vous devez prter attention. La configuration idale nexistant pas, validez-les sur les serveurs avant la mise en production.
Nommez de faon explicite les fichiers ncessaires la rplication
log_bin = mysql-bin
log_bin_index = mysql-bin.index
relay_log = mysql-relay-bin
relay_log_index = mysql-relay-bin.index

Ne configurez pas la rplication dans le fichier de configuration. Cette faon de procder est obsolte et disparatra dans les prochaines versions de MySQL. Utilisez la
commande CHANGE MASTER TO.
Sur le matre, on se focalise en rgle gnrale plutt sur la scurit que sur la performance.
: crit dans le log binaire chaque fois quune transaction est valide.
Cela diminue le risque de perte de donnes en cas darrt brutal mais augmente les
accs au disque, ce qui affecte les performances.

sync_binlog = 1

Pour les tables MyISAM : delay_key_write


disque chaque requte dcriture OFF.

= OFF (ou ON):

crit les index sur le

Pour les tables InnoDB :


innodb_flush_log_at_trx_commit = 1 : crit sur le disque chaque transaction valide ;
innodb_support_xa = 1 : synchronise le log binaire avec les donnes.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

La rplication MySQL
CHAPITRE 8

251

Sur lesclave, on se focalise souvent sur la performance plutt que sur la scurit :
sync_binlog = 0 (ou 1).
Pour les tables MyISAM :
delay_key_write = ON

Pour les tables InnoDB :


innodb_flush_log_at_trx_commit = 2
innodb_support_xa = 0

skip_slave_start : empche la rplication de redmarrer automatiquement.


read_only : empche les critures sur lesclave (sauf pour lutilisateur root ou

celui possdant le droit SUPER).


Figure 88

Architecture de sharding
rplication

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

252

MySQL 5 Audit et optimisation

SAVOIR Le sharding
La rplication ne permet pas de dimensionner sa plate-forme pour pouvoir rpondre une volution de
la charge des requtes dcritures. Cela peut tre un inconvnient majeur dans certaines architectures o
la volumtrie des donnes est trs importante avec (ou non) une charge de requtes galement problmatique. Si malgr les optimisations apportes la base de donnes et lajout de systmes de cache
vous arrivez aux limites des serveurs, le sharding peut tre une solution. Il consiste dcouper la base de
donnes en sous-ensembles appels shards, en gnral de taille quivalente, contenant chacun une partie des donnes. Ce partitionnement, niveau application, a pour but de permettre aux requtes de brasser des volumes de donnes de moindre importance et de diminuer les temps de traitements.
Le critre de partitionnement des shards est trs important. Cest grce lui que la rpartition des donnes sera homogne et que les gains en performances seront au rendez-vous. En gnral cest un identifiant unique comme la cl primaire.
Les principales stratgies 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 denregistrements dans la base ;
charge de la machine hte.
Les shards peuvent tre rpliqus sous la forme matre esclave(s) pour pouvoir profiter de tous les avantages de la rplication abords dans ce chapitre. Le sharding nest cependant pas la panace : il peut tre
complexe mettre en uvre en imposant des contraintes au niveau du code de lapplication pour pouvoir lire et crire les donnes dans le bon shard. Certaines informations ne peuvent (doivent) pas tre
partitionnes et devront tre soit redondantes sur chacun des shards (avec des risques pour les performances et lintgrit des donnes), soit tre centralises (risque de single point of failure (SPOF) ou
point individuel de dfaillance). Les problmes dintgrit des donnes peuvent apparatre galement
lors de la validation des transactions ou pour la sauvegarde lorsquelle est ralise sur un shard la fois.
Ces diffrents aspects sont prendre en considration dans la rflexion mener pour mettre en place
une architecture de sharding.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

9
O trouver de laide ?

Chercher une rponse ne se rsume pas interroger un moteur de recherche dans


lurgence. Il existe en effet dautres leviers actionner en cas de besoin, lorsquune
rponse plus ou moins rapide est requise ou tout simplement pour enrichir ses connaissances au fil de leau.
Fort heureusement, trouver de laide nest pas quune question durgence. Une question qui ne ncessite pas forcment un dlai de rsolution immdiat peut tout fait
trouver sa place sur un forum, par exemple. En revanche, lorsque le temps presse,
cette mme question peut tout dun coup se transformer en une vritable qute chronomtre sans piti qui puisera le sablier...
Pour viter de perdre son temps, prcieux de toute faon, nous allons vous prsenter
nos sources dinformations prfres. Elles sont nombreuses. Retenez celles qui vous
correspondent le mieux, selon votre exprience avec MySQL ou votre affinit avec
langlais. En effet, si la communaut francophone est de plus en plus prsente sur la
toile, la plupart des contenus pointus sont toujours en anglais. Il ne tient qu vous de
rejoindre nos efforts et diffuser votre tour de linformation en franais sur Internet.
LeMug.fr, lassociation franaise des utilisateurs de MySQL, fait partie de ces initiatives susceptibles de vous intresser.
Selon le degr durgence requis, les voies emprunter sont diffrentes, voici notre
slection, parcourir selon le temps dont vous disposez.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

254

MySQL 5 Audit et optimisation

Trouver de laide en urgence


Les ressources internes
Si vous tes le seul dans votre entreprise manipuler les bases de donnes MySQL
ou dtenir les connaissances ncessaires leur fonctionnement, passez au paragraphe suivant... Cependant, il existe peut-tre dans votre service ou ailleurs
quelquun susceptible de vous aider. En effet, selon la taille et lorganisation de votre
socit, il est possible quune cellule bases de donnes (pas forcment ddie
MySQL) soit en place ; le tout est de le savoir, ou de la joindre. Difficile par exemple
dobtenir une rponse immdiate si ce groupe de personnes se trouve dans un autre
pays... Dcalage horaire, disponibilit, autant dobstacles synonymes de dlai supplmentaire pour obtenir la rponse que vous cherchez.
Prenez les devants et demandez autour de vous si une telle cellule serait un jour susceptible de vous aider en pareille situation.

Les ressources externes


Nous ne dtaillerons pas les nombreuses formules offertes par chaque organisme proposant des solutions de support, de conseil, ou de formation autour de MySQL ;
cependant, les points dentre vers celles-ci seront indiqus.

Les moteurs de recherche


Imbattable au niveau prix, il va de soi que le moteur de recherche est videmment un
point dentre incontournable tester avant toute chose. Soumettre le numro de
lerreur rencontre, saisir le message derreur entour de guillemets, font partie des
gestes tenter. Blogs, site de MySQL lui-mme, interface de gestion des bugs
(MySQL toujours), etc., les points de chute sont nombreux... Et anglophones la plupart du temps. Aussi, nhsitez pas formuler votre question en anglais si la version
franaise de celle-ci choue.
Pensez galement utiliser les moteurs de recherche propres un blog ou celui dun
site Internet tel que http://www.mysql.com ou http://planet.mysql.com/ sans oublier sa dclinaison franaise bien sr : http://fr.planet.mysql.com/.

Le support officiel MySQL


Ltendue de la gamme propose par MySQL est trs vaste. En ce qui concerne
lurgence, loffre de support (http://www.mysql.com/support/) est celle qui convient notre

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

O trouver de laide ?
CHAPITRE 9

255

catgorie. Il sagit ici dobtenir le plus rapidement possible un ingnieur support


capable de diagnostiquer le problme et de le rsoudre. Les possibilits offertes par
cette formule sont disponibles sur le site. Certaines options vous permettent de disposer dun support annuel dot dun temps de rponse garanti et dun nombre illimit de questions dont vous dfinissez le caractre durgence.
Nous avons personnellement eu loccasion de tester avec satisfaction le support distance ainsi que le conseil sur site de MySQL.

Les organismes externes


Plusieurs compagnies prives proposent elles aussi du support MySQL. Les plus
connues sont celles dj cites 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 proposs afin de
trouver celle qui convient vos besoins. Peut-tre avez-vous dj un administrateur
MySQL en interne ? Inutile donc den louer un distance ; en revanche souscrire une
formule de support en cas de coup dur ou dabsence de votre DBA peut savrer utile.
Ces socits de conseil proposent en gnral un numro durgence bien visible sur
leur page daccueil. Le support seffectuera principalement (pour ne pas dire exclusivement) en anglais.
Alternative franaise la langue de Shakespeare, Capdata (http://www.capdata.fr) dispose
de comptences en interne ddies MySQL. Il existe galement dautres SSII proposant des offres tournes vers MySQL. La plupart des grands groupes semblent
possder des comptences MySQL en interne. Attention toutefois ces socits
gnralistes : les comptences purement MySQL y sont relativement rares mais
plutt orientes Oracle ou SQL Server.
Nous vous conseillons, lorsque cela est possible, de rencontrer les consultants susceptibles dtre vos futurs interlocuteurs en cas durgence. Mieux vaut tre pointilleux
pendant les entretiens afin dviter les mauvaises surprises le jour o lurgence sonnera votre porte. Cela est dautant plus vrai que du fait de leur raret aujourdhui,
les comptences MySQL reposent parfois sur un tout petit nombre de
collaborateurs ; il suffit parfois quun seul bon lment quitte le navire pour que le
niveau gnral sen ressente.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

256

MySQL 5 Audit et optimisation

Trouver de laide hors contexte durgence


Offres de surveillance distance, possibilit de dbogage ou dinstallation de versions
le tout par un administrateur de bases de donnes lou pour loccasion, tout cela est
possible. Les organismes susceptibles doffrir ce type de services sont les mmes que
ceux offrant du dpannage durgence.
MySQL, l encore, dispose dune offre de conseil trs riche, http://www.mysql.com/
consulting/, et il est possible de rserver un consultant sur site quelques jours le temps
dun audit, dune sance doptimisation ou dune opration de maintenance dlicate
que vous ne souhaitez pas effectuer en interne.
Il nest pas toujours ncessaire davoir un consultant sur place : cest pourquoi les
offres distance concernant ce type de service ont un sens. L encore, outre MySQL,
comparez les diffrentes formules des socits cites prcdemment (Percona,
Pythian Group, Open Query, Capdata...), elles proposent toutes ce genre de services.

Formations
Nous ne lavons pas encore voqu jusqu maintenant mais il est galement possible
de se former MySQL par le biais de formations, quelles soient organises par
MySQL ou non. Si la maison mre possde bien videmment une offre ddie, http://
www.mysql.com/training/, cest galement le cas dorganismes externes comme Alter Way
Formation (http://www.anaska.com/formation-mysql.php) qui disposent de diffrents cursus
officiels et en franais. Dautres organismes ne devraient pas manquer dapparatre
sous les termes Formations MySQL sur un moteur de recherche...

O poser votre question ?


Une question, mme dmunie de tout caractre durgence, mrite une rponse.
Lorsque le temps nest plus (vraiment) le critre numro un de votre recherche, il est
possible de choisir dautres voies que celles voques prcdemment. Nous partons
du principe que vous navez pas trouv de rponse suffisamment prcise auprs dun
moteur de recherche.

Lassociation LeMug
Nous avons fond LeMug.fr, le MySQL User Group France (http://www.lemug.fr) afin
que tous les utilisateurs francophones de MySQL se retrouvent et puissent changer
leurs questions et retours dexprience dans un mme lieu.
Nous sommes tous susceptibles dapporter une rponse quelquun ou de poser une
question lensemble de la liste. Nhsitez pas nous rejoindre, cette liste constitue un

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

O trouver de laide ?
CHAPITRE 9

257

moyen rapide et fiable dobtenir de linformation prcise, en franais bien sr. Le forum
du site est gratuit ; cependant laccs la liste de diffusion ncessite une inscription.
Ladhsion annuelle est fixe ce jour 20 euros, cotisation utilise pour le fonctionnement de lassociation et lorganisation dvnements.

Les blogs
Nous dtaillons nos blogs prfrs dans la section Aller plus loin et enrichir ses
connaissances . Cependant, si votre question est assez proche dun thme voqu
par un auteur dun de ces blogs, pourquoi ne pas publier votre question par le biais
dun commentaire ? condition que celle-ci soit relative au billet principal, lauteur
de larticle ou un autre lecteur est susceptible de vous venir en aide.

Les forums et mailing-lists MySQL officiels


Le site officiel de MySQL hberge plusieurs forums consacrs diffrents thmes.
Moteurs de stockage, rplication, performance, outils, etc., les sujets sont nombreux.
Attention au temps de rponse cependant ; les thmes les plus populaires ne sont pas trop
mal lotis, mais pour peu que vous vous intressiez quelque chose de plus exotique...
Autre aspect prendre en compte sur les forums en gnral : nimporte qui est susceptible de vous rpondre. Les forums de MySQL ne sont pas les plus mal frquents, bien sr, mais si votre question se trouve dans un forum peu frquent, le
poids de chaque rponse a dautant plus dimportance. Veillez donc ne pas tout
prendre pour argent comptant.
Ladresse de la mailing-list est : http://lists.mysql.com/.

Aller plus loin et enrichir ses connaissances


Parcourir rapidement les dernires mises jour des blogs MySQL de sa slection
devrait faire partie des tches quotidiennes de ladministrateur de bases de donnes.
Cette technique est le meilleur moyen de rester inform de lactualit gnrale de
MySQL mais galement daborder des points trs techniques selon les blogs parcourus. Voici notre slection des meilleurs sites ou blogs pour continuer apprendre
jour aprs jour.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

258

MySQL 5 Audit et optimisation

La blogosphre de la communaut
Point dentre incontournable de la communaut MySQL, le site http://planet.mysql.com.
Il rfrence les auteurs de blogs MySQL selon leur langue. La dclinaison franaise
de ce portail, http://fr.planet.mysql.com/, est porter au crdit dun des auteurs de cet
ouvrage, Pascal Borghino, par ailleurs galement prsident de lassociation LeMug.
Si vous ne devez retenir quune adresse de notre slection, retenez celle de http://
Les plus grands experts de MySQL y sont rfrencs aux cts
dautres administrateurs partageant leurs expriences autour de MySQL. Si vous
avez du contenu intressant partager, inscrivez-vous sur le portail.

planet.mysql.com.

Voici notre slection concernant ce portail.


Tableau 91 Slection franaise sur planet fr

Auteur(s)

Adresse

Pascal Borghino Yahoo!


Arnaud Gadal Virgin Mobile
Stphane Combaudon Orange

http://www.dbnewz.com

Olivier Dasini - Orange Business Services

http://dasini.net/blog/

Christophe hello Villeneuve - Alterway

http://www.nexen.net/

Tableau 92 Slection 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/

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

O trouver de laide ?
CHAPITRE 9

259

Les sminaires web


Les webinars sont de courts exposs (une heure environ, et parfois en franais !) consacrs ltude ou la prsentation dun thme spcifique. Alliant image et son, cette
formule est plus vivante quun simple document et permet dtre consulte
nimporte quel moment (http://www.mysql.com/news-and-events/on-demand-webinars/).

Outils et sources de MySQL


Le site http://forge.mysql.com/ tente de centraliser les initiatives, outils et scripts autour de
MySQL. Avant de rinventer la roue, prenez le temps de le consulter.
noter que Percona propose ses adaptations et outils ladresse suivante https://
launchpad.net/percona-innodb. Il sagit des patches, de loutil de backup Percona-XtraBackup
et de leur propre moteur de recherche bas sur le plug-in InnoDB : Percona-XtraDB.
En ce qui concerne les sources de MySQL ou les dernires versions, vous allez devoir
utiliser 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 confrence MySQL
Grande messe annuelle de MySQL, celle-ci se joue depuis quelques annes en Californie, Santa Clara. picentre de toute lactualit MySQL pour quelques jours,
cest le lieu frquenter si vous tes disponible (et motiv !) au mois davril.
Le programme se trouve sur le site consacr la confrence, http://www.mysqlconf.com.
Outre le programme, ce site a une fonctionnalit essentielle pour nous tous : il
archive le contenu de la plupart des prsentations de la confrence prcdente. Le
contenu disponible est donc une mine dor exploiter ladresse suivante (exemple
pour la confrence 2009) : http://www.mysqlconf.com/mysql2009/public/schedule/proceedings.
ne manquer sous aucun prtexte...
Il existe en Europe une confrence similaire, bien que trs allge en termes de contenu, qui na pas lieu tous les ans. La dernire date de 2008.
Un des objectifs de lassociation LeMug est dorganiser une grande confrence
annuelle autour de MySQL.
On trouve cependant des sessions MySQL lors des runions AFUP (Association
franaise des utilisateurs de PHP) avec notamment la venue de Monty Widenius
rcemment (novembre 2009) pour loccasion.

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

260

MySQL 5 Audit et optimisation

Les certifications
Opportunit den apprendre davantage, obligation professionnelle pour dautres, les
certifications divisent en gnral. Inutiles ou au contraire acclrateurs de carrire, les
avis sont trs partags. Si ce domaine vous intresse, ce billet sur lun de nos blogs
relate le passage des certifications dveloppeurs, DBA et Cluster :
B http://www.dbnewz.com/2008/06/13/

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Index
A
Aborted_clients, variable 99, 198
Aborted_connects, variable 99, 198
ACID (atomicit, cohrence, isolation,
durabilit) 59, 60, 204
agrgation 166
ALL, type explain 183
ALTER TABLE, commande 13, 66, 68
ANALYZE TABLE, commande 15, 66, 182
ARCHIVE, moteur 72
avg_row_length, variable 68

B
B+tree, index 175
BBU (Battery Backed Unit) 42
BBWC (Battery-Back Write Cache) 19, 38, 42
benchmark 25, 131
bind-adress, variable 6
binlog 4
binlog_format
MIXED 157
ROW 157
STATEMENT 157
variable 157
binlog-ignore-db, variable 224, 227
Blackhole, moteur 73
BLOB Streaming Engine (MyBS), moteur 76
BLOB, type 67, 196
blog, aide 257
blogosphre, aide 258
Bonnie++, outil 132
B-tree, index 58, 72, 173

C
capacity planning 136
cat, Unix 16, 120

certification, aide 260


CHANGE MASTER TO, commande 226
char, type 67, 167
CHECK TABLE, commande 15
cl
trangre 58, 106
primaire 146
cur 25
cohrence 118
Com_select, variable 92
commande
ALTER TABLE 13
ANALYZE TABLE 15
CHECK TABLE 15
DROP 13
EXPLAIN 11
GRANT 9
OPTIMIZE TABLE 15
REPAIR TABLE 4
ROLLBACK 13
SET 12
SHOW FULL PROCESSLIST 4
COMMIT, commande 40, 57, 61, 115
concurrent_insert, variable 206
confrence, aide 259
Connections, variable 197
CONST, type explain 184
contrainte 58
crash recovery 147
CREATE TABLE, commande 38
Created_tmp_disk_tables, variable 90, 196
Created_tmp_files, variable 195
Created_tmp_tables, variable 90, 196, 201
CROSS JOIN, jointure 172
CSV (Comma Separated Value), moteur 74

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

MySQL 5 Audit et optimisation

262
D

data_free, variable 69
datawarehouse 77
DDL (Data Definition Language) 54, 101
deadlock 104, 107
delay_key_write, variable 65, 250
DELETE, commande 152
df -kh, Unix 3, 122
DISABLE KEYS, commande 192
disk seek 115
dmesg, Unix 121
DML (Data Manipulation Language) 101
droits des utilisateurs 203
DROP, commande 13
dtrace, Unix 127
dual master 237
actif/actif 241
actif/passif 237
duplicate entry 147

E
ENABLE KEYS, commande 192
EQ_REF, type explain 184
esclave (slave) 225
event scheduler 147
Example, moteur 73
Exec_Master_Log_Pos, variable 230
expire_logs_days, variable 156
EXPLAIN, commande 11, 151, 177, 182, 212

F
Falcon, moteur 60, 73
Federated, moteur 73
fichier
MYD 4
MYI 4
file, privilge 204
filefrag, Unix 127
fincore, Unix 127
FLUSH HOSTS, commande 99
FLUSH LOGS, commande 142
FLUSH QUERY CACHE, commande 210
FLUSH TABLES WITH READ LOCK,
commande 119, 223

FLUSH TABLES, commande 210


FORCE INDEX, commande 186
FOREIGN_KEY_CHECKS, commande 192
formation, aide 256
forum, aide 257
fsync, Unix 40, 43
Fulltext, index 58, 67, 174

G
general_log_file, variable 148
GIS, index 67, 180
GRANT, commande 8, 9, 203, 222
GROUP BY, commande 195

H
Handler_read_first, variable 199
Handler_read_key, variable 199
Handler_read_next, variable 199
hash join, algorithme 172
hash, index 58, 72, 177
HEAP, moteur 71
hints 104
htop, Unix 3

I
IBMDB2I, moteur 74
IGNORE INDEX, commande 186
index 58, 172
couvrant (covering) 190
prfixe 190
INDEX, type explain 184
INDEX_MERGE, type explain 184
information_schema 21, 50, 113
INNER JOIN, jointure 170
InnoDB
ib_logfile, fichier 63
ibdata, fichier 62
iblog, fichier 62
idb, fichier 62
moteur 7, 19, 25, 49, 58, 60, 82, 143, 176, 204
undo log, fichier 62
innodb_additional_mem_pool_size, variable 205
innodb_buffer_pool_pages_free, variable 97
innodb_buffer_pool_read_requests, variable 98,
112

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Index

innodb_buffer_pool_reads, variable 98, 112


innodb_buffer_pool_size, variable 31, 46, 82
innodb_buffer_size, variable 145
innodb_data_file_path, variable 143
innodb_file_per_table, variable 62
innodb_flush_log_at_trx_commit, variable 40,
205, 236
innodb_flush_method, variable 43, 205
innodb_log_buffer_size, variable 204
innodb_log_file_size, variable 143, 204
innodb_log_files_in_group, variable 204
innodb_support_xa, variable 250
innodb_thread_concurrency, variable 29, 106,
113
innotop, outil 83, 131
INSERT DELAYED, commande 95
INSERT, commande 95
insert_method, variable 70
INSTALL PLUGIN, commande 53
iostat, Unix 3, 16, 83, 124

J
join_buffer_size, variable 196
jointure 169
journal 141
binaire (binlog) 141, 155
erreur 141
gnral 141, 153
requte lente (slowlog) 141, 148

K
key_buffer_size, variable 24, 31, 46, 84, 93, 145,
205
key_read_request, variable 93
key_read_requests, variable 85
key_reads, variable 85, 93
Kickfire, moteur 77

L
Last_Error, variable 230
LEFT OUTER JOIN, jointure 170
LeMug.fr, aide 253
LOAD DATA INFILE, commande 192
log binaire 4
log_buffer, variable 40

263

log_output, variable 152


log_queries_not_using_indexes, variable 149
log_slave_updates, variable 227
log-bin, variable 222
log-slow-admin-statements, variable 149
long_query_time, variable 10, 149
lshw, outil 121
LVM (Logical Volume Management) 117
lvs, Unix 122

M
Maatkit, outil 83, 131, 186
mailing-list, aide 257
Maria, moteur 75
MASTER_HOST, variable 225
MASTER_LOG_FILE, variable 225, 230
MASTER_LOG_POS, variable 225
MASTER_PASSWORD, variable 225
MASTER_PORT, variable 225
MASTER_USER, variable 225
max_connections, variable 23, 88
max_heap_table_size, variable 46, 72, 90, 196,
207
max_rows, variable 68
MCD (modle conceptuel de donnes) 164
Mdbtools, moteur 76
megacli, Unix 123
memcached 9
MEMORY, moteur 46, 71, 207
merge join, algorithme 172
MERGE, moteur 69
mtadonnes 56
min_examined_row_limit, variable 149
MLD (modle logique de donnes) 164
moteur 49
InnoDB 7
MyISAM 7
moteurs de recherche, aide 254
mount, Unix 122
MPD (modle physique de donnes) 164
mpstat, Unix 124
mutex 106
MVCC (Multi Version Concurrency
Control) 60, 75, 109, 209

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

MySQL 5 Audit et optimisation

264

my.cnf 15, 23, 46, 82


MyISAM
frm, fichier 64
myd, fichier 4, 64
myi, fichier 4, 64
MyISAM, moteur 7, 49, 63, 69, 92, 148, 174, 205
myisam_recover, option 147
myisamchk, outil 65, 66, 84
myisampack, outil 68
mysql 84
MySQL Administrator, outil 96
mysql_slow_log_filter, outil 151
mysql_slow_log_parser, outil 151
mysqladmin, outil 82, 84
mysqlcheck, outil 15, 65
mysqld 95
mysqld_safe 143
mysqldump, outil 225
mysqldumpslow, outil 10, 150
mysqlhotcopy, outil 65, 118
mysqlimport, outil 192
mysqlreport, outil 83, 96, 130
mysqlsla, outil 10, 151
mysqlslap, outil 189
MySQLTuner, outil 127
mytop, outil 83, 131

opened_tables, variable 87, 197


oprofile, Unix 127
optimiseur 167, 181
cost based 182
rule based 182
OPTIMIZE TABLE, commande 15, 65
option USE_FRM 4
ORDER BY, commande 195, 199
organisme externe, aide 255
outil 15
mysqldumpslow 10
mysqlsla 10

P
partition
HASH 212, 214
KEY 212, 214
LIST 212, 214
RANGE 212, 213
partitionnement 211
PARTITIONS, variable 212
PBXT, moteur 19, 60, 75
PITR (Point In Time Recovery) 160, 239
PROCEDURE ANALYSE, commande 21, 168
produit cartsien, jointure 171
PURGE BINARY LOGS, commande 156
pvs, Unix 122

NDB, moteur 74
nested loop, algorithme 172
netstat, Unix 124
null 167
NUMA, architecture 25

O
O_DIRECT 43
OLAP (Online Analytical Processing) 28, 33,
167
OLTP (Online Transaction Processing) 28, 33,
167
open_files, variable 87
open_table_definitions, variable 197
open_tables, variable 87, 197
opened_table_definitions, variable 197

Qcache_free_blocks, variable 210


Qcache_free_memory, variable 92, 210
Qcache_hits, variable 92, 210
Qcache_inserts, variable 210
Qcache_lowmem_prunes, variable 92, 210
Qcache_not_cached, variable 210
Qcache_queries_in_cache, variable 92, 210
Qcache_total_blocks, variable 210
query cache 9, 207
query_cache_size, variable 92, 210
query_cache_type, variable 210

R
RAID 34, 36
ReadAheadNone 123
write-back 123

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

Index

write-through 123
random 33
RANGE, type explain 184
READ LOCK, commande 66
read_buffer_size, variable 195
Read_Master_Log_Pos, variable 230
read_only, variable 226
read_rnd_buffer_size, variable 195
REF, type explain 184
REF_OR_NULL, type explain 184
Relay_Master_Log_File, variable 230
REPAIR TABLE, commande 4, 65
replicate-do-db, variable 227
rplication 146, 217
asynchrone 218
basculement automatique 220
binlog 4
circulaire 244
dcisionnel 220
dimensionnement horizontal 219
I/O 146
master 146
master.info, fichier 221
master-slave 219
partition 248
redondance gographique 220
relais 244
relay-log.info, fichier 221
row based 12
sauvegarde chaud 219
semi-synchronous 218
slave 146
SQL, 146
statement based 12
REPLICATION SLAVE, commande 221
RESET MASTER, commande 156
RESET QUERY CACHE, commande 92, 210
RESET SLAVE, commande 228
Rethinkdb, moteur 78
RIGHT OUTER JOIN, jointure 171
ROLLBACK, commande 13, 57, 61, 115
row based 12
row_format, variable 69

265

S
scaling 22
SELECT, commande 95, 151
select_full_join, variable 96
smaphore 105
sminaire web, aide 259
sequential 33
server-id, variable 222
SET GLOBAL, commande 150, 152
SET, commande 12
SGBDR 164
sharding 252
SHOW BINARY LOGS, commande 156
SHOW BINLOG EVENTS IN,
commande 157
SHOW CREATE TABLE, commande 56
SHOW ENGINE INNODB STATUS,
commande 104
SHOW ENGINES, commande 51
SHOW FULL PROCESSLIST, commande 4,
16, 21
SHOW GLOBAL STATUS, commande 16, 82,
85
SHOW GLOBAL VARIABLES,
commande 82, 85, 142
SHOW GRANTS, commande 99, 223
SHOW INNODB STATUS, commande 16, 83
SHOW MASTER STATUS, commande 156,
223, 229
SHOW PLUGINS, commande 54
SHOW PROCESSLIST, commande 232
SHOW SESSION STATUS, commande 182
SHOW SLAVE HOSTS, commande 232
SHOW SLAVE STATUS, commande 100, 229,
231
SHOW TABLE STATUS, commande 56, 68
SHOW TABLES, commande 224
SHOW VARIABLES, commande 53
skip-name-resolve, variable 8, 204
skip-networking, variable 6
skip-slave-start, variable 226
slave_compressed_protocol, variable 226
Slave_IO_Running, variable 230
Slave_IO_State, variable 230

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>

MySQL 5 Audit et optimisation

266

Slave_SQL_Running, variable 230


slave-skip-errors (variable) 12
slow_queries, variable 91
slow_query_log, variable 148
SMP, architecture 25
sort_buffer_size, variable 23, 84, 95, 195
sort_merge_passes, variable 95, 195
sort_rows, variable 201
sort_scan, variable 201
Spider, moteur 77
SQL_CACHE, commande 210
sql_log_bin, variable 156
sql_slave_skip_counter, variable 12, 235, 236
SSD (Solid State Drive) 44, 78
START SLAVE, commande 226
statement based 12
STOP SLAVE, commande 228
STRAIGHT_JOIN, jointure 172
super, privilge 5, 203, 226
support officiel MySQL, aide 254
surindexation 177
sync_binlog, variable 15, 40, 155, 236
synchronous 40
sysbench, outil 133
SYSTEM, type explain 184

T
table_cache, variable 46
table_definition_cache, variable 196
Table_locks_immediate, variable 198
Table_locks_waited, variable 97, 198
table_open_cache, variable 88
text, type 67, 196
thread 23, 27, 46, 106
thread_cache_size, variable 89, 197
threads_cached, variable 197
threads_connected, variable 88, 197
threads_created, variable 197
threads_running, variable 197
tinyint, type 167
tmp_table_size, variable 46, 72, 90, 196
TokuDB, moteur 77

top, Unix 3, 16, 83, 124


transaction 58
transactionel 118
TRUNCATE, commande 71

U
uname, Unix 120
UNINSTALL PLUGIN, commande 54
UNIQUE_CHECKS, commande 192
UNLOCK TABLES, commande 223
UPDATE, commande 27, 152
uptime, Unix 124
uptime, variable 87
usage, privilge 99
USE INDEX, commande 186
USE, commande 68, 224
use_frm (option) 4
using filesort, extra explain 184
using join buffer, extra explain 184
using temporary, extra explain 185
utf-8 168

V
varbinary, type 67
varchar, type 67
variable
bind-adress 6
bind-adress=127.0.0.1 6
long_query_time 10
skip-name-resiolve 8
skip-networking 6
slave-skip-errors 12
sql_slave_skip_counter 12
sync_binlog 15
vgs, Unix 122
vmstat, Unix 16, 83, 124

W
WRITE LOCK, commande 66

X
XtraDB, moteur 72

customer 27921 at Fri Mar 11 20:13:17 +0100 2011

Proprit de Albiri Sigue <tag.tog@gmail.com>