Memcache/Elasticache хранит много пользовательских паролей в памяти вместо БД

У меня есть два сервера в AWS. Один - это живой рабочий сервер (многопользовательская установка WordPress с сотнями сайтов и около 5000 пользователей), а другой - клон prod, который настраивается для тестового сервера. Живой имеет четыре сервера массивов, Elastic Load Balancer и подключен к большой RDS в AWS. И до вчерашнего дня я наивно думал, что наше кэширование обрабатывается через APC и плагин WordPress тут и там. Но нет. Оказывается, кто-то здесь добавил ElastiCache AWS на наш работающий сервер. По сути, ElastiCache - это memcache для тех, кто не в облаке.

В любом случае, мы попытались включить кэширование на нашем тестовом сервере два дня назад, и это привело к действительно странной ошибке (редирект загадочным образом появился на главной панели администратора нашего живого сайта, которая затем пошла на наш тестовый сервер). Поэтому, как только мы поняли, что ошибка, скорее всего, связана с системой кэширования, о которой мы не знали, мы отключили кэширование. Как оказалось, когда мы включили кэширование на нашем тестовом сервере, он использовал тот же сервер Elasticache, который использовался нашим живым сервером (потому что тест был клоном живого). Поэтому мы отключили его, когда удалили / переименовали файл object-cache.php.

Его отключение решило проблему перенаправления, но внезапно многие (не все) из 5000 наших пользователей перестали заходить на свои отдельные сайты. По какой-то причине значения, которые были в нашей базе данных, не работали для значительного процента пользователей, заставляя их вместо этого сбрасывать свои пароли. Очевидно, что это огромный с 5000 пользователей в смеси. Поэтому мы включили кэширование на нашем работающем экземпляре и решили вместо этого исправить наше кэшированное перенаправление с изменениями конфигурации WP (мы добавили define('RELOCATE',true); в конфигурацию, чтобы перенаправление на наш тестовый сервер было переопределено).

Одна из вещей, которые мы заметили в memcache, заключалась в том, что он постоянно обновлял нашу таблицу wp_options с доменом для тестового сервера вместо нашего живого. Фактически, он все еще делает это всякий раз, когда я запускаю запрос, чтобы найти строку для тестового домена и обновить ее до действующего домена. Каждые несколько минут кэширование меняет его обратно. Страшно. Но похоже, что наше изменение конфигурации на данный момент вызывает переопределение. По-настоящему интересным во всем этом был тот факт, что memcache рисует из своего собственного ключа: пары значений для пользовательских паролей, а не непосредственно из базы данных. Я имею в виду, что с включенным кэшированием пользователи могут войти. Без него многие пользователи вынуждены сбрасывать свои пароли.

Есть ли у меня какие-либо идеи для меня, как эффективно понять, что происходит с memcache в этом случае и как это исправить, чтобы база данных была записана соответствующим образом и чтобы информация о пароле не просто сохранялась в кэше? На мой взгляд, это бомба замедленного действия. Все, что нужно - это одна команда flush_all, чтобы сделать жизнь очень болезненной для большинства моих пользователей.

Мы на Nginx с MySQL на RDS. WordPress 3.4.2.