Pour différentes raisons la base de données SQL qui permet de stocker toutes les informations nécessaires à faire tourner votre site (réglages et contenus) peut ne pas etre disponible quand un visiteur arrive sur votre site. On vous présente ici 2 solutions qui vous permettront d’éviter de perdre vos visiteurs.
En cas de problèmes SQL WordPress déclenche l’exécution du fichier db-error.php
Depuis la version 2.3.2 de WordPress il est possible de personnaliser le message d’erreur de connexion à la base de données.
Il suffit pour cela de créer un fichier db-error.php dans le dossier /wp-content/
Un message personnalisé et aux couleurs de votre site ce n’est pas mal mais on peut aller plus loin.
Afficher un écran d’attente et recharger la page quelques secondes plus tard
En effet ce message peut apparaitre par exemple quand le nombre de requêtes simultanées à votre base de données est trop important. Autrement dit quelques instants plus tard les mêmes requêtes pourront être lancées avec succès et la page sera affichée correctement.
Une solution très simple consiste alors à afficher un écran d’attente et à réessayer de se connecter quelques instants plus tard.
Pour que WordPress fonctionne ainsi, il suffit de mettre dans le fichier db-error.php les quelques lignes suivantes :
Trop d'utilisateurs sont actuellement connectés
Vous allez être redirigé(e) vers la page demandée, merci de patienter quelques instants.
Si la redirection automatique ne fonctionne pas cliquez ici
Charger le cache Google de la page recherchée
La méthode ci-dessus ne fonctionnera que si le problème d’affichage est effectivement lié à une surcharge temporaire de votre serveur SQL.
Seulement le plus souvent si la connexion à votre base de donnée est en échec, c’est que le serveur SQL est carrément planté. Autrement dit il y a peu de chances que ça se remette à fonctionner tout seul, et vos internautes vont voir la page d’attente boucler indéfiniment.
Une autre solution consiste à afficher non pas une page d’attente, mais la dernières version de la page que vous tentez d’afficher que Google a enregistré. C’est à peu près le meme mécanisme qu’utilise Cloudflare d’ailleurs avec sa fonction « Always online ».
Bien évidemment si vous avez indiqué à Google ne pas indexer la page en question, si elle est trop récente pour avoir été crawlée par Google ou encore si le moteur de recherche a estimé que cette page ne présentait pas assez d’intérêt pour etre sauvegardée, ça ne fonctionnera pas.
Par ailleurs si vous avez 2 templates différents pour les versions fixes et mobiles de votre site, c’est l’un des deux qui s’affichera et pas nécessairement celui qui correspond au mode de navigation courant de l’internaute. Mais bon c’est mieux que rien non ?
Voici le code alternatif que vous pouvez intégrer dans db-error.php :
$host=$_SERVER['HTTP_HOST'];
$uri=urlencode($_SERVER['REQUEST_URI']);
header("Location: http://google.com/search?q=cache:$host$uri");
exit();
Vos statistiques de visite continuent d’être justes
Si vous utilisez Google Analytics ou tout autre système de monitoring de votre trafic, le script en question continuera d’etre chargé via le cache Google.
Si vous regardez ce qui se passe dans l’onglet d’analyse en temps réel de Google Analytics, vous verrez apparaitre des URLs du type https://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.
Mise en place d’un système basique de Fast Recovery mySQL
Si les internautes peuvent continuer de surfer sur une page miroir, 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 :
crontab -eIl 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 :
*/5 * * * * /sbin/service mysql status >/dev/null 2>&1 || service mysql restartSeul 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
User-agent: *
Disallow: /server_sql_onlinePenseza aussi à interdire sa mise en cache par vos plugins de cache, et à déclarer des exceptions si vous utilisez Varnish ou NGINX.
Créons ensuite une exception dans le fichier db-error.php pour exclure cette page, le code devant donc etre légèrement modifié :
