Quand un plugin fait planter le serveur mutualisé et l’hébergeur supprime mon compte

Si vous avez visité mon blogs à maintes reprises ces derniers jours, vous avez du tomber sur une série de messages,du type

  • Exceded CPU load
  • Problème avec la base de données MYSQL
  • Ce compte a été supprimé pour des raisons techniques

Phase 1) Mes premières réactions vis à vis de ces problèmes ont été d’appeler la hotline de mon hébergeur. La plupart du temps, c’était un problème de base de données du serveur et le système était réparé dans les 15 minutes.

Phase 2) La hotline m’a affirmé que j’avais un problème de base de données et qu’il fallait que je nettoie les bases de temps en temps ce qui a résulté par un billet  : Réparez vos bases de données SQL (débutant)

Phase 3) Mon compte, hier, a carrément était supprimé car je sollicitais trop mon serveur et faisait planter les autres noms de domaines hébergés sur le serveur!

Panique à bord, appel à la hotline, réponse de la hotline, certaines de mes bases n’ont pas d’index! (pour moi ça ne veut rien dire, mais globalement des bases non indexées ne sont pas des bases optimisées par conséquent, il y a plus de sollicitation sur le serveur, voir des requêtes qui tournent en rond et génére des milliers de requête, puis plante le serveur)

a) un bref aperçu dans l’un de mes fichiers dans le répertoire /tmp/mysql_slow_queries et je découvre que c’est un plugin qui pose des problèmes en lisant un des fichiers.

Voilà le charabia que j’ai lu « 

…LEFT JOIN wp_ak_popularity_contest…

Issu du plugin Popularity Contest (plugin qui permet de connaître quels sont les fichiers les plus lu)

b) Il a fallu ensuite aller dans la partie phpmyadmin et cliquer sur la base  wp_ak_popularity_contest et constater que la base n’avait pas d’index.

c) j’ai tout de suite désactivé le plugin, supprimé la base et supprimé les codes dans ma sidebar!

Conclusions

  • Avant de mettre en place un plugin, vérifier si une table est créée dans la base.
  • Notez bien quelle table a été créé lors de l’activation du plugin
  • Vérifier que la base est bien indexée
  • Regardez vos logs /tmp/mysql_slow_queries de temps en temps pour voir justement si quelque chose cloche
  • Si vous retirez le plugin définitivement, prenez soin de supprimer la table associée, car a priori, elle ne s’efface pas toute seule
  • Évidemment faite une sauvegarde journalière de vos bases de données à partir de PhpMyadmin.

Remarques et conseils

  • Créez vous un blog de test pour vous entrainer.
  • Testez vos plugins sur ce blog de test avant de le déployer sur votre blog.
  • Même si vous testez vos plugins sur un blog de test, vous ne pourrait par reproduier certains problème, du fait qu’il faut tester le plugin en charge. (votre blog de test est sensé ne pas faire de trafic, donc ne sollicité pas les bases de données de la même façon
  • Même si le plugin est un plugin réputé (popularity contest en est un) méfiez vous
  • Si vous avez un problème sur votre blog, essayer de reproduire le problème sur votre blog de test
  • Je ne suis pas un expert du domaine, je viens juste de vous énumérer ce que j’ai fait, un expert pourra éventuellement corriger!

Je remercie à Thierry.stiegler.fr Jbonnel.over-blog.com maigretsblog.com de m’avoir prévenu par twitt et un oscar pour blogmotion.fr qui a pu me demerder sur un problème annexe ! Vraiment sympa les gars.

Rendez vous pour le prochain plantage!

14 réflexions sur « Quand un plugin fait planter le serveur mutualisé et l’hébergeur supprime mon compte »

  1. C’est bien que tu ai réussis à récupérer tes données et à remettre en route le bouzin, c’est pas toujours le cas. 🙂

    On ne le répèteras jamais assez les sauvegarde c’est essentiel !

    Pierre

  2. Xhark, merci pour ta proposition, tu m’as déjà bien décrasser sur une autre histoire!
    Dabrush, en fait ils ont supprimé mon compte mais ils ont gardé les données, heureusement, car j’aurais été incapable de reprendre la main!

  3. Merci pour l’oscar 🙂
    En fait l’idéal c’est d’avoir un serveur dédié, au moins quand y’a un problème tu mets les mains dans les cambouit mais personne ne te supprime de données.

    Cela étant dit ce sont généralement des scripts qui s’occupent de ce genre de soucis, il ne faut donc pas s’étonner de la brutalité de l’action. Les humaines sont ***généralement*** plus compréhensifs. Je pense notamment aux clients des offres gratuites d’EG qui rencontrent ce genre de difficultés : on a plutôt tendance à corriger à leur place…

    Tu peux tout à fait recrée l’index très facilement (tu dois avoir un champ contenant « id » généralement). Au pire si tu as besoin d’aide tu sais ou frapper, ça ne doit pas prendre bcp de temps.

    Enfin on ne le répétera jamais assez : il faut TOUJOURS avoir des backups (récents…) !

  4. @Nohant, merci pour ton complément d’information, tes remarques sont importante. Effectivement un backup automatique, c’est important, j’en avais un, et j’ai essayé de restaurer les bases avec, ça n’a pas marché ! Alors je suis passé en manuel depuis! va falloir que je réétudie ce système bien plus pratique.
    @Aurelien, je pense que la panne a durée 6 heures, mais de bon matin!

  5. Heureusement que tout est rentré dans l’ordre maintenant…
    Je n’ai même pas eu le temps de voir la panne pourtant je viens souvent sur ton blog.

  6. Salut,

    Quelques remarques de profane :

    Vérifier que la base est bien indexée => ça ne veut rien dire en soit, on indexe des champs d’une table mais pas tous, uniquement ceux qui seront nécessaires dans les requêtes car l’indexation a un coût CPU et ralenti a contrario les mises à jours. Il faut donc étudier les champs (ou combinaison de champs) à indexer.

    Si vous retirez le plugin définitivement, prenez soin de supprimer la table associée, car a priori, elle ne s’efface pas toute seule => encore heureux d’ailleurs, en même temps à partir du moment où elle n’est plus utilisée par le plugin ça n’a pas d’impact (à part d’occuper de la place sur le disque) car elle n’est plus mise à jour ni consultée.

    Évidemment faite une sauvegarde journalière de vos bases de données à partir de PhpMyadmin. Ou installer un plugin wordpress comme WordPress automatic backup qui fait ça tout seul et vous l’envoi par mail c’est plus pratique http://www.ilfilosofo.com/blog/wp-db-backup

    une bonne source d’information sur ce sujet passionnant Frédéric Brouard http://sqlpro.developpez.com/

    Cordialement,

  7. @Karim, je viens de changer de mot de passe, j’en ai oublié l’essentiel
    @Olivier, effectivement le compte fermé sans préavis, c’est quand même assez violent!

  8. NON, sauf intervention manuel sur la table ou scripte ayant les droits.
    essaye de changer le mot de passe de ta base au plus vite.

  9. Ma2thieu bonne année à toi! et bonne sauvegarde
    Karim, je pense qu’au départ la table possédait un index, le plugin est réputé, j’ai juste l’impression que l’index a disparu, (c’est possible ça!?)

  10. n’oublie pas que tu es comme un pilote d’essai, c’est toi qui reçois tous les bug zero day en pleine figure.
    Mais l’aventure vaut la peine.
    Une table sans index !!!! c’est un informaticien le gars ?

  11. Bonjour Thierry!

    Comme je ne crois pas avoir eu l’occasion de te souhaiter tous mes voeux pour 2009.
    J’espère que tu te remets de tes émotions… en tout cela devait être la panique à bord!!
    Je crois que je vais lancer un sauvegarde de ma base ce soir!!

Les commentaires sont fermés.

Pin It on Pinterest

Share This

Share This

Share this post with your friends!