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!
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.
Jun/090
Connexion Master Slave: erreur commune
Je vois régulièrement des diagrammes d’architecture où les flèches pour la connexion du Slave / Master sont dans le mauvais sens. Il faut savoir qu’avec MySQL, c’est le Slave qui se connecte au Master pour aller chercher le binlog, et non l’inverse. Ça devrait donc donner un diagramme comme ceci:
Nov/082
MySQL 5.1 GA
MySQL 5.1 est sorti aujourd’hui en version GA (General Availability)! Certaine personne avait avancé qu’il sortirait le 6 décembre, date que j’attendais avec impatience, mais on peut se réjouir dès maintenant !
Dans les nouveaux features de MySQL 5.1, on y retrouve (en ordre de préférence)
Il y a évidement d’autres features que ceux-la, mais ce sont mes préférés. J’ai déjà commencé à me servir de l’event scheduler dans des environnements de developpement. J’ai hate de pouvoir mettre ça en pratique dans un environnement de production!
Vous pouvez donc le télécharger ici
Nov/088
64bit VS 32bit
Je croyais jusqu’à tout récemment que la majorité des serveurs étaient tous en 64bit. La presque totalité des nouveaux hardware supportent le 64bit alors pourquoi installer un OS 32bit sur une machine 64bit ? Pour moi la question ne se posait même pas tellement la réponse me semblait évidente. Hé bien j’étais loin de la réalité.
En 5 mois, j’ai été témoin de 4 personnes (amis et connaissance d’IRC) ayant installé un OS 32 bit sur des machines 64bit. On pourrait croire que ce n’est pas tellement grave, puisque de toute façon il y a peu d’application développée spécifiquement pour les 64bit, et s’ils le sont, le gain de performance est à peu près imperceptible. C’est faux, complètement faux.
Il faut être très vigilant dans le choix de l’OS qu’on installe, surtout sur une machine qui sera dédiée à MySQL. Je vais vous expliquer pourquoi avec 2 exemples.
Cas #1.
MySQL roule sur un OS 32 bits depuis déjà longtemps. Tout fonctionne à merveille, mais la charge de travail a augmenté considérablement depuis la mise en ligne, à un point où il devient nécessaire d’augmenter la RAM pour conserver une performance acceptable. C’est une décision importante, car cette modification demandera un downtime de quelques minutes, et forcement il y a quelqu’un qui perd de l’argent lorsque le serveur ne fonctionne plus. La mémoire vive est très abordable maintenant et l’équipe décide d’upgrader à 8Go de RAM.
Plusieurs d’entre vous ont probablement déjà identifié le problème. Les OS 32bit ne supportent pas plus de 4Go de RAM, théoriquement. En pratique, on plafonne souvent à 3.5Go et comme l’OS utilise de la mémoire, MySQL lui sera capable d’utiliser au mieux ~2.5Go de RAM. Les performances sont loin des résultats escomptés. De plus, pour corriger le problème, il faudra installer un OS 64bit, ce qui entraînera un second downtime plus long que le premier.
Cas #2.
Un Master roule sur un OS 32 bits, mais la machine (qui supporte le 64bit) se fait vieille et de moins en moins performante. Nous avons aussi un Slave utilisé pour les backups dans les mêmes conditions. L’équipe décide donc d’acheter une nouvelle machine très performante, avec plusieurs CPU, plusieurs Go de RAM et des disques très rapides. Évidemment on installe un OS 64bit sur la bête, car nous avons beaucoup plus que 4Go de RAM. Le plan de match est de mettre la nouvelle machine Slave de l’actuel Master, et d’inverser les rôles au moment opportun. C’est une opération qui se fait très rapidement pour minimiser le downtime. Tout se passe à merveille, le changement de serveur est un succès.
Il y a cependant un détail qui a été négligé dans cette opération. Le Master est une machine 64bit alors que les 2 slaves sont demeurés 32bit. Il n’y a rien d’incorrect dans ce procédé, mais là où ça bug, c’est qu’on fait des copies binaires des données sur un des Slave en guise de backup. S’il s’avère nécessairement d’utiliser ces backups sur le Master, il y a de fortes chances que des données soient perdues à cause des floating points.
Je n’ai pas l’infrastructure et le temps nécessaire pour effectuer mes propres tests de performance pour mesurer le réel impact d’un 32bit vs 64bit. Plusieurs personnes de renom affirment qu’il y a un avantage non-négligeable pour les applications demandant beaucoup de CPU et mémoire, comme MySQL. C’est une opinion que j’ai tendance à croire étant donné la multitude d’articles qui l’appuie. La principale raison pour utiliser un os 64 demeure la possibilité d’avoir plus de 4Go de RAM, mais s’il n’y a pas de désavantage à utiliser un 64bit, pourquoi s’en priver ?