dbnewz

Je viens de lire récemment Sécurité PHP 5 et MySQL, écrit par Damien Seguy et Philippe Gamache. J’ai évidement commencé par les parties que me tiennent à coeur, MySQL et en particulier:

• Risques liés aux bases de données
• Vulnérabilités des base de données
• Mesures de sécurité pour MySQL

Je vous le conseille, vous trouverez un condensé de tout ce qu’il faut savoir à ce sujet pour protéger vos bases de données. Merci messieurs!
Je vais m’attaquer à la partie PHP

J’ai eu un petit problème sympa à résoudre. En résumé, nous avons 2 tables t1 et t2.

mysql> select * from t1;
+——+——+
| id | name |
+——+——+
| 1 | a |
| 2 | b |
| 3 | ab |
| 4 | bc |
+——+——+

mysql> select * from t2;
+————–+———+
| dependent_id | base_id |
+————–+———+
| 1 | 1 |
| 3 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 3 | 2 |
| 4 | 2 |
+————–+———+

Nous ouvrons une transaction (T1) et nous exécutons la requête suivante.

SELECT * FROM t1 JOIN t2 WHERE t1.id=t2.dependent_id AND t2.base_id=1 FOR UPDATE;

+——+——+————–+———+
| id | name | dependent_id | base_id |
+——+——+————–+———+
| 1 | a | 1 | 1 |
| 3 | ab | 3 | 1 |
+——+——+————–+———+

Nous ouvrons une transaction (T2) et nous exécutons la requête suivante.

SELECT * FROM roles WHERE id=2 FOR UPDATE;

Et alors que les 2 requêtes ne sont pas sensées travailler sur les même lignes, T2 attend la fin de T1? Comment est ce possible?

Pour comprendre vous devez analyser le plan d’exécution.

mysql> explain SELECT * FROM t1 JOIN t2 WHERE t1.id=t2.dependent_id AND t2.base_id=1 FOR UPDATE;

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
| 1 | SIMPLE | t2 | ALL | NULL | NULL | NULL | NULL | 7 | Using where |
| 1 | SIMPLE | t1 | ALL | PRIMARY | NULL | NULL | NULL | 3 | Using where |

Voila l’erreur, MySQL fait un full table scan (type ALL) pour exécuter cette requête et ainsi bloque toutes les lignes. T2 est ainsi obliger d’attendre la fin de T1. Pourquoi?

Ayant seulement 4 entrées dans cette table, l’optimiseur de MySQL préfère un faire un full table scan plutot qu’utiliser un index. De la j’ ai inséré d’autre entrée dans la table t1, et le plan d’exécution a changé.

| 1 | SIMPLE | t2 | ALL | NULL | NULL | NULL | NULL | 217 | Using where |
| 1 | SIMPLE | t1 | eq_ref | PRIMARY | PRIMARY | 4 | t2.dependent_id | 1 | |

MySQL bloque ainsi seulement la PK et fait bien du ‘row level locking’. T2 peut aboutir sans problème. CQFD!

Kaj réagit aux discussions d’hier. Mais qu’est ce que cela va changer pour le user landa? Va-t-il se tourner vers la version enterprise? Sachant que j’ai encore des serveurs qui tournent MySQL du 3.23, du 4.0 et du 4.1, cette restructuration aura-t-elle un impact pour moi? Non je ne crois. Pour des grosses sociétés, tous les bugs sont trouvés en phase de test… si la version courante est buggé, je prendrais la précédente.

Les annonces faites par Kaj ont secoué un peu la communauté avec des réactions assez forte de ses membres actifs. Je vous laisserez les lire en détails sur son blog.
Mais voila l’idée générale:

• Les patchs et les nouvelles fonctionnalités ne seront plus appliqué à la GA mais attendront la version suivante.
• 2 GA par an pour ce qui est des binaires
• pour les nouvelles versions 1 GA par mois jusqu’à maturation
• 4 GA par an pour ce qui est des sources
• Les sources des versions “entreprise” ne seront disponibles que pour les clients payant

Suite à cela pas mal de réactions, en autres de la part de Mike et Jeremy à ce sujet.

Maintenant quoi penser de la chose? Techniquement, MySQL est open source et pas free source. MySQL a été porté par sa communauté et c’est ce qui a fait que cette BdD soit devenu si populaire. On ne peut pas s’empêcher de penser à la même séparation qu’il y a eu lieu entre RHEL et Fedora. A la différence que les patchs et fixs sont d abord appliqués sur FC et que les versions stabilisées sortent ensuite sur RHEL.

Lorsque vous faites un SHOW SLAVE STATUS pour savoir l’état d’un de vos slaves dans votre chaîne de réplication, vous avez cet intéressant paramètre Seconds_behind_master, ceci évidemment si vous utilisez MySQL 4.1 et plus. Sur un serveur j’ai eu la désagréable surprise de voir cette valeur alterner constamment entre 0 et 2 heures…Humm? Ceci m’a poussé à regarder plus en détail le calcul de cette valeur.

Quand un slave se connecte au master, par la entendez le Slave I/O thread, il enregistre la valeur dm = SELECT UNIX_TIMESTAMP() ce qui revient à connaître la date actuelle du master (dm: date master) puis fait la même chose sur lui même ds = SELECT UNIX_TIMESTAMP() (ds: date slave). De la il calcule la différence D = ts - tm.

Dans les log de réplication (binlog) sont enregistrés les dates d’exécutions de chaque requête. Ainsi lorsque le Slave SQL thread rejoue ces même requêtes, il calcule:

seconds_behind_master = SELECT UNIX_TIMESTAMP() sur le slave - date d’exécution de la requête sur le master - D

Premier point, ce paramètre nous donne la différence entre le moment où une requête est mise dans le relay log et le moment ou elle a été executé sur le master. En aucun cas nous connaissons le temps qu’il a fallu pour la récupérer du master. Donc imaginons maintenant que votre slave est lent à les récupérer mais une fois récupérées, elles soient exécutées instantanément… Votre valeur Seconds_behind_master sera 0 alors qu’en réalité votre slave peut ne pas être à jour.

Quand le SQL thread est au niveau, pas d’autre relay log à jouer, Seconds_behind_master sera 0. Si votre connexion réseau est rapide, le slave I/O thread sera proche du masteret donc ce champ vous donnera une bonne approximation. Dans le cas contraire, le valeur sera 0 car le SQL thread est en attente du I/O thread et non car votre slave est à jour.

NULL est un autre valeur possible pour ce champ, si l’I/O thread est en pause ou en train de se reconnecter, celle valeur est mise à NULL.

En résumé, celle valeur est informative et peut éventuellement vous mettre sur la piste d’un problème réseau mais elle n’est pas à prendre pour argent comptant.