Jan/100
L’importance des clés primaires avec mk-table-sync
J’adore Maatkit. Je m’en sers régulièrement dans toutes sortes d’occasions. Pour tous les Slaves que je configure, j’ajoute un petit script maison qui utilise mk-table-sync afin valider l’intégrité des données sur le Slave avec le Master. Ce petit script envoie un email avec les différences et les requêtes à exécuter le cas échéant.
J’ai remarqué que mk-table-sync possède certaines limitations, c’est-à-dire que le format de la table et l’encoding joue un rôle important sur la manière dont l’outil effectue ses comparaisons. Les tables sans clé primaire ou d’identifiant unique sont particulièrement problématiques, et c’est tout à fait compréhensible. Par définition, s’il n’y a pas d’identifiant unique, il est impossible d’être 100% sur que l’enregistrement #1 sur le Master correspond à l’enregistrement #1 sur le Slave. En étant limité à ce niveau, mk-table-sync préfère “croire” que l’ensemble des données sur le Slave sont erronés et propose des requêtes pour supprimer et réinsérer tous les enregistrements de la table.
Bien que je m’assure que toutes les tables possèdent des clés primaires lors de leur création, il m’est arrivé de me faire avoir. Le statement CREATE TABLE tableName SELECT * FROM tableName2 WHERE …. ; crée une table SANS index! Du coup, mon petit script s’est mis à envoyer des emails de 17Mo de requêtes SQL, ce que Thunderbird digère très mal 
La leçon est: si vous utilisez mk-table-sync, assurez-vous de TOUJOURS avoir un identifiant unique sur vos tables!
Jan/101
Resolutions Geeks de 2010
L’année 2009 a été une année chargée pour MySQL: après son achat par Sun, il passe aux mains d’Oracle. Ce dernier achat fait beaucoup jaser et plusieurs personnes s’interrogent sur l’avenir de MySQL. Je suppose que nous saurons en 2010 ce que Oracle compte faire de MySQL. Personnellement, je préfère attendre les publications officielles plutôt que de m’énerver sur les spéculations alarmistes qu’on a pu lire ces derniers mois…
De mon côté, l’année 2010 s’avère une année très mouvementée:
- Chez iWeb, je participe à un ambitieux projet qui devrait voir le jour au courant de l’été.
- Le soir et les fins de semaine, je passe la majorité de mon temps au HEC pour satisfaire les exigences de mes cours.
Malgré tout, j’ai quand même l’intention de (ce sont mes résolutions):
- Écrire sur mon blog plus régulièrement
- Être davantage présent chez les diverses communautés montréalaises et Open-Source
- Parfaire mes habiletés de ScrumMaster/Chef d’équipe
- Faire des recherches et tests plus sérieux avec Drizzle et MariaDB
Et vous, quelle sont vos résolutions geek 2010 ?
Dec/090
Retrospective du Demo Camp de Montréal
Comme plusieurs bons ScrumMasters, j’applique des principes de scrums dans ma vie quotidienne. Dans ce sens, je me permets de publier ma rétrospective du Demo Camp d’hier soir.
Dans les points négatifs à améliorer:
- Ne pas essayer de faire une présentation de 30 minutes en 10 minutes
- S’informer davantage sur la formule de présentation
- Prévoir que le Xorg de mon debian n’allait pas supporter les résolutions des mégas projecteurs
- Prévoir que simuler le crash d’une DB et la recouvrir live implique un certain nombre de risques
- Pratiquer la présentation, plus, beaucoup plus
Dans les points positifs à retenir:
- De la bière gratuite fournie par Microsoft
- Élargis mon réseau de contacts
J’ai spécialement aimé la présentation de DokDok.
Comme promis, je publie le script de backup que j’ai finalement à peine présenté. Anyway, pour les intéressés, il se trouve ici.
Nov/092
MySQL Sandbox: bravo !
J’ai souvent entendu parler de MySQL Sandbox. Pour effectuer des tests avec un Master/Slave en fin de semaine, j’ai décidé de l’essayer puisque je n’avais que mon laptop. MySQL Sandbox est un outil pour installer un ou plusieurs serveurs isolés, sans affecter les autres.
Wow! Juste Wow! MySQL Sandbox est un outil vraiment génial! J’ai pu créer une instance de MySQL Master avec 2 instances Slaves sur la même machine en moins de 1 minute! C’est le genre de tâche qui prend de 30 minutes à 1 heure lorsqu’un administrateur expérimenté le fait manuellement. MySQL Sandbox permet non seulement d’installer rapidement 1 ou plusieurs serveurs, il permet aussi d’installer des versions différentes en quelque instant !
De plus, des options prédéfinies permettent de créer un setup Master-Slave ou Master-Master automatiquement. Il vient avec des outils permettant d’effectuer des tâches d’administration complexes de manière excessivement simple. En résumé, il permet carrément de jouer avec MySQL.
Comment ça marche? On télécharge la version de MySQL qu’on souhaite installer. Ensuite, on peut
Créer une instance de MySQL:
make_sandbox /path/to/mysql-X.X.XX-osinfo.tar.gz
Créer un Master avec 2 Slaves:
make_replication_sandbox /path/to/mysql-X.X.XX-osinfo.tar.gz
Créer 4 serveurs avec une réplication circulaire (Master-Master)
make_replication_sandbox –circular=4 /path/to/mysql-X.X.XX-osinfo.tar.gz
Ces 3 commandes installent, configurent et démarrent le ou les serveurs MySQL. En quelques mots, MySQL Sandbox c’est simplicité, rapidité et fun!
Nov/092
Un bout de DBA au Career Demo Camp de Montréal
Mercredi le 2 décembre, je serai parmi les speakers au Carrer Demo Camp de Montréal. Le CDCM est un événement gratuit qui se déroule simultanement et dans les même locaux que le Microsoft Techdays de Montréal. Il est animé par mon ami Jean-Luc Sanscartier et Joey DeVilla.
Au menu, une démonstration sur une manière simple et efficace de faire des backups MySQL gratuitement.
Avis aux intéressés! Il reste encore quelques places!
Oct/090
Une belle histoire de Scaling
J’ai lu une histoire très intéressante aujourd’hui à propos de l’utilisation de MySQL chez SoftLayer. Il raconte comment ils ont atteind les limites de MySQL de 5 manières différentes avant de trouver “la” solution pour construire un datawarehouse. Une belle histoire de scaling!
http://sldn.softlayer.com/09/2009/building-the-data-warehouse/
Disponible en anglais uniquement…
Oct/090
SQL_MODE bonne ou mauvaise idée ?
MySQL est connu pour être très flexible avec la validation des données. Les conversions silencieuses ne sont pas des pratiques courantes parmi les autres SGBD. Au lieu de lancer des erreurs, MySQL lance des warnings, ce que la majorité des applications ne gèrent pas. (Est-ce que votre application fait un SHOW WARNINGS; à chaque requête?)
Néanmoins, la variable SQL_MODE permet de contrôler ce comportement. Plusieurs niveaux de validation peuvent donc être assignés, partant d’une validation quasi absente (par défaut) à une validation très stricte. Ce qui peut paraître comme une bonne affaire me parait plutôt comme une très mauvaise idée.
Le problème avec le SQL_MODE c’est que par défaut, la valeur est vide (oui oui!). Il n’y a pas de mode prédéfinie ce qui donne un comportement très souple. Plusieurs personnes ne savent pas que cette variable existe et construisent une application qui repose malheureusement sur cette souplesse. Lorsque votre application finie par en dépendre, c’est-à-dire qu’elle se comporte “normalement” avec cette absence de validation de données, vous risquez gros.
On peut insérer des dates impossibles comme le 31 février ou 0000-00-00 , des divisions par 0 dans des opérations mathématiques et des valeurs qui dépassent largement la limite possible des champs. Votre application fait peut-être tout ça, sans même que vous le sachiez! Elle ne produit aucune erreur puisque du côté de MySQL, il n’y a que des Warnings.
Imaginez le scénario: vous désirez loguer des transactions bancaires, mais un bug idiot fait que toutes les dates des transactions sont insérées avec un string quelconque, 1-janvier-2009 par exemple, ce que MySQL converti en 0000-00-00. Le champ pour stocker l’IP de la personne qui fait la transaction est un SMALLINT, tous vos IP atteignent la valeur maximum et sont convertis en 32767.
Un bon conseil: si vous débutez un nouveau projet, assurez-vous de mettre un SQL_MODE strict pour vous éviter des problèmes tôt ou tard ! Essayez-le sur une application existante pour voir comme elle réagit!
Le SQL_MODE peut être modifié par session ou globalement pour l’ensemble des usagés. Parmi les plus stricts, on retrouve
strict_trans_table: Si une valeur n’a pas pu être insérée dans une table transactionnelle sans modification, la commande est annulée. Pour une table non-transactionnelle, la commande est annulée si cela survient dans une ligne unique ou dans la première ligne d’une insertion multiple
traditional: MySQL se comporte comme un système SQL “traditionnel”. Une description simple est que ce mode “émet une erreur et non pas une alerte” lors de l’insertion d’une valeur incorrecte dans une colonne. Note : si vous utilisez un moteur de table non-transactionnel, les commandes INSERT/UPDATE s’arrêteront dès que l’erreur est repérée.
Oct/098
MySQL Query Cache
La query cache de MySQL joue un rôle important dans la performance de plusieurs sites Web. Elle a pour avantage d’être transparente, c’est-à-dire que la ou les applications qui s’en servent n’ont pas besoin d’être modifiées.
J’ai recu la semaine passée la question suivante (je résume):
Je souhaite utiliser une cache pour le menu de mon site afin de le rendre plus performant. Puisque le contenu du menu ne change pratiquement jamais, est-il plus avantageux d’utiliser APC Cache que la Query Cache de MySQL puisque la communication s’effectue selon un schéma comme:
php -> cache_apc (ram)
php -> mysql -> query_cache (ram)Je souhaite réduire au minimum les requêtes SQL exécutées.
Personnellement, j’utiliserais la cache de MySQL. Tout d’abord, il faut savoir qu’il y a une énorme différence entre les 2 caches.
MySQL Query Cache est centralisée sur le serveur MySQL, c’est-à-dire qu’elle utilise la RAM de la machine du serveur MySQL. Elle possède un mécanisme d’invalidation basique, mais efficace. L’invalidation se produit lorsque des valeurs d’une table sont en cache, et que ces valeurs sont mise à jour par une application ou manuellement par un utilisateur.
APC Cache est centralisée sur le serveur Web, c’est-à-dire qu’elle utilise la RAM disponible sur le serveur qui roule Apache et PHP (en supposant que vous utilisez Apache). Vous serez responsable d’invalider la cache lorsque nécessaire. Si quelqu’un modifie la valeur directement dans MySQL, la cache possèdera la vieille valeur jusqu’à ce qu’un processus l’invalide.
Puisque les données ne changent pratiquement jamais, je ne me casserais pas la tête à réinventer la roue. MySQL fait déjà pour vous ce que APC ferait, sans le moindre effort. De plus, il est plus ou moins vrai de dire que d’appeler la cache correspond à une requête. Oui, la string SQL est nécessairement envoyé à MySQL, mais lorsque celui-ci la reçoit et valide que cette requête est cachée, il retourne immédiatement le résultat sans rien “processer”. C’est comme ça que fonctionne APC aussi, il lui faut un identifiant unique pour associer le résultat, tout comme fait MySQL avec le HASH de la requête.
Les caches (peu importe laquelle) sont tout aussi efficaces avec une petite requête qui consomme peu de ressource qu’avec une grosse qui en demande beaucoup. Il est donc plus avantageux de cacher les processus lourds que les légers.
Ce qu’il faut surtout se soucier lorsqu’on utilise une cache, c’est comment et à quelle fréquence il faut l’invalider. Lorsque la Query Cache de MySQL est activée, le processus de cacher les résultats et de les invalider s’effectue tout seul de manière invisible. Ainsi, d’autres requêtes que vous ne soupçonnez même pas bénéficient de la cache. À l’inverse, il faut modifier le code pour chaque requête que vous souhaitez cacher avec APC.