Le carnet du grincheux

Une journée de perdue. Une journée complète perdue à essayer de remettre une base de données d'équerre chez un client. Le bougre avait perdu toutes les données d'une table, mais de façon assez surprenante sans que sa base de données soit corrompue et, disait-il, sans qu'il n'ait rien fait. J'ai pourtant la désagréable impression qu'il y a eu un DELETE FROM mytable quelque part… Seul ennui, cela s'est passé sur une machine qu'il administre lui-même et qui n'écrivait strictement rien dans les fichiers journaux. Autant dire que la seule indication de connexions ssh en root de la part d'une adresse visiblement forgée dans /var/log/auth.log n'était que d'une utilité toute relative.

J'étais donc le responsable tout désigné même s'il n'avait aucune sauvegarde de ses données. J'étais le responsable tout désigné même si cette machine possédait un mot de passe trivial pour root et si son daemon sshd acceptait les connexions sur root. Passons, le client est roi.

Pourtant, je le lui avait dit. Un serveur, ça s'administre un minimum. Il vaut mieux même qu'il soit administré par des gens compétents. Là, visiblement, ce n'était pas le cas et la sécurité reposait sur un port ssh non standard. Remarquez, c'est déjà mieux que rien et il ne faut pas voir le mal partout.

Mais ce n'est pas tout. MySQL doit être, à l'exception notoire de MS-SQL, le pire système de base de données existant. Ce truc est capable de corrompre des données plus qu'à son tour, surtout lorsqu'on utilise autre chose que MyISAM, et est d'une stabilité toute relative lorsqu'on essaie de faire fonctionner des répliques. Je ne compte plus personnellement le nombre de répliques qui ont explosées en vol devant mes yeux ébahis sur des requêtes des plus classiques, se soldant par un arrêt de la base de production pour faire une archive dans un état connu et un redémarrage avec les logs binaires du serveur puis de sa réplique. Ce qui m'amusera toujours, c'est de voir une réplique à jour refuser une requête conforme sur des données existantes. C'est pour moi un réel mystère et un émerveillement de tous les instants.

Remettre en route une réplique MySQL sur une base sensible est toujours un sport de haut vol. Ça l'est encore plus lorsqu'on ne peut pas arrêter la base avant l'interruption programmée de service suivante. Lorsqu'on tel décrochage se produit et qu'on doit attendre quelques jours avant de pouvoir repartir d'un état connu, on a largement le temps de se convertir à toutes les religions du monde et prier pour que la base principale n'explose pas d'ici-là. Pour ménager mes nerfs, j'en suis maintenant à installer quatre répliques parallèles par serveur de production ! Ceintures et bretelles, mais avec un tel outil, ça se justifie.

Ainsi, prétendre utiliser MySQL sur des bases importantes sans sauvegarde quotidienne est aussi risqué que d'essayer de danser un quick step avec des talons aiguilles. Il y en a qui ont essayé. On risque au mieux l'entorse, au pire le traumatisme crânien ou la foulure de méninges. Là, ce sont juste 700 Mo de données qui ont disparu. Des données qui seront difficiles à reconstruire, mais heureusement rien de vital.

Sauf que… Sauf qu'un bon nombre de serveurs sont aujourd'hui administrés comme cela, à la va comme je te pousse. Non seulement les bases sont trop souvent des bases MySQL, mais encore les administrateurs systèmes sont des administrateurs aux pieds tendres qui ne savent pas toujours ce qu'ils font ni quelle est la portée des modifications qu'ils peuvent faire dans certains fichiers de configuration. Combien de fois en ai-je vu qui bricolaient plus qu'ils administraient ? Qui appliquaient des recettes toutes faites sans vraiment savoir ce qu'ils faisaient ?

Et on s'étonne après ça d'avoir des serveurs qui tombent en vol, des sites internet comme le fameux france.fr notoirement sous-dimensionné, ce qui a coûté au contribuable le double de ce qu'il aurait dû coûter !

Quand est-ce que les gens comprendront qu'on ne fait pas administrer un serveur par le premier venu et que les données que l'on confie à un serveur ont un coût de gestion ? L'outil informatique est un outil dont la gestion n'est pas un coût marginal contrairement à ce qu'on voit trop souvent et qui aboutit toujours à plus ou moins long terme à des catastrophes. Croire le contraire est la pire erreur qu'on puisse faire.