Distinguer la panne Redis de la base principale de WordPress
Le site ou la connexion à l’administration affiche « Error establishing a Redis connection ». Redis sert ici de cache objet persistant : il conserve des résultats réutilisables entre plusieurs requêtes. Cette panne ne signifie pas que les articles ont disparu de MySQL ou MariaDB. Ne remplacez pas les identifiants de la base principale pour tenter de corriger une erreur qui nomme Redis.
Le résultat recherché se déroule en deux temps : retrouver un fonctionnement contrôlé sans ce cache si nécessaire, puis corriger sa connexion et le réactiver. Le contournement temporaire ne remet pas le service Redis en état. Il peut augmenter le travail de la base de données ; il faut donc surveiller le site pendant cette période.
Le parcours vise une installation auto-hébergée où le cache est géré par Redis Object Cache ou par un prestataire identifié. Sur WordPress.com ou une offre gérée, les fichiers et le service peuvent être sous contrôle de la plateforme. Dans un multisite, le cache et sa configuration peuvent concerner plusieurs sous-sites : l’intervention doit être préparée à cette échelle.
Préparer l’accès aux fichiers et conserver l’erreur précise
Relevez le message exact, l’heure, le domaine et la dernière modification connue : migration, changement de secret, maintenance Redis ou mise à jour de composant. Conservez les détails dans un dossier privé. Une capture de diagnostic peut révéler un nom de serveur interne ou des paramètres ; elle ne doit pas être publiée sans relecture.
Préparez un accès SFTP ou au gestionnaire de fichiers qui fonctionne indépendamment de WordPress. Sauvegardez en privé le fichier de configuration et le drop-in de cache avant modification. Une sauvegarde de données récente reste nécessaire pour les travaux plus larges, mais cette procédure ne demande ni restauration SQL ni suppression de contenu pour commencer.
Lorsque le site est déjà indisponible, un contournement ciblé peut servir au rétablissement. Notez son heure et les opérations réalisées pendant cette période. Des clés Redis anciennes peuvent subsister alors que des données WordPress changent sans les invalider : la réactivation devra traiter cette incohérence. Pour comparer des configurations ou des versions, utilisez une copie dont les effets externes sont neutralisés et dont le cache est isolé de la production.
Identifier le fichier qui fournit réellement le cache objet
WordPress peut charger un fichier spécial nommé object-cache.php dans son répertoire de contenu. Ce drop-in est distinct du dossier ordinaire d’une extension. Le répertoire est souvent wp-content, mais il peut avoir été déplacé par la configuration. Vérifiez le chemin réel du site et la valeur de WP_CONTENT_DIR si elle est personnalisée.
Ouvrez une copie du fichier en lecture seule et examinez son en-tête : nom, éditeur et adresse du composant. Le drop-in de Redis Object Cache annonce son identité. S’il appartient à un autre outil ou au prestataire, utilisez leur procédure, car une constante prévue pour ce plugin ne s’applique pas à tous les caches Redis.
Ne renommez pas tout le dossier des extensions pour cette panne. Un drop-in peut encore être chargé même si le dossier de son extension n’est plus accessible. Inversement, désactiver normalement une extension peut déclencher ses opérations de nettoyage. Identifiez le propriétaire et le mécanisme avant de choisir une action. Le simple nom object-cache.php ne permet pas de savoir qui a installé le fichier ni quelles données le service partage.
Choisir un contournement qui ne vide pas une base partagée
Si l’administration reste ouverte, Réglages, Redis permet d’observer l’état du cache. Ne choisissez pas automatiquement Flush Cache ou Disable Object Cache pour diagnostiquer une connexion. Dans Redis Object Cache 3.0.0, la désactivation depuis l’interface retire le drop-in puis tente de vider la base Redis utilisée. En cluster, cette action peut viser les nœuds maîtres. Un préfixe de clés différent pour chaque site ne protège pas les autres données de cette purge de base.
Si le prestataire confirme que tout le périmètre visé est réservé à ce cache et valide sa purge, le bouton Disable Object Cache constitue son parcours d’interface. Conservez d’abord le fichier et l’état initial, appliquez une seule fois, puis vérifiez l’accès au site. Le retrait réussi du drop-in ne prouve pas que la purge distante a abouti si Redis était inaccessible. La réactivation avec Enable Object Cache reste donc soumise au contrôle de cohérence décrit plus loin. Une purge déjà effectuée ne peut pas être annulée par ce bouton.
Lorsque le partage ou l’impact n’est pas établi, préférez le contournement par constante prévu pour ce drop-in identifié. Il permet de revenir au fonctionnement sans cache persistant sans demander de vider la base. Si vous n’avez pas les droits sur les fichiers, faites appliquer cette opération précise par le responsable plutôt que de tester plusieurs boutons de nettoyage.
Utiliser la constante de secours du drop-in identifié
- Cette méthode convient au drop-in confirmé de Redis Object Cache qui prend en charge
WP_REDIS_DISABLED. Avec votre accès aux fichiers, ouvrez lewp-config.phpréellement utilisé et gardez sa copie en privé. Recherchez une définition existante de cette constante. Si elle existe, modifiez sa valeur ; n’en ajoutez pas une deuxième qui entrerait en conflit. - Si elle est absente, placez la ligne ci-dessous dans la partie des réglages personnalisés, avant le chargement de
wp-settings.php, sans modifier l’ouverture PHP ni les autres constantes. Utilisez la valeur booléennetrue, sans guillemets. Enregistrez puis ouvrez une nouvelle requête vers l’administration et une page non servie seulement depuis un ancien cache de page. - Le résultat attendu est le retour de l’accès avec Redis contourné. Si une erreur de syntaxe apparaît, restaurez aussitôt le fichier conservé. Si l’erreur Redis reste identique, vérifiez le fichier chargé et le propriétaire du drop-in au lieu de multiplier les constantes. Après réparation du service, remettez la valeur initiale ou retirez seulement la ligne ajoutée, selon la procédure de réactivation décrite plus loin.
define( 'WP_REDIS_DISABLED', true );Retirer temporairement le seul drop-in lorsque cette voie est nécessaire
- Cette variante demande un accès fichier et la confirmation que le propriétaire autorise le retrait de son drop-in. Elle sert lorsque la constante n’est pas prise en charge ou que le prestataire demande ce mécanisme. Gardez d’abord une copie privée de
object-cache.php, avec son chemin, son identité et ses permissions. Ne retirez pas un fichier d’un autre cache sur la seule base de son nom. - Depuis SFTP ou le gestionnaire de fichiers, déplacez ce seul fichier vers un emplacement privé préparé hors du répertoire public. L’objectif est que le chemin exact de chargement ne contienne plus
object-cache.php, sans supprimer l’original. Ne déplacez niadvanced-cache.php, ni le dossier entier de contenu, ni la configuration de la base principale. - Ouvrez une nouvelle requête et vérifiez le retour du site. Si le fichier revient automatiquement, un outil de gestion le régénère : arrêtez les retraits répétés et faites intervenir son propriétaire. Pour revenir à l’état initial, remettez la copie confirmée à son chemin exact, seulement après réparation Redis. Ce retour réactive potentiellement la dépendance qui bloquait le site ; préparez le même accès de secours.
Lire les diagnostics du plugin déjà présent
Redis Object Cache est publié par Till Krüss. La version documentaire relevée est 3.0.0 ; elle annonce WordPress 4.6 et PHP 7.2 au minimum, testé jusqu’à WordPress 7.1.4. Ces informations décrivent l’état déclaré du composant, sans constituer un test de votre installation. Une nouvelle installation du plugin ne crée pas à elle seule un serveur Redis disponible. Ces anciens minima techniques ne recommandent pas de conserver une version PHP non maintenue.
Quand l’accès est revenu, ouvrez Réglages, Redis et consultez l’état puis l’onglet Diagnostics. En multisite, passez par Mes sites, Administration du réseau, Réglages, Redis avec les droits réseau nécessaires. Relevez la version du drop-in, le client utilisé et les détails de connexion utiles. Un état désactivé par constante est attendu pendant le contournement. Ne confondez pas cet état volontaire avec une nouvelle preuve de panne du service.
Gardez le diagnostic intégral en privé et partagez seulement les éléments nécessaires après masquage des secrets. Si le plugin indique un drop-in invalide ou appartenant à un autre outil, ne forcez pas son remplacement. Identifiez d’abord le propriétaire. Une différence entre la version du plugin et celle du fichier peut demander une mise à jour contrôlée sur copie, mais elle ne justifie pas de remplacer un fichier administré par l’hébergement.
Vérifier l’adresse, le port et le transport réellement attendus
Comparez la configuration du site avec les informations privées du prestataire : hôte Redis, port, transport TCP ou TLS, et éventuellement chemin de socket Unix. Le mot hôte désigne ici le service Redis, pas nécessairement le serveur de la base WordPress. Une migration peut avoir conservé une adresse qui n’est plus joignable depuis le nouveau moteur PHP.
Dans wp-config.php ou dans la source de configuration gérée, retrouvez les paramètres existants du cache. Pour Redis Object Cache, ils peuvent notamment être définis par WP_REDIS_HOST, WP_REDIS_PORT, WP_REDIS_SCHEME ou WP_REDIS_PATH. N’ajoutez pas un second ensemble si le prestataire injecte déjà ces valeurs ailleurs. Comparez chaque valeur avec le contrat de connexion actuel avant toute modification.
127.0.0.1 désigne l’environnement local du processus qui se connecte ; dans un conteneur, ce n’est pas automatiquement le service Redis voisin. Un port ne détermine pas universellement l’usage de TLS. Avec TLS, vérifiez également le nom du serveur et la confiance du certificat. Ne désactivez pas cette vérification pour transformer une erreur de transport en connexion apparemment réussie.
Distinguer authentification et permissions sur les commandes
Un message NOAUTH indique qu’une authentification est requise. Une erreur de mot de passe ou d’utilisateur demande la comparaison avec le secret Redis actuel et son compte, sans toucher au mot de passe MySQL. Faites cette vérification par le canal privé du prestataire. Ne placez pas le secret dans une capture, une URL de diagnostic ou un ticket public. Redis Object Cache accepte notamment WP_REDIS_PASSWORD sous forme de chaîne ou de tableau utilisateur/mot de passe pour une ACL : faites confirmer la forme déjà attendue, sans recopier un exemple de secret dans la configuration.
Un message NOPERM peut apparaître après une connexion authentifiée : le compte n’a pas le droit d’exécuter une commande ou d’accéder aux clés demandées. Les ACL de Redis sont des règles qui peuvent limiter ces deux périmètres. Faites rapprocher la commande refusée, l’utilisateur attendu et les besoins documentés du client de cache.
Ne répondez pas par l’attribution de tous les droits à tous les comptes. Une correction doit porter sur le compte et le périmètre nécessaires, avec la règle initiale conservée par le responsable. Après modification, la disparition de NOAUTH ne suffit pas : la lecture et l’écriture de cache nécessaires doivent encore fonctionner. Un compte peut répondre à un test de connexion tout en étant refusé pour l’usage réel de WordPress.
Tester la joignabilité sans écrire ni vider le cache
Si le responsable dispose déjà de redis-cli, il peut exécuter PING depuis le même environnement réseau que PHP. Un test depuis son poste personnel ne valide pas le trajet du site. L’exemple ci-dessous vise une connexion TCP avec authentification ACL ; remplacez l’hôte fictif, le port et l’utilisateur par les valeurs confirmées. Le mot de passe est demandé de manière masquée avec --askpass.
Si le service utilise TLS, ajoutez --tls et les paramètres de confiance requis par le prestataire. S’il utilise un socket, employez son parcours correspondant plutôt que cet exemple TCP. N’ajoutez pas un mot de passe dans les arguments visibles. Cette commande ne crée aucune clé et ne purge aucune base.
PONG indique que cette connexion a reçu une réponse. Cela ne valide pas toutes les permissions du cache, la configuration du client PHP ou la destination utilisée par WordPress. Conservez le résultat avec l’origine du test et l’heure. Une erreur de résolution, de refus de connexion, de certificat ou d’authentification oriente vers des corrections différentes.
redis-cli -h redis.exemple.invalid -p 6379 --user utilisateur-cache --askpass PINGTraiter MISCONF et READONLY au niveau du service
Un message MISCONF mentionnant l’impossibilité de sauvegarder un instantané RDB sur disque demande l’examen de la persistance par le responsable Redis. Le service peut refuser des écritures à la suite de cet échec. Faites vérifier ses journaux, l’espace disponible, les permissions et les ressources nécessaires à l’opération qui a échoué.
Ne désactivez pas automatiquement la persistance ou son mécanisme d’arrêt des écritures pour remettre un seul site en ligne. Le service peut héberger d’autres données dont la conservation importe. Maintenir temporairement WordPress sans ce cache évite de transformer un problème d’accès au site en changement global de politique Redis. Le responsable du service choisit le correctif et contrôle la reprise des opérations attendues.
Un message READONLY peut signaler une connexion à une réplique qui refuse les écritures. Faites vérifier le point de connexion attendu et un éventuel basculement de rôle. La correction consiste à retrouver le service ou le routage prévu pour le cache, pas à rendre arbitrairement la réplique inscriptible. Augmenter un délai de connexion ou vider des clés ne corrige ni un rôle de réplication incorrect ni un échec de persistance.
Corriger la connexion et préparer un cache cohérent
Une fois la cause identifiée, modifiez seulement le paramètre confirmé dans la source effective. Conservez l’ancienne définition et évitez les blocs contradictoires. Pour un secret injecté, utilisez le mécanisme du prestataire. Sur une copie au cache isolé, vérifiez le transport et le type de client réellement utilisés. En cas d’erreur PHP, restaurez le fichier préservé et maintenez le contournement.
Avant de retirer ce contournement, traitez les clés présentes avant la panne. Pendant que WordPress utilisait son cache interne, des modifications ont pu être enregistrées sans mettre à jour Redis. Ces anciennes valeurs ne deviennent pas automatiquement correctes au retour du service ; certaines clés peuvent ne pas expirer. Faites confirmer la suppression limitée à l’espace de clés de cette installation ou de tout le réseau multisite concerné, avant qu’il soit relu.
Si cette invalidation ciblée n’est pas disponible, le mainteneur peut préparer un préfixe neuf avec WP_REDIS_PREFIX, pris en charge par ce drop-in. Il doit être unique, stable et commun aux instances qui desservent la même installation, ou au réseau entier en multisite. Relevez le préfixe courant, vérifiez les permissions ACL sur le nouveau, puis modifiez sa définition unique dans la configuration avant la reconnexion. Gardez le contournement actif sur toutes ces instances pendant la bascule. N’utilisez pas une valeur aléatoire différente à chaque requête.
Ce changement ne supprime pas les anciennes clés : leur retrait doit être planifié séparément avec le responsable, notamment pour éviter une occupation mémoire durable. Ne réactivez pas ensuite l’ancien préfixe sans en vérifier la cohérence. Si la préparation échoue, gardez Redis contourné. Les options non prises en charge WP_REDIS_GRACEFUL ou WP_REDIS_SELECTIVE_FLUSH ne constituent pas un raccourci garanti. Une purge de base entière reste réservée à un périmètre dédié et expressément confirmé ; aucun changement de connexion ne demande de restaurer toute la base WordPress.
Réactiver le cache et vérifier de nouvelles requêtes
Quand le responsable confirme la connexion et la cohérence de l’espace de cache, préparez le retour avec l’accès fichier toujours ouvert. Si vous avez ajouté WP_REDIS_DISABLED, retirez cette seule ligne ou restaurez sa valeur initiale. Si vous avez déplacé le drop-in, remettez la copie conforme au chemin prévu. Si le cache avait été désactivé par l’interface, utilisez Enable Object Cache après les mêmes contrôles. La disparition de l’erreur de connexion ne suffit pas à autoriser la réutilisation d’anciennes clés.
Ouvrez ensuite une nouvelle requête vers l’administration et consultez l’état Redis. Vérifiez que le contournement n’est plus indiqué et que la connexion attendue est active. Comparez une page publique et un écran d’administration, puis une modification réversible sur copie avec relecture de sa valeur. Une page déjà conservée par un cache de page ne prouve pas que PHP rejoint Redis. En multisite, vérifiez aussi un second sous-site et une donnée globale pertinente avec l’administrateur du réseau.
Surveillez les journaux et la charge de la base pendant la reprise. Un cache redevenu vide doit se remplir selon l’usage ; aucune mesure de gain universel ne découle de cette seule remise en service. Si le blocage revient, réappliquez le contournement connu et conservez le nouvel événement. Ne bouclez pas sur les boutons de purge ou de réactivation sans examiner la cause qui réapparaît.
Préparer la prochaine maintenance sans dépendance cachée
Documentez le propriétaire du drop-in, le chemin réel du contenu, la source des paramètres et le service Redis utilisé. Précisez si la base est réservée au cache ou partagée, et qui peut en autoriser une purge. Conservez la procédure de secours avec sa méthode de retrait ; une constante oubliée peut laisser le site fonctionner longtemps sans le cache que l’équipe croit actif.
Avant une migration, vérifiez l’accès au nouveau service depuis PHP, l’authentification, le transport et le comportement de la copie. Avant une rotation de secret ou une maintenance Redis, prévoyez le moment où chaque consommateur prendra sa nouvelle configuration. Le retour de PONG et l’accès à une page publique ne remplacent pas la validation fonctionnelle du cache objet.
Pour une demande de correction, fournissez la version du plugin et du drop-in, le code d’erreur utile, l’heure, l’environnement et le contournement appliqué. Gardez les secrets dans leur canal prévu. Le dossier doit permettre de distinguer une mauvaise destination, une autorisation refusée et un service dégradé. La réparation est achevée lorsque le cache fonctionne de nouveau et que le site reste utilisable avec des vérifications cohérentes, sans nettoyage global ajouté par habitude.
