Ne donnez pas trop de processeurs à InnoDB

Matt Yonkovit et Yves Trudeau ont mesuré l'impact du nombre de processeurs sur les performances InnoDB. Il est connu que InnoDB n'aime pas les machines à 16 coeurs, et via la commande taskset, Matt et Yves ont testé la progression des performances de 1 à 16.
Au final, il semble bien que 6 coeurs soient capables de fournir le même travail que 9. 8 coeurs est donc le maximum d'éfficacité actuellement pour un serveur MySQL sur InnoDB.

Sauvegarde MySQL sur SSH

Garry Van Burren publie une (longue) ligne de commande pour sauvegarder des bases MySQL sur un serveur distant, via SSH. mysqldump et mysql sont appelé à la rescousse, et ssh se charge du transport. Rien de difficile (hormis les 3 jeux de noms d'utilisateurs), mais une astuce pratique pour une sauvegarde.

mysql_secure_installation, utile mais non paramétrable

Je n’avais pas prévu d’écrire un billet sur mysql_secure_installation, c’est en préparant le prochain article (installation du cluster MySQL) que m’est venue l’idée d’écrire quelques lignes sur le sujet.

Ce script, présent dans le répertoire “bin” de votre installation de MySQL, a pour but de “sécuriser” votre base une fois celle-ci installée. Il vous est d’ailleurs conseillé de l’exécuter une fois mysql_install_db lancé ou à défaut de passer par mysqladmin pour au moins modifier le mot de passe associé à l’utilisateur “root”.

Lors de l’installation du cluster, je pars du principe qu’un autre serveur MySQL est susceptible de tourner sur le SQL node, je choisis donc d’opter pour …

[Lire plus]
Myosotis : proxy MySQL et PostGreSQL en Java

Les proxy SQL sont partout dans les actualités, notamment pour les bases de données Open Source. MySQL Proxy et PG-Pool sont juste deux exemples récentes. Mais voici un autre proxy que vous devez connaître : Myosotis.
Myosotis est un proyx JDBC 'client natif' pour MySQL et PostgreSQL. Nous l'avons initialement développé pour relier nos Cluster sans utiliser de pilote JDBC. Myosotis analyse la requête dans le protocole du client, et émet un appel JDBC similaire, puis il retourne le résultat au client. Comme vous pouvez le deviner, c'est écrit en Java. "

[Lire plus]
MySQL 5.1.26-rc publiée : la dernière avant la GA?

MySQL/SUN annonce la publication de MySQL 5.1.26-rc, la dernière version de la série des 5.1, et possiblement la dernière avant la publication en GA.
La liste des mises en production est courte, et de bonne augure pour la suite : le moteur FEDERATED est maintenant désactivé par défaut. 7 bogues ont été corrigés, reliés à la réplication, l'analyse de requête, InnoDB et l'Unicode.

Alertes sécurité des applications PHP et MySQL, édition 210


PHP et MySQL ne font l'objet d'aucune alerte de sécurité dans leurs versions courantes :
PHP 5.2.6 et 4.4.8; MySQL 5.0.51 (communauté) , 5.1.24-rc et 6.0.4.
Les mises à jour sont recommandées vers ces versions.



10 alertes de sécurité ont été émises cette semaine, concernant des applications suivantes :
Drupal, Gallery, Joomla, MyBB, PHP Nuke, V-webmail, Zen Cart, phpMyAdmin, vBulletin et wordpress


[Lire plus]
mysqlsla 2.0 publié

mysqlsla est un analyseur de log MySQL qui permet d'extraire les informations importantes des logs MySQL. Ces derniers stockent les requêtes brutes, et il est parfois difficile de repérer les requêtes qui sont identiques, à quelques variables ou valeurs près. mysqlsla est alors là pour ça.
Ce problème de requêtes similaire est une raison de plus pour passer aux commandes préparées de MySQL : avec les commandes préparées, la requête est dissociée des valeurs d'exécution, et le stockage dans le log MySQL devient constant : la requête d'un coté, les valeurs de l'autre. Et on peut aussi arriver au même résultat avec les variables MySQL.

Les méta-données FALCON en MySQL 6.0.5

"MySQL® 6.0.5-alpha, la dernière version de la série 6.x de MySQL est disponible au téléchargement sur les sites de SUN|MySQL.
Les méta-données (les données à propos des données), sont très importantes, notamment pour les développeurs. Dans cet article, nous verrons ce qui est nouveau dans les méta-données FALCON, en comparaison avec la version 6.0.4."

Optimiser une requête SQL

Depuis quelques temps, un serveur qui héberge quelques petits sites s’est mis à monter régulièrement en charge, sans augmentation de trafic, ni changements applicatifs. J’ai laissé traîner les choses, ne sachant pas d’où venait le souci. Il aura fallu cinq minutes de travail et l’utilisation de la commande shell top, de la directive de configuration... Read more »

Cet article Optimiser une requête SQL est apparu en premier sur EnPause.fr.

Énumérez vos champs !

On a parfois la mauvaise habitude de faire des SELECT * FROM table; Mon astuce de la semaine va tenter d’expliquer pourquoi il faudrait toujours énumérer les champs qu’on veut sélectionner, même s’il s’agit de la table au complet.

Il y a 3 raisons majeures pour lesquelles il ne faudrait JAMAIS faire de SELECT * FROM dans les requêtes d’une application:

  • La description de la table par le biais de la requête est perdue
  • Les changements de champs
  • La grosseur des champs

Description de la table

Les Q.A vont être d’accord avec moi là-dessus, il n’y a rien de mieux qu’un code avec des noms de variables et de fonctions bien choisis. Et lorsque c’est pas suffisamment explicite, les programmeurs doivent ajouter des commentaires pour aider à la compréhension du code. Les requêtes SQL ne doivent pas faire exceptions à cette règle. Supposons que vous devez …

[Lire plus]