Parmi les nouveautés de MariaDB 5.3, l’une d’entre elle, bien pratique est le « progress reporting », qui permet de savoir où le serveur en est dans l’exécution d’une commande.

Le principe est simple, j’exécute une commande et MariaDB m’indique le pourcentage effectué pour une étape donnée. Un exemple:

MariaDB-5.3> ALTER TABLE client ENGINE=InnoDB;
Stage: 1 of 2 'copy to tmp table'   44.5% of stage done

MariaDB-5.3> ALTER TABLE client ENGINE=InnoDB;
Stage: 2 of 2 'Enabling keys'      0% of stage done    

MariaDB-5.3> ALTER TABLE client ENGINE=InnoDB;
Query OK, 3000000 rows affected (5 min 15.24 sec)      
Records: 3000000  Duplicates: 0  Warnings: 0

Les commandes implémentant le « progress reporting » sont pour le moment: ALTER TABLE, ADD INDEX, DROP INDEX, LOAD DATA INFILE.

Le moteur Aria supporte également les commandes suivantes: CHECK TABLE, REPAIR TABLE, ANALYZE TABLE, OPTIMIZE TABLE

MariaDB-5.3> > CHECK TABLE aria_table;
Stage: 3 of 3 'Checking data'      0% of stage done

Plus d’informations sur AskMonty.org.

Je suis amené à réaliser régulièrement des audits de serveurs MySQL.Voici le premier volet d’une série d’articles où je vais essayer de vous donner quelques points clés pour mieux comprendre le fonctionnement de MySQL.

La configuration du serveur est un des points que je regarde, et l’une des erreurs les plus courantes concerne le paramétrage des options tmp_table_size et max_heap_table_size.

my.cnf, comme vous le savez certainement est le nom du fichier de configuration de MySQL. Vous pouvez également le retrouver sous le nom de my.ini en environnement MS Windows. Il permet comme son nom l’indique de configurer votre serveur MySQL en y centralisant les options de … configuration. Le but ici n’est pas de détailler la longue liste des paramètres de MySQL, la documentation officielle est (presque) bien faite, mais de mettre le « focus » sur la directive !include (avec un « ! » devant).

Cette dernière permet d’inclure un fichier de configuration dans un autre (sic). Autant je suis un adèpte de la non duplication du code en dévellopement (des require_once en PHP utilisés avec modération ça vous simplifie bien votre code), autant je ne suis pas un grand fan pour éclater la configuration de mon serveur MySQL en plusiseurs endroits. Cependant il faut avouer que parfois cela peut servir !

Alors comment ça marche ?

C’est (apparemment) très simple. Mon client mysql va chercher sa configuration dans différents endroits (définit à la compilation):

Mon fichier de configuration se nomme  /etc/mysql/my.cnf et il contient simplement la directive !include suivit du « vraie » fichier de configuration:

Et au final dans mon fichier de configuration (au passage j’utilise le très pratique soft développé par Giuseppe Maxia : MySQL Sandbox):

Simple non ?

C’est (presque) tout, et ça marche…pas

Une petite vérification s’impose:

Les paramètres ne sont pas prit en compte. (commentaire de l’expert: ça ne peut donc pas fonctionner)

(30 minutes et quelques insultes plus tard…)

En fait, la subtilité,  c’est de rajouter un saut à la ligne, à la fin de la commande !include /home/daz/sandboxes/msb_5_1_35/my.sandbox.cnf

Vérification (au cas où):

(commentaire de l’expert: ça fonctionne !)

MySQL possède un grand nombre de fonctions pour gérer les dates et le temps. Il est possible de récupérer le numéro calendaire d’une semaine avec la fonction week. Dimanche 5 avril nous étions semaine 14. La fonction week nous le confirme:

mysql> SELECT week('2009-04-05');
+--------------------+
| week('2009-04-05') |
+--------------------+
|                 14 |
+--------------------+

Lundi 6 avril, nouvelle semaine, on passe donc à la semaine 15:

mysql> SELECT week('2009-04-06');

+--------------------+

| week('2009-04-06') |

+--------------------+

|                 14 |

+--------------------+

Souci !!! Le résultat n’est pas celui espéré (14 au lieu de 15). En fait la fonction week prend un deuxième paramètre optionnel, qui permet de « régler la précision » (compter sur 53 ou 54 semaines, commencer la semaine un dimanche ou un lundi…) bref elle est complète et complexe…

Le réglage usuel est de mettre le deuxième paramètre à 3 ! ou alors d’utiliser la fonction WEEKOFYEAR.

mysql> SELECT weekofyear('2009-04-05');
+--------------------------+
| weekofyear('2009-04-05') |
+--------------------------+
|                       14 |
+--------------------------+

mysql> SELECT weekofyear('2009-04-06');
+--------------------------+
| weekofyear('2009-04-06') |
+--------------------------+
|                       15 |
+--------------------------+

Il est pafois utile de désactiver le log binaire lors d’une restauration. MySQL permet de le désactiver pour une session avec la commande SQL_LOG_BIN:

Lors de la restauration avec le client mysql on peut donc utiliser la ligne de commande suivante:

En cas de perte du mot de passe root surtout si c’est votre seul compte (super) administrateur, vous vous trouvez dans une situation pour le moins embarrassante.
MySQL propose un moyen de s’en sortir. Certes, si le mot de passe est perdu vous ne pourrai pas le récupérer, car il est stocké haché dans la base:

mysql> SELECT user, password FROM mysql.user;
 +---------+-------------------------------------------+
 | user    | password                                  |
 +---------+-------------------------------------------+
 | root    | *81F5E21E35407D884A6CD4A731AEBFB6AF209E1B |
 +---------+-------------------------------------------+
 1 rows in set (0.39 sec)

Néanmoins il est possible de le changer. Voici les étapes à suivre:

1/ Arrêter le serveur MySQL

Cela ne devrait pas poser trop de problèmes:
mysql stop (sous linux)
NET STOP MySQL (sous windows)
…
ou dans le pire des cas, débranchez la machine

2/ Démarrer le serveur en désactivant la vérifications des droits

shell> mysqld --skip-grant-tables

Il important de noter qu’une fois démarré avec skip-grant-table, n’importe qui peut se connecter au serveur MySQL et avec tout les droits… Inutile de préciser que le serveur est à ce moment particulièrement vulnérable.

3/ Connexion au serveur MySQL

Connectez vous au serveur mysql, comme à l’accoutumée.

shell> mysql --user=UtilisateurExistantPas --password=MotDePasse

Welcome to the MySQL monitor.  Commands end with ; or \g.
 Your MySQL connection id is 2
 Server version: 5.1.30-community-log MySQL Community Server (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

4/ Protéger le serveur

La première chose à faire, une fois connecté est de sécuriser le serveur en remettant en place la vérification des droits:

mysql> FLUSH PRIVILEGES;

shell> mysql --user=UtilisateurExistantPas --password=MotDePasse
 ERROR 1045 (28000): Access denied for user 'UtilisateurExistantPas'@'localhost'
(using password: YES)

5/ Changer le mot de passe

L’heure est enfin venue de se créer un nouveau mot de passe root

mysql> SET PASSWORD FOR root@localhost=PASSWORD('m0T2pA55e');
 Query OK, 0 rows affected (0.06 sec)

6/ Arrêter le serveur

Pour sortir de la configuration skip-grant-tables, il faut arrêter le serveur, pour mieux le redémarrer…

7/ Redémarrer le serveur normalement

et le tour est joué

shell> mysql --user=root --password=m0T2pA55e
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.30-community-log MySQL Community Server (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>