Lovelive et Google

Bonjour,

Si vous êtes membre du site Lovelive ou simplement que vous passiez sur le site le 27 mars au matin, vous avez peut-être remarqué que le site ne répondait pas vraiment... À vrai dire, ce billet est plutôt destiné à donner un petit retour d'expérience aux petits webmasters comme je le suis, afin d'enrichir le web de quelques expériences et de solutions pour s'en sortir en cas de crise.

Le site Lovelive souffre depuis quelques jours de problèmes qui lui pendaient au nez depuis une année, et de problèmes relatifs à la nouvelle version du site. En voici une liste :

1. la partition système du serveur est pleine à craquer, alors que les répertoires /tmp, /var/log, ainsi que le cache apt ont été nettoyés ;
2. le site souffre d'un timeout de connexion, le serveur web ne peut pas communiquer avec le serveur d'applications ;
3. après reboot, mysql ne se lance plus et se plaint de ne pas trouver le fichier mysqld.sock (et plein d'autres problèmes empêchant de lancer mysql) ;
4. le site disparaît carrément de l'index Google sur la majorité des expressions sur lesquelles il se classait bien.

1. Partition système pleine à craquer

Depuis quelques mois, j'étais régulièrement obligé de faire de l'espace sur la partition système de mon serveur. En effet, il arrivait fréquemment que la partition système (réglée par défaut à 3Go, ce qui me semble désormais trop peu) soit remplie à plus de 90%, ce qui est assez dangereux. En effet, un disque système qui n'a plus un seul octet de libre aura beaucoup de problèmes à démarrer correctement.

Il m'arrivait de temps en temps d'ajouter quelques packages utiles au serveur, ce qui ajoutait par-ci par-là quelques mégaoctets au disque dur. Alors forcément, plus ces packages prenaient de place, plus il fallait faire le ménage souvent sur le disque. Également, il me fallait vérifier mes tables MySQL, et les optimiser (avec la commande OPTIMIZE DATABASE de MySQL) régulièrement pour être sûr de récupérer quelques mégaoctets très précieux.

Et cette dernière semaine, plouf, le disque de démarrage a atteint un remplissage de 100%. Premier effet : un des serveurs lancés habituellement plante ou ne se lance plus.

Sachant que les résultats de la commande htop (outil système destiné à vérifier la charge du système et du processeur) montraient une assez bonne santé du système, j'ai assez vite trouvé que le problème venait peut-être d'un problème de disque. Un appel à la commande df (disk fill, probablement) l'a confirmé. 100% utilisés sur la partition /.

Au vu de ces chiffres, direction immédiate vers le répertoire /var/log. Étonnamment, je n'ai pu libérer que 40Mo, alors qu'auparavant, dans les situations alarmantes, j'avais pour plus de 700Mo de logs à libérer. Après cette opération, il n'a fallu que 10 minutes pour que le problème se reproduise. Nettoyage du cache apt, suppression de quelques packages, rien n'y a fait. Et impossible de trouver ce qui prenait toute la place sur le disque, enfin pas tout de suite...

2. Serveur d'applications qui plante

L'effet du disque plein, c'est que de nombreux services du système se sont mis à lamentablement planter. Mais pas tous, alors on peut être induit en erreur. Mais ce qui nous intéresse le plus se trouve dans le point n°3.

3. MySQL ...[fail]

La chose la plus insupportable dans le problème, c'est qu'il devient impossible de démarrer MySQL et effectuer des opérations de maintenance.

Alors ce à quoi j'ai pensé, c'est à déplacer les fichiers de base de données de MySQL. Et c'est en regardant la place prise par ces fichiers que je me suis aperçu qu'ils avaient gonflé jusqu'à prendre 60% de la taille de la partition. L'objectif ici est alors de trouver comment reconfigurer un MySQL avec des bases existantes déplacées dans un autre répertoire.

Le but ici était alors de déplacer /var/lib/mysql vers un répertoire d'une partition peu occupée, sans mettre mon MySQL à sac. Voici la méthode que j'ai dû employer pour y parvenir.

• Déplacer var/lib/mysql vers la partition libre. Il est aussi possible de copier seulement, par sécurité, mais il faut faire très attention à conserver les permissions sur les fichiers lors de la copie.
• Si tout se passe bien, supprimer /var/lib/mysql.
• Ensuite, créer un lien symbolique (commande ln -s <nouveau répertoire> /var/lib/mysql), en ne mettant pas de slash (/) final dans le chemin du nouveau répertoire.
• En principe, vous n'avez même pas à modifier votre fichier de configuration my.cnf.
• Il vous suffit alors de relancer mysqld (ou lancer service restart mysql) et le tour est joué.
• Si malgré tout, le lancement de MySQL échoue, (pour un fichier mysqld.sock, ou un fichier mysql.plugin ou mysql.host) il faut supposer que comme moi vous avez oublié de conserver les bonnes permissions de fichiers en faisant la copie. Vous pouvez corriger le problème en changeant le propriétaire des fichiers du répertoire vers mysql.

Au final, c'est bien 1.7Go que j'ai pu libérer sur la partition principale. Et en plus, tout marche correctement (il a fallu réparer quelques tables MyISAM crashées, mais pas de gros bobo).

4. Le site se fait saquer dans tous les sens par Google

Cette section concerne les webmasters plus que les administrateurs système, et peut servir si l'on se demande encore concrètement ce que l'on risque à redévelopper un site. Même en prenant beaucoup de précautions, vous pouvez encore vous faire avoir par quelques erreurs, qui peuvent vous coûter votre place, voire votre présence (sur Google).

Lorsque le site vivait encore ses 8 dernières semaines avant la nouvelle version, j'ai décidé qu'il fallait absolument conserver un maximum d'URL et utiliser des redirections au maximum, afin de ne pas perdre le fruit d'un dur labeur. J'ai donc décidé, sur l'ancien site, un Drupal 6, de modifier les URLs pour qu'elles répondent au nouveau schéma d'URLs, et mettre automatiquement les redirections 301 qui allaient. Avec 8 semaines devant moi, et connaissant la vitesse que Google avait mis pour mettre à jour toutes les URLs d'un autre site, il était évident qu'au lancement de la nouvelle version, toutes les anciennes URLs ne seraient plus prises en compte par le moteur de recherche. Première erreur. En 8 semaines, le moteur n'avait mis à jour le chemin que de 20% des pages environ. Ce qui laisse 80% de pages à retrouver en 404.

Résultat : des milliers d'erreurs de crawling, des pages qui ont changé, ce qui fait que Google a carrément écarté le site de certains de ses résultats. Si la sentence peut être temporaire, il ne faut pas compter là-dessus et agir. En effet, c'est maintenant sur le nouveau site qu'il faut effectuer les redirections 301 que le temps n'avait pas permis au moteur de trouver (ouf !). Je me lance tout de suite là-dedans et vous donnerai l'état des améliorations.

À suivre.