Limitations et restrictions

Certaines commandes MySQL ne sont pas permises dans un événement.

Verrouiller une table est interdit: LOCK TABLES, UNLOCK TABLES.

Il n’est malheureusement pas possible de charger des données avec la commande LOAD DATA INFILE.

Les requêtes préparées (PREPARED STATEMENT) ne peuvent être créées dans un événement.

La récursivité.

Un événement ne peut être créé, modifié ou supprimé par un déclencheur, une procédure stockée ou un autre événement.

De plus, on ne peut pas créer, modifier ou supprimer un déclencheur ou une procédure stockée dans un événement.

La suppression d’une base de données (DROP DATABASE) entraine la suppression de tous les objets qu’elle contient, donc les évènements aussi.

Un événement désactivé (DISABLE, DISABLE ON SLAVE) est supprimé en cas d’arrêt du serveur.

Le DEFINER doit avoir les droits nécessaires pour l’exécution de l’évènement, cet utilisateur doit bien entendu exister. S’il est supprimé, renommé ou si ses privilèges ne sont plus adaptés, l’exécution de l’évènement échoue.

En éditant le journal des erreurs:

Conclusion

Comme vous avez pu le constater tout au long de cet article, le programmateur d’évènements est bien plus qu’un simple gadget, un véritable outil qui s’ajoute à la palette de l’administrateur de base de données MySQL.

Malgré certaines limitations, comme l’impossibilité de lancer des commandes systèmes ou des scripts externes, ce planificateur facilitera la vie du DBA en lui donnant la possibilité d’automatiser certaines tâches de maintenance.

(Début de l’article)

Appel d’une procédure stockée

Il est possible d’appeler des procédures stockées dans un événement.

Archivage périodique des données

Beaucoup d’entreprises sont obligées de conserver d’énormes volumes de données historiques sur leurs serveurs de bases de données. Un moyen de réduire l’espace occupé est d’utiliser le moteur de stockage ARCHIVE. Ce moteur de table, compresse automatiquement les données qui n’occupent alors plus que 30% de leur taille originale.

]]> http://dasini.net/blog/2009/06/24/le-programmateur-devenements-event-scheduler-part-56/feed/ 2 http://dasini.net/blog/2009/06/16/le-programmateur-devenements-event-scheduler-part-46/ http://dasini.net/blog/2009/06/16/le-programmateur-devenements-event-scheduler-part-46/#comments Tue, 16 Jun 2009 09:58:03 +0000 freshdaz http://dasini.net/blog/?p=622 SELECT * FROM _event.insert_event ; mysql> DELIMITER €€ mysql> CREATE EVENT `_event`.`second_event` ON SCHEDULE EVERY 30 SECOND DO BEGIN /*selectionne la val maximale de la colonne fois. Si elle vaut NULL alors retourne la valeur 0 dans la variable @fois*/ SELECT if(max(fois),max(fois)+1,1) INTO @fois FROM _event.insert_event; /*Insertion des données dans la table*/ INSERT INTO _event.insert_event (moment, fois, action) VALUES (now(), @fois, concat('Execution ', @fois, " de l'event")); END €€ mysql> DELIMITER ;]]>

Quelques exemples d’évènements

Insertions de données dans une table, toutes les 30 secondes

Créer une vue matérialisée

Le concept de vue matérialisée n’est pas implémenté dans MySQL. Une vue matérialisée est un « snapshot ». Ce type de vue permet de stocker le résultat d’une requête, contrairement aux vues classiques qui elles, ne stockent que la définition de la requête. Les vues matérialisées ne réexecutent donc pas la requête à chaque interrogation. Par contre la gestion de la fraîcheur des données est à la charge de la vue.

A noter que les commandes TRUNCATE et INSERT ne sont pas atomiques. Il est donc possible qu’une interrogation sur la table _event.City_fra ne renvoie pas de résultat.

(à suivre… event scheduler: Appel d’une procédure stockée)

Gérer les évènements

MySQL propose plusieurs méthodes pour visualiser les évènements. La méthode la plus pratique consiste à aller chercher l’information dans la table event de la base de données des méta-données information_schema:

L’évènement premier_event créé précédemment n’y apparaît pas. C’est tout à fait normal, un événement à exécution unique n’est par défaut pas conservé par MySQL. Modifions notre événement pour qu’il puisse en rester une trace après son exécution:

MySQL propose également deux autres commandes pour avoir des informations sur les évènements:

SHOW EVENTS et SHOW CREATE EVENT:

A noter, qu’il est également possible de lire l’information dans la table event de la base de données mysql avec la requête suivante: SELECT * FROM event .

Vous avez aussi la possibilité de modifier la structure d’un événement, le renommer, ou encore changer son code avec la commande: ALTER EVENT

On retrouve les clauses de la commande CREATE EVENT, que l’on peut donc modifier aisément avec ALTER EVENT. Le dernier utilisateur qui modifie un événement devient son DEFINER. Par exemple si un évènement à pour DEFINER daz@localhost. Une modification de cet événement, par exemple le désactiver (DISABLE), avec l’utilisateur root@localhost mettra le DEFINER de l’évènement à la valeur root@localhost.

Désactiver un évènement

Il est bien entendu possible d’effacer un événement. Ceci se fait avec la commande DROP EVENT.

Effacer un évènement

(à suivre… event scheduler: Quelques exemples d’évènements)

Créer un événement

Pour créer notre premier événement, un coup d’oeil dans la documentation de MySQL nous donne les informations suivantes:

CREATE

[DEFINER = { user | CURRENT_USER }]

EVENT

[IF NOT EXISTS]

nom_évènement

ON SCHEDULE moment

[ON COMPLETION [NOT] PRESERVE]

[ENABLE | DISABLE | DISABLE ON SLAVE]

[COMMENT 'commentaire']

DO requêtes_sql;

moment:

AT timestamp [+ INTERVAL intervalle] ...

| EVERY interval

[STARTS timestamp [+ INTERVAL intervalle] ...]

[ENDS timestamp [+ INTERVAL intervalle] ...]

Les clauses entre crochets sont optionnelles, pour nous faciliter la tâche, ignorons les pour le moment. Comme tous les objets de la base de données, notre événement a un nom: nom_évènement . Il se lance à un moment: moment, pour exécuter des requêtes: requêtes_sql.

Le lancement de l’évènement est soit ponctuel (AT), soit récurrent (EVERY).

Armé de ces quelques éléments, empressons-nous de créer notre premier événement.

Commençons par créer et nous connecter à la base de données dans laquelle se dérouleront nos tests, la base de données _event, et ensuite créons la table insert_event, qui accueillera les données insérées grâce à notre événement.

Quelques explications s’imposent. L’évènement premier_event s’exécute dès sa création, car le moment choisi est CURRENT_TIMESTAMP,de plus il ne s’exécute qu’un fois à cause de la clause AT. Le comportement programmé est ici très simple, il s’agit simplement d’insérer un enregistrement dans la table insert_event. Pour le vérifier il suffit de taper la requête suivante:

mysql> SELECT  *  FROM  insert_event;

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

| moment              | fois | action            |

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

| 2008-05-29 20:46:25 |    0 | Mon premier event |

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

Notre événement à également laissé des traces dans le fichier de journalisation des erreurs (error log):

Ce fichier d’erreurs nous apprend essentiellement deux choses: premièrement que l’évènement s’est déroulé correctement (c’est pour ainsi dire une bonne nouvelle) et deuxièmement que l’évènement à été effacé. En effet, un événement qui ne s’exécute qu’une seule fois n’est par défaut pas préservé (ON COMPLETION NOT PRESERVE) après son exécution.

Pour nous remettre de toutes ces émotions, explicitons les clauses optionnelles de la syntaxe du CREATE EVENT:

DEFINER: le créateur de l’évènement.

IF NOT EXISTS: clause permettant de ne pas générer de messages d’erreurs si un évènement du même nom existe au moment de la création.

ON COMPLETION [NOT] PRESERVE: permet de rendre un événement à exécution unique, persistant dans la table système mysql.event après son exécution.

ENABLE | DISABLE | DISABLE ON SLAVE: active / désactive un événement. Attention un événement désactivé est effacé au redémarrage du serveur MySQL.

COMMENT : Ajouter un commentaire. (ce qui est, du reste, une excellente idée)

(à suivre… event scheduler: Gérer les évènements)

Qu’est-ce qu’un programmateur d’évènements ?

Le programmateur d’événements ou « event scheduler » offre la possibilité, à l’administrateur de base de données, de déclencher l’exécution de requêtes programmées directement dans le serveur MySQL. Ce planificateur de tâches (CRON-like) interne permet donc d’automatiser très simplement des tâches à des intervalles réguliers, ou à heure fixe, sans avoir besoin de configurer le système sur lequel la base de données fonctionne.

Comment fonctionne le programmateur d’évènements ?

La première chose à faire est de vérifier si le programmateur d’évènements est activé. Pour ce faire regardez la valeur du paramètre event_scheduler:

mysql> SHOW VARIABLES LIKE 'event_scheduler';

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

| Variable_name   | Value |

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

| event_scheduler | OFF   |

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

Par défaut le programmateur n’est pas activé, event_scheduler vaut donc OFF. Activez le avec la commande SET GLOBAL (le droit SUPER est nécessaire).

mysql> SHOW GLOBAL VARIABLES LIKE 'event_scheduler';

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

| Variable_name   | Value |

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

| event_scheduler | ON    |

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

Un fois activé, le programmateur d’évènements créé un processus léger (thread) qui tourne en tâche de fond. Ce processus est chargé d’exécuter les événements lorsque le moment est venu. On peut le voir avec la commande SHOW PROCESSLIT. Cependant, il faut avoir le privilège SUPER pour pouvoir la lancer.

(à suivre… event scheduler: Créer un évènement)

]]> http://dasini.net/blog/2009/04/20/le-programmateur-devenements-event-scheduler-part-16-2/feed/ 0 http://dasini.net/blog/2008/12/03/les-nouveautes-de-mysql-51-part-25/ http://dasini.net/blog/2008/12/03/les-nouveautes-de-mysql-51-part-25/#comments Wed, 03 Dec 2008 00:37:25 +0000 freshdaz http://dasini.net/blog/?p=275
(<- précédent)

Le programmateur d’évènements

Pouvoir automatiser ses tâches de manière fiable et simple est le rêve de tout administrateur de base de données. Le programmateur d’évènements (Event Scheduler) est un planificateur de tâches (CRON-like) embarqué dans MySQL 5.1.

Il est alors possible d’exécuter, de façon récurrente ou unique, des requêtes, en fonction de la date et de l’heure.

L’évènement se crée avec la commande CREATE EVENT.

CREATE EVENT nom_evenement ON SCHEDULE
      <moment> DO <code_sql>

L’évènement peut être lancé une seule fois (AT) ou de manière répétitive (EVERY)

<moment> = AT | EVERY

L’évènement est constitué d’un ensemble de requêtes.

<code_sql> = requêtes sql

Créer une vue matérialisée rafraîchie toutes les 10 minutes :

DELIMITER //
CREATE EVENT vue_materialisee
ON SCHEDULE EVERY 10 MINUTE
DO
BEGIN
   TRUNCATE TABLE _event.City_fra;
   INSERT INTO _event.City_fra
      SELECT * FROM world.City WHERE CountryCode='FRA'
      ORDER BY name;
END//
DELIMITER ;

La réplication par les données (row based)

MySQL permet de journaliser dans un fichier les requêtes d’écriture effectuées sur le serveur. Ce fichier, le binary log, stocke ces requêtes en un format binaire (d’où son nom). Il est indispensable à la réplication, et est également utilisé pour la restauration du serveur.

A partir de MySQL 5.1, le serveur permet de stocker cette information, non plus seulement sous forme de requêtes (statement based) mais également sous forme de lignes (row based). Cette nouvelle fonctionnalité est intéressante, en particulier en cas de réplication de requêtes non déterministes.

La commande SHOW VARIABLES LIKE ‘binlog_format’ permet de connaître le format du journal binaire

mysql> SHOW VARIABLES LIKE 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | MIXED |
+---------------+-------+
1 row in set (0.00 sec)

Trois options de journalisation sont disponibles :

• Statement based (mode par défaut) : On journalise la requête telle-quelle (pas son résultat),
• Row based : On journalise le résultat de la requête,
• Mixed : MySQL choisit entre statement et row en fonction du contexte.

Le mode de journalisation peut être changé dynamiquement avec la commande SET

mysql> SET SESSION binlog_format='ROW';
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
1 row in set (0.01 sec)

mysql> SET SESSION binlog_format='STATEMENT';
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE 'binlog_format';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
1 row in set (0.01 sec)

mysql> SET SESSION binlog_format='MIXED';
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | MIXED |
+---------------+-------+
1 row in set (0.01 sec)

(à suivre… MySQL Cluster & general log, slow query log dans une table)

]]> http://dasini.net/blog/2008/12/03/les-nouveautes-de-mysql-51-part-25/feed/ 2