La migration du site SynerGeek.fr est terminée mais je ne peux pas dire qu’elle s’est faite sans douleur !
La plus grosse difficulté à régler était le problème d’encodage des tables… au moment de la restauration de la base, tous les caractères accentués ont été transformé dans des caractères “pas catholiques” 😉
Je ne vais pas rentrer dans les détails sur l’encodage et le nombre de bits par caractère, mais maintenant toutes les tables sont en “pur UTF8” et interclassement utf8_general_ci.
Comme pour un déménagement dans la vie réelle, une migration est toujours un bon moment pour faire le ménage. Cette fois, j’ai supprimé une bonne vingtaine de tables qui n’était plus utilisées.
En informatique, tout problème a une solution (en théorie) et quand on est confronté à un problème et qu’on le résout (il faut parfois une bonne dose de ténacité), on s’en sort grandi dans ses compétences.
MySQL
Cette fois, c’est sur la manipulation de base de données MySQL dans laquelle il m’a fallu trifouiller, modifier des données, exporter, importer… alors je vais vous donner quelques tuyaux qui m’ont bien été utile.
Même si j’utilise beaucoup phpmyadmin pour les tâches courantes, importer les bases en ligne de commande via ssh est beaucoup plus sûr et surtout beaucoup plus rapide.
Une fois les manipulations réalisées sur mon ordinateur en local, je transfère la base de données “fichier.sql” par FTP sur le serveur distant et ensuite je lance la commande :
mysql -u utilisateur -pmotdepasse nom_base < fichier.sql
- utilisateur est le nom d’utilisateur qui a les droits sur la base
- motdepasse est le mot de passe de cet utilisateur (il doit être collé au “-p”)
- nom_base est le nom de la base dans laquelle on va importer les données
Voici quelques requêtes à lancer dans phpmyadmin pour retrouver les caractères accentués. Dans cet exemple, ce sera uniquement sur la table “wp_posts” qui contient tous les articles d’un site WordPress et agir sur les colonnes post_title, post_excerpt et post_content
[shell]update wp_posts set post_title=replace(post_title,”é”,”é”);<br />update wp_posts set post_title=replace(post_title,”à”,”à”);<br />update wp_posts set post_title=replace(post_title,”ê”,”ê”);<br />update wp_posts set post_title=replace(post_title,”ô”,”ô”);<br />update wp_posts set post_title=replace(post_title,”â”,”â”);<br />update wp_posts set post_title=replace(post_title,”è”,”è”);<br />update wp_posts set post_title=replace(post_title,”ï”,”ï”);<br />update wp_posts set post_title=replace(post_title,”î”,”î”);<br />update wp_posts set post_title=replace(post_title,”é”,”é”);<br />update wp_posts set post_title=replace(post_title,”û”,”û”);<br />update wp_posts set post_title=replace(post_title,”ç”,”ç”);<br /><br />update wp_posts set post_excerpt=replace(post_excerpt,”é”,”é”);<br />update wp_posts set post_excerpt=replace(post_excerpt,”à”,”à”);<br />update wp_posts set post_excerpt=replace(post_excerpt,”ê”,”ê”);<br />update wp_posts set post_excerpt=replace(post_excerpt,”ô”,”ô”);<br />update wp_posts set post_excerpt=replace(post_excerpt,”â”,”â”);<br />update wp_posts set post_excerpt=replace(post_excerpt,”è”,”è”);<br />update wp_posts set post_excerpt=replace(post_excerpt,”ï”,”ï”);<br />update wp_posts set post_excerpt=replace(post_excerpt,”î”,”î”);<br />update wp_posts set post_excerpt=replace(post_excerpt,”é”,”é”);<br />update wp_posts set post_excerpt=replace(post_excerpt,”û”,”û”);<br />update wp_posts set post_excerpt=replace(post_excerpt,”ç”,”ç”);<br /><br />update wp_posts set post_content=replace(post_content,”é”,”é”);<br />update wp_posts set post_content=replace(post_content,”à”,”à”);<br />update wp_posts set post_content=replace(post_content,”ê”,”ê”);<br />update wp_posts set post_content=replace(post_content,”ô”,”ô”);<br />update wp_posts set post_content=replace(post_content,”â”,”â”);<br />update wp_posts set post_content=replace(post_content,”è”,”è”);<br />update wp_posts set post_content=replace(post_content,”ï”,”ï”);<br />update wp_posts set post_content=replace(post_content,”î”,”î”);<br />update wp_posts set post_content=replace(post_content,”é”,”é”);<br />update wp_posts set post_content=replace(post_content,”û”,”û”);<br />update wp_posts set post_content=replace(post_content,”ç”,”ç”);<br />update wp_posts set post_content=replace(post_content,”‘”,”‘”);[/shell]
Editer des gros fichiers
La base du site SynerGeek.fr fait environ 50 Mo et il n’est pas si facile d’ouvrir et surtout d’utiliser des fonctions chercher/remplacer avec un éditeur de texte classique. Que ce soit sur Mac avec Smultron ou sur PC avec Notepad+ cela faisait planter l’appli.
J’ai donc cherché et trouvé un logiciel sur Mac, idéal pour manipuler de gros fichier: MacVim, que vous pouvez télécharger ici (et il existe aussi sur d’autres OS: PC, Unix et même Amiga ou OS/2 !!!)
Petite parenthèse… A l’heure actuelle on l’on manipule des dizaines de Go voire de To, comment se fait-ce qu’il ne soit pas plus facile d’éditer un fichier de quelques dizaines de Mo ??
Maître Olivier, aurais-tu une explication à nous donner sur cet état de fait ? 😉
Quoiqu’il en soit, le site SynerGeek.fr a trouvé une place au chaud sur un serveur Dell 1950, bi-processeur quad core Intel E5310, 7 Go de Ram, 2 disques SATA de 750 Go sous PROXMOX, un hyperviseur libre. Ce serveur va nous permettre ainsi de virtualiser des distrib, réaliser des tests etc… On aura sûrement l’occasion d’en reparler.
SynerGeek.fr Informatique & Veille Technologique
“Editer des gros fichiers” – “La base du site SynerGeek.fr fait environ 50 Mo…”
Ce n’est pas franchement un gros fichier xD
Oui, je pense qu’il suffisait de changer la collation de la base avant de réimporter les données.
C’est ce que j’ai fait finalement… mais avant ce que j’ai lu sur le sujet n’était pas franchement clair. c’est un des problèmes d’Internet c’est que dans la masse d’informations que l’on peut trouver à partir d’une recherche, il y a un tas de “vieilleries” qui ne sont plus d’actualités à l’heure actuelle? Faut vraiment faire le tri!
Bien joué pour la migration !
Un éditeur de texte pour les gros fichiers ? Ben, tout simplement parce que ça ne sert à rien !
Tu parles de 50mo, mais c’est le SQL exporté et non le poids réel de toutes les données.
Selon le moteur de stockage utilisé tu peux utiliser plusieurs formes d’export. Généralement c’est MyISAM qui est utilisé mais pour des raisons techniques on peut utiliser InnoDB et plein d’autres ! (dont par exemple CSV qui va tout simplement stocker sous forme de CSV, ou encore un autre moteur qui va stocker les données en mémoire vive pour la rapidité).
A mon avis, il y avait plus facile comme méthode quand je lis ceci :
http://www.devcha.com/2008/03/convert-existing-mysql-database-from.html
L’erreur de l’export en SQL (dans son implémentation), c’est qu’il ne dissocie pas la création des tables de l’import des données. En modifiant juste la création des tables tu aurais été tranquille.
félicitation et merci de ton travail.
Je ne justifierai pas la raison pour laquelle il n’existe pas d’éditeur de texte pouvant ouvrir des fichiers de 1To. Quand tu vois qu’une bible pèse à peine 1Mo, quel être humain voudrait éditer un fichier de 1To?
Personnellement, au dessus d’une certaine taille de document, j’utilise sed ou j’écris mon propre programme de traitement.
Ok mais entre 1 To et 50 Mo il y a quand même une sacré différence.. pourquoi un simple search and replace fait planter quasiment une bécane ?
Content de savoir que ce site va perdurer.
un sed ou un iconv sur le dump n’aurait’il pas été plus rapide ?
Peut-être mais je ne connais pas ces commandes… les précédentes migrations se sont passées plus ou moins bien… mais quand un site prend de l’ampleur ça devient plus difficile de faire la jonction… bon c’est comme tout il aurait fallu mieux préparer avant !