Depuis la version 5.1.6, MySQL dispose d’un planificateur d’événements qui évite de recourir à des scripts que nous planifions avec le gestionnaire cron sous Linux. La méthode est bien plus sûre puisqu’elle évite que les mots de passe se baladent dans différents fichiers du serveur, en clair !

Activation du planificateur d’événements

Vous pouvez éditer le fichier my.ini ou my.cnf et ajouter dans la section [mysqld] la ligne event_scheduler=1. Vous devez alors redémarrer l’instance :

• service mysqld restart, sous CentOS (la méthode reload ne marche pas pour MySQL)
• net stop MySQL && net start MySQL, sous Windows

Vous pouvez aussi modifier à chaud ce paramètre par l’une ou l’autre des deux commandes ci-dessous :

• SET GLOBAL event_scheduler=1
• SET @@global.event_scheduler=1

Pour vérifier que le planificateur d’événements s’exécute sous MySQL, tapez :

SELECT @@global.event_scheduler

Vous pouvez, par ailleurs, vérifier le fonctionnement du planificateur d’événements avec la commande SHOW PROCESSLIST.

Réparation et optimisation planifiées de tables MyISAM

Cet événement planifié a pour objet de programmer tous les jours les commandes REPAIR et OPTIMIZE sur des tables MyISAM :

DROP EVENT IF EXISTS grc.e_repair_grc;
DELIMITER $$
CREATE EVENT grc.e_repair_grc
    ON SCHEDULE EVERY 1 DAY STARTS '2013-01-17 15:30:20'
        ENABLE
    DO 
        BEGIN
                DECLARE val_table VARCHAR(255);
                DECLARE val_schema VARCHAR(255);
                DECLARE val_sql VARCHAR(255);
                DECLARE cur_grc CURSOR FOR
                        SELECT table_schema, table_name
                        FROM information_schema.tables
                        WHERE table_schema='grc';
                OPEN cur_grc;
                LOOP
                        FETCH cur_grc INTO val_schema,val_table;
                        SET @a=val_schema;
                        SET @b=val_table;
                        SET @s='REPAIR TABLE ?.?';
                        PREPARE stmt FROM @s;
                        EXECUTE stmt USING @a,@b ;
                        DEALLOCATE PREPARE stmt;
                        SET @s='OPTIMIZE TABLE ?.?';
                        PREPARE stmt FROM @s;
                        EXECUTE stmt USING @a,@b ;
                        DEALLOCATE PREPARE stmt;
                END LOOP;
                CLOSE cur_grc;
        END
$$
DELIMITER ;

Vérifications d’usage

Le 1er contrôle à effectuer est de vérifier que votre « event » a bien été créé. Pour ce faire, vous pouvez employer deux méthodes distinctes :

• USE grc ; SHOW EVENTS ;
• SELECT * FROM INFORMATION_SCHEMA.EVENTS ;

Mais cela ne suffit pas. Il vous faudra contrôler dans les logs de MySQL que la commande programmée s’est correctement exécutée. Pour les activer, là-encore, vous disposez de deux méthodes.

• A froid, ajoutez general_log=1 dans la section [mysqld] du fichier my.ini ou my.cnf et redémarrez l’instance comme indiqué ci-dessus.
• A chaud , tapez à partir de l’invite MySQL SET GLOBAL general_log=1 ou SET @@global.general_log=1.

Le fichier de logs du type host.log se situe par défaut à l’endroit où sont stockées les données.

Pour plus d’information sur la commande CREATE EVENT : Event Scheduler Configuration

 Dsfc

Autres articles sur le sujet :

1. MySQL : des triggers à la place des check constraints !
2. Hétic, saison 2, sur MySQL !
3. Tracer les connexions à MySQL
4. Développer avec MySQL 5.5
5. Administration de MySQL 5.5 sous Linux
6. Performances WordPress : surveillez les requêtes MySql !
7. Administrer MySQL en mode graphique
8. Le paquet Mysql-Server : exemple de contorsion sous Debian et Ubuntu
9. Installer MySQL 5.1 sur CentOs 5.4
10. Exporter la structure d’une base Mysql en XML