У меня в AWS два сервера. Один из них - это действующий производственный сервер (установка WordPress с несколькими сайтами с сотнями сайтов и около 5000 пользователей), а другой - клон продукта, который настраивается для тестового сервера. У действующего есть четыре сервера массива, эластичный балансировщик нагрузки и он подключен к большому RDS в AWS. И до вчерашнего дня я наивно думал, что наше кеширование осуществляется через APC и плагин WordPress кое-где. Но нет. Оказывается, кто-то здесь добавил ElastiCache AWS на наш действующий сервер. По сути, ElastiCache - это кэш памяти для тех, кто не работает в облаке.
Как бы то ни было, два дня назад мы попытались включить кеширование на нашем тестовом сервере, и это привело к действительно странной ошибке (перенаправление загадочным образом появилось на главной панели администратора нашего живого сайта, которое затем перешло на наш тестовый сервер). Поэтому, когда мы поняли, что ошибка, скорее всего, связана с системой кеширования, о которой мы не знали, мы отключили кеширование. Как оказалось, когда мы включили кеширование на нашем тестовом сервере, он использовал тот же сервер Elasticache, что и наш живой сервер (потому что тест был клоном живого). Поэтому мы отключили его, когда удалили / переименовали файл object-cache.php.
Его отключение решило нашу проблему перенаправления, но внезапно многие (не все) из наших 5000 пользователей больше не могли входить на свои отдельные сайты. По какой-то причине значения, которые были в нашей базе данных, не работали для хорошего процента пользователей, вынуждая их вместо этого сбрасывать свои пароли. Очевидно, это огромное количество пользователей, в которых участвует 5000 человек. Поэтому мы повторно включили кеширование на нашем живом экземпляре и решили вместо этого исправить наше кешированное перенаправление с изменениями конфигурации WP (мы добавили define ('RELOCATE', true); в конфигурацию, чтобы принудительно переопределить перенаправление на наш тестовый сервер).
Одна из вещей, которые мы заметили с memcache, заключалась в том, что он продолжал обновлять нашу таблицу wp_options с доменом для тестового сервера вместо нашего живого. Фактически, он все еще делает это всякий раз, когда я запускаю запрос, чтобы найти строку для тестового домена и обновить ее до активного домена. Каждые несколько минут кеширование меняет его обратно. Страшно. Но похоже, что наше изменение конфигурации на данный момент приводит к отмене. По-настоящему тревожным во всем этом был тот факт, что кажется, что memcache извлекает из собственных пар ключ: значение для паролей пользователей, а не напрямую из базы данных. Я имею в виду, что с включенным кешированием пользователи могут войти. Без него многие пользователи вынуждены сбрасывать свои пароли.
Есть ли у меня какие-нибудь идеи относительно того, как эффективно понять, что происходит с memcache в этом случае, и как это исправить, чтобы база данных была записана должным образом, и информация о пароле не просто хранится в кеше? На мой взгляд, это бомба замедленного действия. Достаточно одной команды flush_all, чтобы сделать жизнь большинства моих пользователей очень и очень болезненной.
Мы находимся на Nginx с MySQL на RDS. WordPress 3.4.2.
Ваш кеш был перезаписан данными и информацией о сеансе из тестового экземпляра. Используйте клиент memcached для очистки кеша. Это также может сделать перезагрузка кластера кеша. Сброс пароля также сбрасывает ваши сеансы, поэтому это было возможным решением.
Тем не менее, ваши группы безопасности, вероятно, настроены неправильно. Ваш тестовый экземпляр никогда не должен был подключаться к кластеру ElastiCache. Memcached не имеет аутентификации, поэтому, если вы можете связаться с серверами кеша, у вас будет доступ к данным. Убедитесь, что ваши группы безопасности не настроены так, чтобы разрешать ввод всех адресов.