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!

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 ?

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.

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!

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!

http://sldn.softlayer.com/09/2009/building-the-data-warehouse/

Disponible en anglais uniquement…

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.

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.

Malgré tout, je crois en un storage engine non officiel: Percona-XtraDB. Il est basé sur le populaire engine InnoDB, mais offre de meilleures performances tout en demeurant 100% compatible à ce que InnoDB peut accomplir. On peut donc remplacer aveuglement InnoDB par XtraDB sans craindre quoi que ce soit! On pourrait ainsi dire qu’il s’agit d’un nouveau InnoDB, plus rapide et plus robuste.

Comme son nom l’indique, il est principalement développé par Percona, une entreprise pour laquelle j’ai un très grand respect. Bien qu’il soit encore jeune, j’ai confiance qu’il atteigne une maturité très rapidement. Je suis de très près son évolution et j’ai déjà élaboré quelques tests avec.

J’aimerais connaitre vos opinions sur les storages engines non officiels.

Beaucoup d’entre eux tentent de migrer de MySQL vers PostgreSQL et sont heurtés à toutes sortes de petits problèmes. Ce que j’en retiens comme conclusion, c’est que MySQL est d’abord et avant tout le SGBD de premier choix. Davantage de gens connaissent et apprennent MySQL en premier, avant de potentiellement se tourner vers d’autres solutions. Il est souvent le point de référence pour savoir si un truc va mieux ou moins bien que les autres solutions comme PostgreSQL.