J'ai fait quelques tests de NDOutils, extension servant à stocker les événements générés par Nagios dans une base (My)SQL. Le schéma de base de NDOutils utilise InnoDB. Qui dit transactions, dit journal de ces transactions. Lorsque tu as un volume conséquent de transactions, disons entre 20 et 30 requêtes/seconde, le volume des ces journaux est important, environ 8GO/jour dans ce cas. Logiquement, j'espère, j'en suis venu à tweaker la configuration de Mysql pour ne pas conserver ces 8GO. Et là, petite surprise: tu peux jouer sur deux paramètres: la taille des fichiers (max_binlog_size) et le nombre de jours pendant lesquels tu les conserves (expire_logs_days). Ce nombre de jour est un entier comprit entre 0 et 99, 0 désactive la suppression des logs de manière automatique. Tu peux tout de même passer des requêtes pour supprimer les journaux.
Là ou pour moi c'est une, mauvaise, surprise, c'est dans la comparaison avec PostgreSQL. j'avais eu à configurer la gestion des journaux sur un PostgreSQL, et tu pouvais, de mémoire, jouer sur: la taille d'un fichier, le nombre total de fichiers (avec une rotation automatique) et, éventuellement, une commande shell à éxecuter automatiquement juste avant la suppression d'un journal: par exemple, copier le journal sur un système de fichier réseau, faire un scp, ...
Avec PostgreSQL, tu n'as aucun mal à prévoir la taille totale des journaux: taille d'un fichier x nombre de fichiers. Avec MySQL, c'est impossible. De plus, si tu veux conserver les journaux, il te faut une moulinette qui va mêler SQL et commandes shell.
Ce point particulier illustre bien pourquoi je préfère PostgreSQL à Mysql: la moindre fonctionnalité un tant soit peu intéressante de MySQL souffre de limitations franchement absurdes.
J'ai joué avec tout ça cette semaine, donc en 2008, avec le mysql d'une debian stable. Si on me montre comment mieux gérer ces journaux, j'en serais particulièrement heureux !
[^] # Re: Et Derby alors ?
Posté par matt23 . En réponse à la dépêche Sun Microsystems fait l'acquisition de MySQL. Évalué à 2.
Là ou pour moi c'est une, mauvaise, surprise, c'est dans la comparaison avec PostgreSQL. j'avais eu à configurer la gestion des journaux sur un PostgreSQL, et tu pouvais, de mémoire, jouer sur: la taille d'un fichier, le nombre total de fichiers (avec une rotation automatique) et, éventuellement, une commande shell à éxecuter automatiquement juste avant la suppression d'un journal: par exemple, copier le journal sur un système de fichier réseau, faire un scp, ...
Avec PostgreSQL, tu n'as aucun mal à prévoir la taille totale des journaux: taille d'un fichier x nombre de fichiers. Avec MySQL, c'est impossible. De plus, si tu veux conserver les journaux, il te faut une moulinette qui va mêler SQL et commandes shell.
Ce point particulier illustre bien pourquoi je préfère PostgreSQL à Mysql: la moindre fonctionnalité un tant soit peu intéressante de MySQL souffre de limitations franchement absurdes.
J'ai joué avec tout ça cette semaine, donc en 2008, avec le mysql d'une debian stable. Si on me montre comment mieux gérer ces journaux, j'en serais particulièrement heureux !