News MYSQL

Ecrire un commentaire
le 13/10/2007 à 14:13
Supporter le retard de réplication
Le plus gros parasite de la réplication est le retard (replication lag) : c'est le fait que les esclaves soient en retard sur le maître. Pour certaines applications, ce n'est pas un gros problème, mais pour d'autres, comme celles qui utilisent la base de données pour stocker les sessions, c'est plus difficile à accepter.

Peter Zaitsev identifie les sources de retards sur une architecture de réplication : la charge de l'esclave (qui doit servir les lectures en plus de rattraper les écritures), les verrous (qui bloquent tous les requêtes, y compris le thread de réplication), les longues requêtes (qui ennuient tout le monde).

Au final, il est recommandé d'inclure dans l'application des systèmes qui s'adaptent à ce retard, plutôt que de faire planter l'application.

- Managing Slave Lag with MySQL Replication
Ecrire un commentaire
Note de l'auteur :

J'en fait souvent une blague quand j'en parle avec les développeurs que je rencontre, mais il semble que les imbéciles qui le font sont plus nombreux que je ne le pensais.

Au point que Sheeri Kritzer a mesuré les performances de trois situations, pour identifier la plus rapide : pour réaliser 1000 insertions, elle teste trois cas. Le premier cas fait 1000 connexions et requêtes, le deuxième fait 1 connexion et 1000 requêtes, et le dernier fait une connexion et une requête.

Si vous ne vous doutez pas de la réponse, lisez l'article...

- Making Queries 45-90 Times Faster !!
- Sheeri Kritzer
Ecrire un commentaire
InnoDB avait des soucis à supporter les auto_increment quand de nombreux processus tentaient simultanément d'utiliser cette colonne.
Heikki Turri, auteur d'InnoDB, a placé dans la RC1 de MySQL 5.1 un patch qui réduit considérablement les effets de compétition sur cette colonne.
Selon Brian Aker, c'est une raison suffisante pour utiliser InnoDB et passer dès que possible à MySQL 5.1.

- MySQL 5.1 RC, Innodb Scaling
- Nouvelle version de MySQL : 5.1.22 RC
Ecrire un commentaire
le 01/10/2007 à 21:51
Nouvelle version de MySQL : 5.1.22 RC
MySQL 5.1.22, la première version Release Candidate (Candidat à la publication) a été publiée. Son niveau de stabilité approche les standards de qualité nécessaires pour une publication officielle (GA), et elle entre dans une période intensive de recherche de bogues. On peut prévoir une publication finale dans les prochains mois.

Une nouvelle fonctionnalité : l'option innodb_autoinc_lock_mode permet de modifier le comportement de verrouillage de InnoDB

Corrections MySQL 5.1.22 : 17 bogues ont été corrigés, et notamment : NDB Cluster, InnoDB. Tous des bogues ouverts.

- MySQL
- Téléchargement MySQL 5.1
- MySQL 5.1.22
- Rapports d'erreurs et corrections
Ecrire un commentaire
le 27/09/2007 à 22:51
LIMIT est plus lent que JOIN
La clause LIMIT sert à réaliser ces barres de navigation, en découpant un résultat en plusieurs pages. Mais si elle est prodigieusement utile dans cette situation, elle est à l'origine d'un sérieux gâchis d'octets et de lignes. Pour dépasser l'utilisation traditionnelle de LIMIT, vous pouvez appeler à la rescousse les bonnes vieilles JOINTURES.

Au passage, vous verrez la conversion de LIMIT en JOIN, la création d'une table d'assistance, comment numéroter des lignes dans une table, mysqlslap, les variables MySQL, et les insertions de masse. Bonne lecture.

- Mon JOIN est plus rapide que ton LIMIT
Ecrire un commentaire
Note de l'auteur :

Je suis toujours fasciné par la communication autour des techniques d'entreprises que MySQL peut développer.
Outre la distribution mondiale des employés (300 développeurs dans 30 pays), les fêtes de Noël en ligne qui durent 24 heures, et le responsable de l'ingénierie qui "commence tôt et finit tard".

Le dernier billet en date est consacré à la rencontre de Heildelberg (magistralement organisée par Georg Richer, pourquoi ne suis-je pas étonné ?) et aux aspects nécessaires pour réussir une telle réunion. Peut-être que Pascal Borghino aura des retours lui aussi? patience...

- MySQL Heidelberg Developer Mtg: Looking back
- Competing for talent
- MySQL: Workers in 25 countries with no HQ
- How to arrange a physical meeting in a virtual organisation
- How to cope with timezones
Ecrire un commentaire
le 25/09/2007 à 20:51
Correspondance Oracle - MySQL
Il semble que de plus en plus d'administrateurs ait un pied dans les deux mondes : Oracle et MySQL. On voit fleurir les blogues d'admin MySQL qui doivent se mettre à Oracle, et réciproquement.

Le dernier billet que je viens de découvrir a mis en place le projet d'une correspondance entre les deux serveurs : c'est à dire comment résoudre dans l'autre serveur les problèmes du premier. Apache est le serveur HTTP de prédilection avec MySQL, alors que Oracle Application Server sera le choix pour Oracle.

Cet article est déjà long, mais n'est pas fini. L'auteur indique qu'il va ajouter des informations au fur et à mesure de sa propre progression, mais vous pouvez lui en soumettre d'autres.

- Looking at MySQL and Oracle
Ecrire un commentaire
le 25/09/2007 à 20:39
MySQL AB investit dans PDO
Selon Lukas Smith, MySQL AB va affecter un programmeur pour revoir le code de PDO_MySQL (le pilote MySQL de PDO pour PHP), afin de le nettoyer, d'ajouter des tests et toutes les fonctionnalités qui seront utiles. Cet effort semble se faire en plus de l'investissement actuel dans l'extension mysqlnd (mais peut-être est-ce que finalement ce seront les mêmes qui travailleront dessus ?).

De retour de la conférence développeur de MySQL, à Heidelberg, Lukas rapporte différents développements pour MySQL dans les prochains mois :
- L'optimiseur SQL va améliorer sa gestion des commandes préparées, puis des sous-requêtes
- Les sauvegardes en ligne sont prévues pour MySQL 5.2
- Les LOB seront streamés directement depuis la base de données, en HTTP (il sera plus facile de stocker ses images en base!)
- La réplication accepte des schéma de base différentes entre le maître et l'esclave

- MySQL conf notes, Frisbee and new captcha
Ecrire un commentaire
Les premiers pas d'un administrateur MySQL qui se met à Oracle.

Il y décrit plusieurs réflexes d'administrateur MySQL qui sont confrontées à une réalité OracleCela permet de mieux comprendre les différences entre les bases de données, en plus d'aider ceux qui doivent vivre dans les deux mondes.

- From MySQL to Oracle: A Few Differences
Ecrire un commentaire
Note de l'auteur :

Pour mieux comprendre les futures menaces de sécurité, prenons une grande inspiration, et jetons nous dans les "vulnérabilités de sécurité", ce qu'elles sont, comment elles sont classées, comment elles sont découvertes, comment MySQL en entend parler, ce que fait l'équipe de sécurité MySQL "MySQL Security Team", quels sont les rôles des membres de l'équipe, comment les vulnérabilités sont corrigées, comment ces corrections sont distribuées et pourquoi vous devez y porter attention.

- How MySQL Treats Security Vulnerabilities
LoadingChargement en cours