WordPress : le guide ultime pour contourner les plantages SQL

Je n’ai aucune formation en informatique (je suis ingénieur en mécanique) mais je suis un gros bidouilleur. Par conséquent je torture systématiquement mes ordinateurs, téléphones et divers joujous pour rajouter telle ou telle fonctionnalité (que je n’utiliserai jamais) ou les booster (sans effet visible à l’œil nu).
Bien évidemment j’ai le même défaut quand il s’agit de sites web mais avec des effets de bords nettement plus importants.

Des plantages SQL dus à des attaques de hackers

Je vous passerai le détails de toutes mes catastrophes informatiques pour faire un focus sur un problème que je rencontre sur mon serveur dédié.
Depuis l’an dernier le serveur SQL qui fait tourner tous mes sites WordPress plante très régulièrement, rendant tous les sites inaccessible parfois pendant plusieurs heures.

Après optimisations et diverses fouilles dans les logs j’en suis arrivé à la conclusion que – pour une fois – les plantages ne sont pas de mon fait, mais liés à des attaques.
Le serveur est protégé par Cloudflare + CSF +Fail2ban + Jetpack + d’autres scripts ou plugins, mais n’étant pas expert en admin sys il reste des trous dans la raquette.

En attendant de renforcer la sécurité du serveur, je partage avec vous la rustine que j’ai mise en place pour que ces plantages passent (presque) inaperçus.

Redirection de l’internaute vers le cache Google de la page demandée

Attention, si cette solution permet de masquer le(s) problème(s) elle ne résout évidemment rien. Si vous avez régulièrement des plantages SQL encore non expliqués, vous devrez tout de même continuer à investiguer ou vous risquez tôt ou tard de subir un plantage bien plus grave !

Je vous ai déjà parle de wp-error.php il y a bien longtemps dans un articles qui parlait de contourner les erreurs de connexion à votre base de données. En cas de problème de connexion à votre base SQL ce script que vous pouvez créer dans le répertoire /wp-content/ sera exécuté par WordPress.

Plutôt que de signaler un plantage à l’internaute – info sans intérêt – nous pouvons regarder si notre ami Google n’a pas mis la page demandée en cache.
Si c’est bien le cas on va donc afficher ce cache.

Pour afficher le cache Google d’une page il suffit de renseigner une adresse de la forme : http://google.com/search?q=cache:url_de_la_page

Notre petit fichier wp-error.php va donc contenir ces quelques lignes de code :

Si vous utilisez Cloudflare cette astuce vous est déjà familière puisque c’est précisément ce que fait le service en cas de plantage, en tapant dans son propre cache. Comme vos images sont de plus en cache sur le CDN Cloudflare vous devriez avoir des pages parfaitement lisibles.

Vos statistiques Google Analytics continuent d’être justes

Cerise sur le gâteau, si vous utilisez Google Analytics, si les pages visibles dans la section temps réel seront de type http://google.com/search?q=cache:url_de_la_page mais c’est bien les page ciblées qui seront loggées dans l’outil, puisque le tag Google Analytics pointera sur les URL mises en cache. Pour les pages qui ne sont pas en cache vous aurez un petit message moche de ce type 404 Google :

Error_404

J’ai bien tenté de scrapper le cache Google (avec file_get_contents ou curl) pour intercepter le message et afficher une alternative personnalisée si on tombe sur une 404, mais Google n’aime visiblement pas les scrappeurs et il m’a systématiquement bloqué. Si vous avez une idée je suis preneur …

En attendant nous nous contenterons de ça, ce qui devrait couvrir 99% des requêtes si vous avez un site de contenu, ce qui est probable sous WordPress.

Mise en place d’un système (basique) de Fast Recovery SQL

C’est bien beau tout ça, l’internaute peut surfer sur une page miroir, mais pendant ce temps le serveur est tout de même planté.
Pour tester et relancer le serveur SQL nous allons créer une tâche CRON avec un compte admin, ce qui est pour des raisons évidentes de sécurité impossible depuis cPanel ou WHM.

Connectez-vous en SSH à votre serveur nous allons éditer la table CRON “à la main”. Pour ce faire, une fois connecté via un compte admin, saisissez la commande

Il vous suffit ensuite de rajouter vos tâches CRON, de sauver le tout avec ^X.

Nous allons tester toutes les 5 minutes si le serveur SQL est arrêté. Si c’est le cas on le démarre.
Voici donc la ligne à rajouter :

Seul hic : lors de la plupart des plantages le serveur tourne encore, le problème résidant au niveau de la connexion à la base de données et non du moteur en lui-même.
Nous allons donc tester le temps de chargement d’une page en s’assurant qu’on ne retombe pas sur une page “en cache”.

Créons une page à cet effet via WordPress : elle ne pourra donc s’afficher correctement que si le serveur SQL est online.
Appelons-la server_sql_online et interdisons son indexation par Google via le fichier robot.txt en rajoutant la ligne suivante :

Créons ensuite une exception dans le fichier wp-error.php pour exclure cette page :

Si on requête cette page alors que le serveur SQL est crashé ça va donc mouliner dans le vide.
La page renverra donc un code différent de 200, puisque la page ne sera pas affichée avec succès.

Créons un petit script que nous appellerons test_sql_server et que nous allons loger dans /usr/bin :

Dans le script ci-dessus pensez bien à remplacer http://mon-site.fr par l’url de votre site, et uid_mon_site par l’UID linux de votre site.

Rajoutons maintenant un appel à ce script toutes les 10 minutes dans le CRON :

Il ne nous reste plus qu’à relancer le service CRON avec l’une des deux commandes suivantes pour que nos modifications soient prises en compte :  

ou

Et voilà !

Ça ne me dit toujours pas d’où viennent mes problèmes mais au moins l’impact internautes est réduit.
Vos avis et remarques sont les bienvenues, surtout si vous voyez des améliorations à apporter à cette solution technique un peu cracra 😉

Un grand merci à Pascal Parole qui m’a bien aidé pour la partie script !

WordPress : le guide ultime pour contourner les plantages SQL

Vous avez un projet ?

Parlons-en ensemble

Nous contacter

Partager cet article

Noter cet article

Fabien Elharrar - 303 articles

Consultant en acquisition d’audience, monétisation web et growth hacking.

157 solutions pour monetiser votre blog
RECEVOIR LES MEILLEURS ARTICLES
JE M'ABONNE
Lire les articles précédents :
La fausse bonne idée : pire ennemie de la startup et du créateur d’entreprise

Fermer