mysql backup script

Une fois installée votre première base de donnée Mysql sur un os Windows qui n’est pas un poste de développeur, vous deviendrez par définition un DBA et la tâche la plus importante de celui-ci est … la sauvegarde des données.

Vous irez souvent chercher sur le net un script tout fait qui face cela simplement et la plupart d’entre eux utilise une méthode simple mais qui a fait ses preuve, l’utilitaire mysqldump.

Voici un script un peu plus complet que la moyenne, gèrant un bug pernicieux du ERRORLEVEL sous Windows, et sauvant en plus les routines et la table d’évènements. Et testé depuis un an en production.

Il gère les sauvegardes à chaud, à froid (service coupé, la méthode la plus fiable), incrémental (fichiers binlogs), et vous envoyant un mail de rapport si spécifié.
J’aimerais le compléter avec une gestion des binlogs plus poussé, la compression des fichiers, des méthodes de sauvegardes plus complètes voir le support des snapshots

Le zip fourni contient le script, un fichier de configuration et un utilitaire d’envoi de mail.

mysqlbackupscriptTéléchargement

Je vous recommande également la lecture de cet article de la documentation officielle:
http://dev.mysql.com/doc/refman/5.0/fr/backup-policy.html

Pour une solution plus complète, regardez les solutions commerciales zmanda recovery manager ou mysql enterprise backup

De l’arrivée des ORMs

En passant

projet pour la fontaine de l’éléphant de la Bastille, Aquarelle de Jean-Antoine Alavoine (1776-1834)

Un des changements récents et inévitable de notre nouvelle ère numérique est l’objectivation  des bases de données, et l’introduction des ORMs. Je me frotte a ces beautés fatales depuis plusieurs années et si les débuts furent assez séduisants mais houleux, j’en conclus avec le recul que l’évolution est incontournable.
Essentiellement de part la proéminence des langages objects : même si C tient le haut du pavé sur Tiobe, C++ C# et java sont juste derrière (voir devant depuis janvier). Quoi de plus naturel que de persister directement les objets en bases, sans mapping manuel qui est source d’erreurs.

Seulement, ces outils puissants sont aussi complexes et ne remplacent pas une connaissance minimale de SQL, faute de se tirer une balle dans le pied. Si vous ne regardez pas les requetes générées ou le modèle, attention aux surprises lors de la mise en production. Sur de gros volume de données, cela pardonne moins facilement.

Vous serez donc bien aise de lire les mauvaises pratiques d’hibernate et d’autres avant de vous lancer plus en avant, et de trouver un bon tutoriel (ici pour nhibernate).

A contrario, il existe de nombreux cas où l’utilisation d’un ORM est trop coûteux, et vos premiers projets avec cette technologie seront bien sur plus lents.

Je vois plusieurs effets directs de cette arrivée à maturité des ORM :

  • un premier est que les développeurs s’intéressent plus à ce qui se passe coté base de donnée et vont moins faire de copier/coller, sans doute parce que l’ORM les soulage des tâches les moins nobles
  • un autre est que les couches d’accès aux données peuvent se simplifier considérablement,
    il est possible de les faire tenir en une centaine de ligne nonobstant les entités.
  • un dernier est le blowback, l’arrivée des noSQL, non pas pour stocker des grosses quantités de données, mais pour s’astreindre des difficultés de la modélisation (et je rejoins l’avis de monty).

Un cas classique est le stockage d’objets sérialisés (en json, ou en xml) sur des bases jeunes (mongoDB) ou des graphes d’objets dans des blobs… avec les médiocres performances ou la perte de fonctionnalités: plus de critères, plus de compatilité ascendante.

Les développeurs ne savent-ils plus modéliser, ou le DBA n’a-t-il plus de rôle  ? C’est un éventualitée mais dans ce cas c’est effectivement la fin de vie des SGBDR car ils ne sont performants qu’avec des modèles bien fait.

La prochaine étape sera peut-être alors le retour en grâce des bases de données objets qui existent depuis nombreuses années mais n’ont pas réussit à s’imposer face aux SGBDR traditionnels, même s’ils sont plus performants sur les opérations de CRUD.
A moins que les SGBDR n’intègrent de plus en plus l’objet… A cet égard, l’exemple CRUD de mysqlcluster est impressionant.

Ou alors des SGBDR qui crée

Une anecdote pour finir: savez-vous que Posgresql gère l’héritage de table depuis la version 7 ?

Sql Server Express log des requêtes

Si on prend le cas de SQL Express, il n’est pas possible nativement de voir les requêtes exécutées, ce qui est au combien pénible surtout dans notre ère des ORM. On risque de se retrouver en production avec des horreur de type n+1 ou autre comme l’explique si bien R.J Lorimer (son article parle d’Hibernate mais s’applique très bien à ses congénères) ou d’autres.

On peut démarrer le service avec les paramètres /T4032 /T3605 en éditant le  registre ou mieux faire un démarrage en ligne de commande et faire un bon vieux tail des familles.

SQL Express a le bon gout de faire tourner ses logs à chaque démarrage.

Accessoirement, je vous laisse découvrir le  billet d’un développeur indien qui a construit un plugin visual studio autour de l’idée !!

Une solution qui a le mérite de (re)faire découvrir la relative simplicité du développement des plugin VS encore que son implémentation du tail lui-même ne soit peut-être pas très performante…
Décidément Pondicherry semble inspirer