Діагностика Redis Object Cache після міграції WordPress

Як зрозуміти, що проблема пов’язана з Redis

Підозрювати persistent object cache варто, якщо після міграції частина сайту працює зі старими даними, хоча записи в базі вже змінені. Типові приклади: старі параметри в адмінці, попередня конфігурація плагіна, некоректне меню, помилки входу або різна поведінка сайту для різних користувачів.

Водночас не кожна проблема кешується в Redis. HTML-кеш на рівні вебсервера, CDN, кеш сторінок у плагіні або кеш браузера мають інші механізми. Тому спочатку потрібно з’ясувати, чи використовує WordPress саме persistent object cache.

• Проблема з’явилася одразу після зміни сервера, домену або хостингу.
• Після очищення кешу дані тимчасово стають правильними, але знову повертаються.
• У логах є помилки підключення до Redis, authentication required, connection refused або timeout.
• На новому сервері встановлені інші host, port, пароль, Unix-сокет або база Redis.
• На сайті залишився object-cache.php, скопійований зі старої інсталяції.

Перевірка persistent object cache у WordPress

Виконуйте команди з кореня WordPress і від імені того самого системного користувача, під яким працює сайт або WP-CLI. Це важливо: CLI може використовувати інше оточення, інший PHP або інші змінні середовища, ніж PHP-FPM.

Команда wp cache type показує тип активного object cache. Якщо використовується persistent cache, зазвичай буде вказано відповідний драйвер або плагін. Додатково перевірте наявність drop-in у каталозі wp-content.

• Файл wp-content/object-cache.php є спеціальним drop-in WordPress і завантажується раніше за багато звичайних плагінів.
• Назва файлу сама по собі не доводить, що він належить саме Redis: його могли створити різні кеш-плагіни.
• Перевірте власника, права доступу, дату зміни та фактичний вміст файлу.
• Якщо сайт працює в режимі multisite, перевіряйте конфігурацію з урахуванням усієї мережі та команд, які виконуються для конкретного сайту.

wp cache type
ls -l wp-content/object-cache.php
file wp-content/object-cache.php
head -n 40 wp-content/object-cache.php

Що перевірити в object-cache.php

Не редагуйте drop-in навмання. Спочатку визначте, який плагін його створив, і подивіться, чи містить він посилання на класи Redis, константи або змінні для host, port, database та password. Частина плагінів зберігає параметри безпосередньо у власній конфігурації, а частина читає їх із wp-config.php або environment-змінних.

Якщо drop-in залишився від старого сервера, безпечніше перевстановити або повторно активувати сумісний кеш-плагін за його документацією, ніж переносити файл вручну. Файл може бути від іншої версії плагіна, містити стару адресу Redis або очікувати PHP-розширення, якого немає на новому сервері.

• Не копіюйте object-cache.php з резервної копії без перевірки джерела.
• Не публікуйте в чатах і тикетах повний файл, якщо в ньому є пароль або токен.
• Перевірте, чи збігаються версії PHP, плагіна та Redis-клієнта з вимогами вашої конфігурації.

Перевірка параметрів підключення Redis

Після міграції порівняйте фактичні параметри старого і нового середовища. Redis може працювати на localhost, окремому приватному хості або Unix-сокеті. Також має значення порт, номер логічної бази, пароль, ACL-користувач, TLS та ім’я контейнерного сервісу.

Шукайте ці значення у wp-config.php, файлах .env, конфігурації PHP-FPM, налаштуваннях кеш-плагіна або змінних середовища контейнера. Не припускайте, що localhost означає те саме в усіх середовищах: у Docker localhost усередині контейнера WordPress вказує на цей самий контейнер, а не на контейнер Redis.

• Host: адреса або ім’я сервісу Redis.
• Port: стандартний порт не гарантує, що саме він використовується у вашому середовищі.
• Database: номер логічної бази Redis, якщо його задає клієнт.
• Password або ACL: актуальні облікові дані та права користувача.
• Socket або TLS: додаткові параметри, які можуть відрізнятися після міграції.

grep -nE 'REDIS|WP_REDIS|CACHE' wp-config.php .env 2>/dev/null
redis-cli -h 127.0.0.1 -p 6379 ping

Як безпечно перевірити доступ до Redis

Відповідь PONG підтверджує, що Redis доступний за вказаною адресою, але не гарантує, що WordPress використовує саме цей сервер або правильну базу. Якщо Redis захищений паролем чи ACL, використовуйте спосіб авторизації, прийнятий у вашому середовищі, і не передавайте секрети через історію shell-команд.

Помилки connection refused і timeout зазвичай вказують на мережу, порт, firewall або невірний host. Помилка NOAUTH означає проблему з авторизацією. Якщо Redis доступний, але WordPress не підключається, перевірте PHP-розширення або бібліотеку клієнта, які використовує конкретний drop-in.

• Перевіряйте Redis із сервера та користувача, де реально виконується WordPress.
• Не відкривайте Redis у публічний інтернет лише для швидкої перевірки.
• Якщо Redis спільний для кількох сайтів, обов’язково визначте ізоляцію ключів і баз.

Очищення кешу після зміни конфігурації

Коли параметри підключення виправлені, очистіть object cache через WordPress і повторіть перевірку сайту. Це прибирає старі об’єкти, які могли залишитися у правильній або неправильній Redis-базі.

Команда wp cache flush може залежати від активного object-cache drop-in. Якщо drop-in не працює або WordPress не може завантажити його через помилку PHP, команда може завершитися помилкою. У такій ситуації спочатку потрібно відновити сумісний драйвер або тимчасово вимкнути drop-in.

wp cache flush
wp cache type

Чому не варто одразу запускати FLUSHALL

Команда FLUSHALL видаляє всі ключі з усіх Redis-баз конкретного Redis-сервера. Якщо один екземпляр використовується кількома сайтами, чергами або іншими сервісами, це може спричинити проблеми далеко за межами поточної міграції.

Навіть FLUSHDB потрібно виконувати лише після підтвердження, що вибрана база належить потрібному сайту. Спочатку використовуйте wp cache flush або штатний механізм плагіна. Для спільного Redis узгодьте очищення з адміністратором інфраструктури та перевірте політику ізоляції ключів.

• Не використовуйте FLUSHALL у production без чіткого розуміння наслідків.
• Не очищайте Redis під час пікового навантаження без плану спостереження.
• Після очищення перевірте авторизацію, адмінку, меню, кошик і критичні форми.

Тимчасове вимкнення Redis для локалізації проблеми

Якщо сайт продовжує показувати старі дані або виникають помилки, тимчасово вимкніть object-cache drop-in. Перед цим зробіть резервну копію файлу та переконайтеся, що маєте доступ до сервера. Перейменування не видаляє файл і дає змогу швидко повернути його назад.

Після вимкнення перевірте сайт у приватному вікні або з очищеною сесією. Перегляньте саме ті дії, які раніше спричиняли проблему: вхід, збереження налаштувань, зміну меню, оновлення запису чи роботу плагіна.

cp wp-content/object-cache.php wp-content/object-cache.php.backup
mv wp-content/object-cache.php wp-content/object-cache.php.disabled
wp cache type

Як трактувати результат

Якщо без drop-in проблема зникає, причина майже напевно пов’язана з Redis-конфігурацією, несумісним кеш-плагіном, помилкою клієнта або залишеним файлом object-cache.php. Це не означає, що Redis потрібно назавжди вимкнути: після діагностики встановіть сумісну конфігурацію та повторно протестуйте сайт.

Якщо проблема залишається, шукайте її в page cache, CDN, PHP-коді, базі даних, cookies або іншому плагіні. Повернення drop-in без перевірки не допоможе і може знову приховати актуальні зміни.

• Повертайте файл лише після перевірки його походження та параметрів.
• Після повернення очистіть кеш і повторіть функціональні тести.
• Не залишайте резервні копії з паролями доступними з web-каталогу.

mv wp-content/object-cache.php.disabled wp-content/object-cache.php

Логи та типові помилки після міграції

Якщо базові перевірки не дали відповіді, перегляньте журнали PHP-FPM, вебсерверів, контейнерів і самого кеш-плагіна. Шукайте час виникнення помилки та порівнюйте його з діями в адмінці. Одне повідомлення в логах може стосуватися іншого процесу, тому важливо перевіряти контекст.

Окремо зверніть увагу на права доступу. WP-CLI може запускатися від одного користувача, а PHP-FPM — від іншого. У результаті CLI бачить одні environment-змінні або має доступ до сокета Redis, а вебзапит — ні.

• Connection refused: Redis не слухає вказану адресу або доступ блокує firewall.
• Could not connect або timeout: помилка маршрутизації, DNS, мережі чи неправильний host.
• NOAUTH або authentication required: неправильний пароль, ACL-користувач або відсутній параметр авторизації.
• Class not found або extension missing: на новому сервері немає потрібного PHP-розширення чи бібліотеки.
• Старі дані без помилок: WordPress може підключатися до іншого, але доступного Redis.

Фінальний чекліст після відновлення

Після виправлення не обмежуйтеся перевіркою головної сторінки. Persistent object cache може впливати на різні частини WordPress, зокрема на налаштування, користувачів, меню, запити та дані плагінів.

Проведіть контрольну перевірку в тому самому середовищі, де працюють реальні користувачі, і переконайтеся, що після повторного деплою або перезапуску PHP-FPM конфігурація не зникає.

• wp cache type показує очікуваний тип кешу.
• object-cache.php належить потрібному плагіну й не містить старих адрес або секретів.
• WordPress і PHP-FPM використовують однакові host, port, database та параметри авторизації.
• wp cache flush завершується без помилок.
• Перевірені вхід, вихід, збереження налаштувань, меню, записи та ключові функції сайту.
• У логах немає нових помилок Redis після кількох реальних запитів.
• Redis не очищався глобально, якщо на ньому працюють інші сайти або сервіси.