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 :
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<meta name="robots" content="noindex,follow" />
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
<meta http-equiv="content-language" content="fr-FR" />
<meta http-equiv="refresh" content="8; url=/<?php echo $_SERVER['REQUEST_URI']; ?>">
<title>Nombre trop important d’utilisateurs connectés – Merci de patienter</title>
</head>
<body>
<h1>Trop d'utilisateurs sont actuellement connectés</h1>
<p>Vous allez être redirigé(e) vers la page demandée, merci de patienter quelques instants.</p>
<p>Si la redirection automatique ne fonctionne pas <a href="/<?php echo $_SERVER['REQUEST_URI']; ?>">cliquez ici</a></p>
</body>
</html>
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é :
<?php
/* On récupère le NDD et l'URL de la page demandée */
$host=$_SERVER['HTTP_HOST'];
$uri=urlencode($_SERVER['REQUEST_URI']);
/* Et on affiche le cache Google de cette page si ce n'est pas la page de test */
if ($uri ! = "server_sql_online") {
header("Location: http://google.com/search?q=cache:$host$uri");
exit();
} else {
header("Location: ".$host$uri");
exit();
}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 :
sql_status=$(/usr/bin/curl -sL $url -w "%{http_code}\\n" "http://mon-site.fr/server_sql_online/" -o /dev/null)
if (($sql_status ! = 200)); then
kill -HUP $(ps -A -ostat,ppid | grep -e '[zZ]'| awk '{ print $2 }')
pkill -9 -u `id -u uid_mon_site`
/sbin/service mysql restart
/sbin/service httpd restart
fiDans 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 :
*/10 * * * * /usr/bin/test_sql_server > /dev/null 2>&1Il ne nous reste plus qu’à relancer le service CRON avec l’une des deux commandes suivantes pour que nos modifications soient prises en compte :
crond restartou
/sbin/service crondEt voilà ! Bien évidemment on vous invite à analyser le log des erreurs SQL pour identifier un éventuel problème ou votre serveur se remettra à planter très rapidement …
- SQL poche pour les Nuls, 4e édition
- SQL par l’exemple: La pratique professionnelle des bases de données
