Blog Haypo

Étant donné que je suis en train de nettoyer mon site Internet, haypocalc.com, je vais en profiter pour en retracer son histoire.

Contenus hébergés

J'ai acheté le nom de domaine haypocalc.com ainsi qu'un hébergement chez OVH en décembre 2001 pour y publier ma calculatrice scientifique HaypoCALC. Ce logiciel restera le contenu essentiel du site web pendant plusieurs années.

J'ai ensuite hébergé deux sites Internet d'un ami (Nicolas Letavernier) : Le Système Solaire d'Exoscin et Généalogie des LETAVERNIER (sites hebérgés aujourd'hui sur son propre site, letavernier.com). Ami avec qui je suis d'ailleurs parti au Québec de Septembre à Décembre 2003. Ensemble nous avons monté un site Internet pour y narrer nos aventures : Notre aventure au Québec.

Enfin, le dernier gros événement est la création du blog que vous êtes en train de lire en mai 2006.

Vous trouvez les détails ainsi que mes autres sites Internet, anciens et actuels, dans mon article Mes sites web. La mémoire de l'Internet, archive.org, a conservé de nombreuses copies de mon site depuis sa création : consultez les archives d'haypocalc.com depuis 2002.

Évolutions technologiques

Le partie technique du site web où je publie mes articles d'informatique (de mathématiques et divers autres sujets) a connu trois grandes époques.

Au départ, j'écrivais mes articles sous forme de document HTML. Je me servais de l'éditeur Macromedia Dreamweaver 4 car j'appréciais de voir directement le résultat (principe d'un éditeur WYSIWYG). Un jeu de scripts PHP me permettaient d'ajouter un entête, un menu dynamique et un pied de page.

Émerveillé par les norme XML, XSLT et CSS, j'ai alors migré tout mon site sous forme de documents XML. Je voulais respecter la sacro-sainte rêgle « séparation du fond et de la forme » (dans mon cas : du texte et de la mise style). J'ai extrait le style pour rédiger une feuille de style CSS et j'ai écrit des outils XSLT pour générer du HTML à partir du XML. Les articles étaient écrits dans ma variante simplifiée du HTML.

Un jour j'en ai eu assez de passer plus de temps à développer des logiciels pour mon site web plutôt qu'à écrire des articles. J'ai alors décidé d'utiliser un outil existant pour me concentrer sur le contenu et j'ai choisi MediaWiki. J'ai découvert cet outil par l'encyclopédie Wikipédia et j'ai rapidement adoré l'édition en ligne par un simple clic. Depuis que j'utilise MediaWiki, j'ai réalisé que mon site web était plus actif. Je n'hésite plus à corriger mes fautes de frappes et à ajouter des informations à un article. Un autre avantage de MediaWiki est qu'il est toujours développé et je profite donc des mises à jour.

Publicité

Mon site haypocalc.com n'a jamais vu la moindre banière de publicité. Je me suis toujours refusé à me laisser tenter par cette pollution visuelle (Résistence À l'Agression Publicitaire). Pourtant, le traffic du site augmente continuellement. Je suis passé de 26.000 visiteurs en 2002 à 953.000 en 2006 pour atteindre aujourd'hui 3.700 visiteurs par jour. Il est tentant de gagner de l'argent en ajoutant des encarts publicitaires, mais je préfère préserver mes visiteurs pour un meilleur confort de lecture.

J'ai reçu récemment un email indiquant que ma base de donnée haypocalc.com atteignait 90% du quota de 25 Mo. J'ai rapidement suspecté mon wiki de monopoliser toute la place dans MySQL. Je sais que MediaWiki, logiciel gérant le wiki, est très gourmant en place : chaque révision d'une page est stockée intégralement dans la base de donnée et non pas juste les changements.

Changement de contrat

La première chose qui m'a choqué est que les termes de mon contrat OVH, une offre d'hébergement « 300GP » (GP pour Grand Public), avaient changé. Pour preuve, en 2003 l'offre comportait « espace MySQL illimité », alors qu'aujourd'hui il y a un quota de 25 Mo. Je n'ai pas été informé de ce changement. Il existe des options pour avoir 100 ou 250 Mo de base MySQL, mais ça se paie très cher : respectivement 72€ et 144€ (prix TTC par an). Un mauvais point pour OVH.

La grosse boulette

J'ai alors commencé par faire une sauvegarde de la base. Par expérience, j'ai appris à toujours sauvegarder avant de faire une opération délicate (susceptible d'être une connerie).

Pour faire le ménage dans le wiki, j'ai décidé de vider la table MySQL « wiki_text » qui semblait ne contenir que les anciennes versions. Les noms des colonnes de cette table sont préfixés par « old » (ancien) alors que pour la table « wiki_cur », les noms des colonnes sont préfixés par « cur » (current, actuel). Manque de bol, j'ai alors cassé le wiki : impossible de modifier une page (le formulaire d'édition était vide) !

Je réalise que j'ai fait une boulette : j'aurai du la renommer plutôt que de la vider.

Tentative de restauration du SQL par phpMyAdmin

Pour restaurer la base MySQL, je commence par la vider (supprimer toutes les tables) et j'utilise le phpMyAdmin d'OVH pour envoyer la sauvegarde. Sachant que la taille maximale de l'envoi est de 8 Mo (compressé ou non), je compresse mon dump SQL de 22 Mo avec gzip. Le fichier tient dans 4 Mo, la taille est bonne : je l'envoie. Premier échec : timeout PHP.

J'installe alors phpMyAdmin dans mon hébergement pour résoudre le problème de timeout. J'ai passé la première épreuve mais j'ai un nouveau soucis : la requête SQL s'interrompt. Il est possible de reprendre son exécution en réenvoyant le même fichier, sauf qu'après quelques étapes, c'est MySQL qui échoue. Décidément, rien ne fonctionne !

Concentration

À ce point là, la base de donnée MySQL de mon site était vide. Mon wiki et mon blog étaient donc hors-service depuis trois heures. Autre idée pour contourner les erreurs phpMyAdmin : j'écris un script Python pour découper le dump SQL de 22 Mo en petits bouts de 8 Mo. Nouvel échec. Je tente alors 6 Mo, 5 Mo, 4 Mo : rien à faire.

Finalement, je réunis tous mes neurones pour me souvenir que j'avais déjà eu ce même soucis quelques années auparavant. Pour les gros transferts SQL, il faut utiliser la commande « mysql » (en ligne de commande via un script PHP) après avoir envoyé le dump SQL par FTP. J'upload le dump et je lance la commande: ça marche !

Merde alors, si j'avais une meilleure mémoire, j'aurai gagné 4h :-( « Quand on n'a pas de tête, on a des jambes pour courir »

Migration à MediaWiki 1.10

Après de nombreuses heures, j'avais réussi à corriger ma boulette, mais mon soucis de taille de la base MySQL persistait. Entre temps, j'étais tombé sur l'article Help:Reduce size of the database de l'encyclopédie dédiée à Star Trek. En suivant les liens, j'ai vu que le problème est ancien et corrigé : il existe un script « maintenance/deleteOldRevisions.php » pour faire le ménage. Je récupère le script pour MediaWiki 1.6 par subversion et je le lance : erreur PHP (appel à une fonction non déclarée). Je comprend que ma version de MediaWiki est trop ancienne, il faut migrer à la nouvelle version.

Je prend mon courrage à deux mains et décide de migrer MediaWiki en version 1.10. C'est toujours une bonne idée niveau sécurité. Je récupère la base de donnée de mon wiki et l'installe dans un MediaWiki 1.10 neuf. Je lance le script « php upgrade.php --quick » (lu dans la documentation MediaWiki) et à mon grand étonnement, c'est un succès au premier essai !

Réduction de la base MediaWiki

Je peux enfin lancer « php maintenance/deleteOldRevisions.php --delete ». La commande dure longtemps, une dizaine de minutes, mais s'est terminée correctement.

Je renvoie ma base de donnée mise à jour et j'installe MediaWiki 1.10 sur haypocalc.com. Tout baigne.

Conclusion

Ce qu'il faut retenir : Pensez à faire des sauvegardes et assurez vous de pouvoir l'utiliser (avant de tout casser) !

Au total, j'ai du passer environ 6h sur mon problème en transpirant tout le long à grosses gouttes. Effectivement, j'avais supprimé volontairement six ans de boulot et j'étais incapable de le restaurer.

Je doute que ce billet intéresse grand monde, mais je me devais de l'écrire pour ne pas retomber dans les mêmes pièges ;-)