Reconnaître un partage qui produit des effets inattendus
Deux installations WordPress utilisent le même serveur Redis. Après une purge sur la première, la seconde ralentit brutalement. Dans un cas plus sérieux, une donnée de test semble provenir de l’autre installation. Relevez ce qui a changé, l’heure et l’opération exacte. Un cache vidé explique une reconstruction et une hausse de charge temporaire. Une valeur qui appartient à une autre installation invite à vérifier l’identité des clés. Ces deux effets peuvent provenir d’un partage différent des données ou des commandes de purge.
Choisissez deux installations de test identifiées et un exemple de donnée non personnelle. Relevez l’adresse de chacune, son environnement et son propriétaire. Une copie de préproduction peut avoir repris les paramètres Redis du site actif lors de sa création. Vérifiez cette possibilité avant d’activer son cache ou de le nettoyer. Pour agir, il faut un accès au fichier de configuration WordPress et l’accord du responsable Redis sur les ressources attribuées. Si la plateforme gère le drop-in, faites passer le changement par son mécanisme de configuration habituel. Le simple accès à l’administration WordPress ne définit pas le périmètre autorisé sur le service partagé.
Distinguer installations et sous-sites d’un réseau
Établissez si vous avez deux installations indépendantes ou plusieurs sous-sites d’un même réseau multisite. Dans un réseau, certains groupes de cache sont partagés volontairement et d’autres tiennent compte du sous-site. La configuration se fait au niveau de l’installation et du drop-in. Attribuer au hasard une base différente à chaque sous-site peut contredire ce fonctionnement. Dans le cas de deux installations, chacune doit avoir une identité et une destination de cache maîtrisées.
Pour chaque installation, notez le serveur ou le socket Redis, le client PHP, le numéro de base lorsqu’il existe et le préfixe de clés. Relevez aussi qui déclenche les purges, par exemple un bouton, une commande de déploiement ou une tâche automatique. Ajoutez les autres usages du service Redis. Il peut héberger un cache applicatif distinct ou des données dont la durée de vie est différente. Demandez au responsable la liste des bases et instances effectivement réservées. Un numéro qui paraît vide pendant un relevé ne démontre pas qu’il est disponible. Cette attribution doit précéder le changement de WordPress.
Identifier le logiciel qui fournit object-cache.php
Examinez le fichier object-cache.php du répertoire de contenu réel et retrouvez son fournisseur. Dans Redis Object Cache, ouvrez les réglages ou les diagnostics disponibles pour lire les paramètres effectifs. Conservez ce relevé en privé et masquez les identifiants de connexion. Le nom du fichier est commun à plusieurs fournisseurs. Les constantes de l’un ne configurent pas automatiquement l’autre. Si l’hébergeur génère le fichier ou les paramètres, retrouvez sa source de vérité avant de modifier une copie qui serait réécrite au prochain déploiement.
Le parcours de code ci-dessous concerne Redis Object Cache de Rhubarb Group. Vérifiez sa version et celle du drop-in installé. Son dépôt documente WP_REDIS_DATABASE pour la base et WP_REDIS_PREFIX pour l’identité des clés. L’ancienne constante WP_CACHE_KEY_SALT apparaît encore sur certains sites. Comparez les priorités documentées par la version en place et éliminez les doubles définitions dans le fichier maintenu. Gardez la configuration d’origine. Si la panne est une impossibilité de connexion plutôt qu’un partage de données, résolvez d’abord la joignabilité avec le guide dédié avant de tester l’isolation.
Séparer l’identité des clés et la portée d’une purge
Un préfixe unique permet de distinguer les noms de clés de deux applications. Cela réduit les collisions lorsque des données portent les mêmes identifiants internes. Une purge de toute la base Redis peut cependant retirer les clés de tous les préfixes présents dans cette base. Le fonctionnement dépend de la commande réellement envoyée et des protections du fournisseur de cache. Relevez le mécanisme utilisé par le bouton ou par le script d’exploitation. Le mot « vider le cache » dans une interface ne précise pas toujours cette portée.
Sur un service Redis qui permet plusieurs bases logiques, une base réservée à chaque installation peut séparer les effets d’une commande limitée à la base sélectionnée. Une commande qui vise toute l’instance aurait encore un périmètre plus large. Les bases logiques partagent aussi les ressources du même service. Elles ne constituent pas une séparation complète de sécurité ou de capacité. Si deux équipes doivent être indépendantes sur ces points, demandez une instance ou une politique de service adaptée. Conservez dans le bilan les trois éléments, identité des clés, destination logique et commandes autorisées.
Vérifier les possibilités de l’architecture Redis
Pour deux applications indépendantes, privilégiez des destinations Redis dédiées. La documentation Redis déconseille de faire cohabiter des applications sans lien dans une seule instance en s’appuyant seulement sur ses bases logiques. Un index distinct est un espace de noms ; les bases restent notamment enregistrées dans les mêmes fichiers de persistance. Si l’hébergement a déjà validé une architecture partagée, faites confirmer explicitement son périmètre et les droits de purge avant de conserver ce fonctionnement.
Redis permet la sélection d’une base dans certaines architectures. Redis Cluster utilise uniquement la base zéro et ne prend pas en charge ce mécanisme de sélection. Un service géré peut également imposer ses propres possibilités. Faites confirmer le type de service avant d’utiliser un numéro trouvé dans un exemple. Pour un cluster ou un besoin d’isolation plus fort, une destination dédiée peut être la bonne méthode. Le fournisseur doit préciser le point d’accès, les identifiants et le mécanisme de purge à utiliser.
Si plusieurs bases logiques sont disponibles, faites réserver explicitement un index distinct pour chaque installation indépendante. Gardez un préfixe lisible et unique par environnement. Pour une copie, différenciez aussi production et préproduction. Lorsque le client ou la plateforme possède un cache local supplémentaire, vérifiez la procédure de bascule recommandée pour éviter de conserver un état ancien dans les processus. Le changement ne se limite pas à la valeur écrite dans un fichier. Les diagnostics et les nouvelles requêtes doivent montrer que l’installation rejoint la destination prévue. Un accord d’attribution clair facilite cette vérification et le retour éventuel.
Préparer la bascule sans purger la destination commune
Sur une copie isolée du service ou un environnement de test attribué, conservez la configuration initiale et un point de restauration adapté au site. Faites vérifier la disponibilité de la nouvelle base ou de l’instance par son responsable. Préparez les accès au fichier de configuration même si l’administration devient lente pendant le réchauffement du cache. Relevez le comportement du site avant changement et choisissez une fenêtre où une hausse temporaire de charge est acceptable.
Si une préproduction pointe encore vers le cache actif, utilisez le contournement documenté pour son drop-in afin de couper cette utilisation avant les essais. Vérifiez les effets de toute commande d’activation ou de désactivation. Certaines opérations d’installation du cache peuvent elles-mêmes déclencher une purge. Ne les utilisez pas comme simple méthode de reconnexion sur une base dont l’usage reste partagé. Préparez d’abord la destination indépendante et les paramètres du fournisseur. Faites une seule bascule à la fois pour pouvoir attribuer un écart au site modifié et constater le comportement de l’autre installation dans son état normal.
Renseigner la base et le préfixe dans la configuration maintenue
Dans wp-config.php, placez les constantes reconnues avant le chargement de wp-settings.php, selon les instructions du fournisseur. Recherchez les définitions existantes et modifiez-les à leur source. L’exemple suppose une architecture partagée déjà approuvée par le responsable, hors Redis Cluster, et une base 4 réservée à la seule installation de préproduction concernée. Il ne recommande pas ce partage pour de nouvelles applications indépendantes. Ce numéro et le préfixe sont illustratifs. Gardez les autres paramètres de connexion déjà validés. Une autre installation indépendante doit recevoir sa propre attribution, par exemple une autre base et une identité distincte.
Après l’enregistrement sur la copie, lancez une nouvelle requête puis ouvrez les diagnostics du cache. Vérifiez la base, le préfixe et l’état de connexion effectifs. Si les valeurs ne changent pas, retrouvez la configuration chargée, le déploiement ou les paramètres imposés par la plateforme. Ne multipliez pas les définitions dans plusieurs fichiers. Le retour consiste à rétablir les valeurs sauvegardées seulement si leur destination est encore autorisée et cohérente. Si l’ancienne destination est la cause de collisions confirmées, gardez temporairement le cache de cette copie contourné selon la méthode du fournisseur jusqu’à correction.
define('WP_REDIS_DATABASE', 4);
define('WP_REDIS_PREFIX', 'atelier-preproduction:');Vérifier la séparation avec une clé temporaire
Sur deux copies autorisées à cet essai, choisissez un nom de clé et un groupe uniques au test. L’exemple crée une valeur dans l’installation A avec une expiration courte, cherche cette même clé depuis B, puis la retire depuis A. Remplacez les racines et les noms d’exemple par les références de votre recette. Ne réutilisez pas un groupe métier comme users ou options. Confirmez au préalable que les deux contextes emploient bien un cache persistant et le composant prévu.
La lecture depuis B doit indiquer une absence si les espaces sont isolés sur ce trajet. Relisez aussi la clé depuis A dans une nouvelle commande avant de la retirer, afin de confirmer sa persistance. Si A ne la retrouve pas, l’absence depuis B ne démontre rien sur l’isolation. La relecture de A doit suivre immédiatement celle de B, avant expiration. Si A a perdu la clé, par expiration, éviction ou changement de destination, le résultat est non concluant. Une absence attendue dans B et une erreur de connexion sont deux résultats différents. Ne liez pas ces lignes par && : le code non nul attendu d’une clé absente ne doit pas empêcher le relevé suivant ni le nettoyage ciblé. Notez chaque résultat séparément. Le test peut charger le code WordPress et doit respecter les contraintes des copies utilisées.
Une réussite dans le terminal concerne ce contexte. Le PHP web et les workers peuvent recevoir une autre configuration. Faites confirmer leurs paramètres effectifs et exercez un contrôle représentatif par leur voie de maintenance autorisée.
Après les commandes ci-dessous, répétez le contrôle dans le sens inverse avec une nouvelle clé : B écrit et relit sa valeur, A doit répondre que cette clé est absente, puis B doit encore relire sa valeur avant le nettoyage ciblé. Une erreur de connexion, une clé expirée ou une valeur perdue ne valent pas un refus de lecture démontrant l’isolation. Gardez les paramètres effectifs et chaque résultat. Vérifiez aussi le nettoyage dans le contexte qui a créé la clé. Ce contrôle porte sur les groupes et les processus effectivement utilisés ; il ne valide pas automatiquement tous les caches ajoutés par des extensions.
wp --path=/copie-a cache set test-isolation-unique valeur-a test-maintenance-unique 300
wp --path=/copie-a cache get test-isolation-unique test-maintenance-unique
wp --path=/copie-b cache get test-isolation-unique test-maintenance-unique
wp --path=/copie-a cache get test-isolation-unique test-maintenance-unique
wp --path=/copie-a cache delete test-isolation-unique test-maintenance-uniqueTester la purge dans un périmètre jetable
La vérification de purge doit se faire dans des destinations de test dont tous les usages sont connus. Créez pour cet essai une nouvelle paire de valeurs synthétiques sur A et B, avec une durée qui couvre la manipulation, puis relisez chacune depuis une nouvelle requête avant toute purge. Les deux valeurs doivent encore être présentes : sinon, corrigez le test avant de mesurer leur disparition ou leur survie. Utilisez ensuite la commande de purge documentée de A. Relisez la valeur de B dans une nouvelle requête. Elle doit rester disponible si le contrat prévu assure cette indépendance. Si elle a disparu, écartez d’abord une expiration ou une éviction normale ; les observations seules ne permettent alors pas d’attribuer sa perte à la purge. Sur A, vérifiez que la valeur n’est plus présente et que le site reconstitue ses données attendues. Si B est également vidé, identifiez la commande envoyée et le service qu’elle vise avant de reproduire l’opération ailleurs.
Comparez les purges de l’administration aux scripts de maintenance. Un déploiement peut utiliser une commande plus large que le bouton du plugin. Documentez les deux mécanismes et retirez du parcours normal celui dont la portée est incompatible avec le partage. Si une plateforme gère cette opération, faites valider la règle par son responsable. Les préfixes ne garantissent pas la survie à une purge globale. Les droits sur le service et le choix d’architecture doivent correspondre à ce que les outils d’exploitation sont réellement capables d’exécuter. Conservez la preuve du périmètre observé dans l’environnement jetable.
Prévoir le retour et le réchauffement du cache
Si la nouvelle destination pose un problème de connexion, conservez le message précis et les paramètres non secrets. Utilisez le contournement prévu par le drop-in sur la copie pour garder le site accessible pendant l’analyse. Rétablissez ensuite la configuration d’origine uniquement lorsque son usage est validé. Les anciennes clés peuvent avoir conservé des valeurs datant d’avant la bascule. Avant de relire cet ancien espace, le responsable doit décider comment invalider seulement les données de cette installation dans un périmètre autorisé.
Une nouvelle base de cache démarre avec peu de données. Les premières requêtes peuvent solliciter davantage la base principale et les services distants. Surveillez ce réchauffement dans la fenêtre préparée et vérifiez que le coût retombe ensuite. Si l’autre site ralentit aussi, comparez l’usage des ressources partagées plutôt que de supposer une collision. Une séparation des bases logiques conserve le même processus Redis et parfois la même machine. Gardez un relevé avant et après pour distinguer un cache froid, une saturation du service et un défaut de configuration. Chaque cause appelle une correction différente.
Valider les opérations courantes des deux installations
Vérifiez les pages publiques, les écrans d’administration et les écritures habituelles dans chaque environnement de test. Pour une boutique, utilisez les moyens de commande isolés prévus par l’équipe. Une configuration de cache doit suivre les mises à jour des données et les invalidations attendues. Vérifiez un changement éditorial sans réutiliser de données personnelles pour l’essai.
- Confirmez le fournisseur du drop-in et les paramètres effectifs de chaque installation.
- Vérifiez que les destinations réservées et les préfixes diffèrent selon le plan d’attribution.
- Relisez les valeurs synthétiques depuis de nouvelles requêtes sur A et B.
- Testez la purge de A uniquement sur les destinations jetables et constatez la survie de B.
- Vérifiez le parcours de déploiement, qui peut utiliser une autre commande de purge.
- Retirez les valeurs de test et consignez le contournement et les paramètres à rétablir en cas d’incident. Gardez la validation des usages de production séparée de cet essai.
Conserver l’attribution lors des prochaines copies de site
Ajoutez au dossier d’exploitation le service Redis, le numéro de base ou la destination dédiée, le préfixe, le client et le propriétaire de chaque installation. Notez les commandes autorisées et la portée des purges. Lors d’une copie vers la préproduction, changez ces paramètres avant de remettre le cache en service. Vérifiez aussi les variables d’environnement et les modèles de déploiement qui pourraient rétablir ceux du site actif. Un fichier corrigé manuellement peut être remplacé au prochain lancement d’un script.
Redis Object Cache fournit ces réglages dans sa version gratuite. Une autre intégration ou une offre gérée utilise son propre contrat de configuration. Gardez les noms de constantes liés au fournisseur identifié. La documentation d’un produit en version bêta doit également être distinguée de celle de la version en service. Le plan d’isolation se valide sur les données, les purges et les ressources. Reprenez ce petit scénario après un changement de client ou d’hébergement et gardez une attribution lisible pour éviter de choisir un index disponible seulement en apparence.
