Eu tenho dois servidores no AWS. Um deles é um servidor de produção ao vivo (uma instalação do WordPress de vários sites com centenas de sites e cerca de 5.000 usuários) e o outro é um clone de produção que está sendo configurado para um servidor de teste. O live tem quatro servidores de matriz, um Elastic Load Balancer e está conectado a um grande RDS no AWS. E até ontem, eu ingenuamente pensei que nosso caching estava sendo tratado via APC e um plugin do WordPress aqui e ali. Mas não. Acontece que alguém aqui havia adicionado o ElastiCache da AWS ao nosso servidor ao vivo. Essencialmente, o ElastiCache é memcache para aqueles que não estão na nuvem.
De qualquer forma, tentamos habilitar o cache em nosso servidor de teste dois dias atrás e ele introduziu um bug muito estranho (um redirecionamento apareceu misteriosamente no painel de administração principal do nosso site ao vivo que foi para o nosso servidor de teste). Então, quando percebemos que o bug provavelmente estava relacionado a um sistema de cache que não sabíamos que tínhamos, desativamos o cache. Como aconteceu, quando ativamos o cache em nosso servidor de teste, usamos o mesmo servidor Elasticache que nosso servidor ativo estava usando (porque o teste era um clone do live). Então nós desativamos quando removemos / renomeamos o arquivo object-cache.php.
A desativação resolveu nosso problema de redirecionamento, mas, de repente, muitos (nem todos) de nossos 5.000 usuários não puderam mais fazer login em seus sites individuais. Por algum motivo, os valores que estavam em nosso banco de dados não estavam funcionando para uma boa porcentagem de usuários, forçando-os a redefinir suas senhas. Obviamente, isso é enorme, com 5.000 usuários no mix. Então, reativamos o cache em nossa instância ao vivo e decidimos corrigir nosso redirecionamento em cache com alterações de configuração do WP (adicionamos define ('RELOCATE', true); na configuração para forçar o redirecionamento para o nosso servidor de teste a ser substituído).
Uma das coisas que notamos com o memcache foi que ele continuava atualizando nossa tabela wp_options com o domínio para o servidor de teste no lugar do nosso live. Na verdade, ele ainda faz isso sempre que eu executo uma consulta para encontrar a string do domínio de teste e atualizá-la para o domínio real. A cada poucos minutos, o cache muda de volta. Assustador. Mas parece que a nossa mudança de configuração agora força uma substituição. A coisa realmente preocupante sobre tudo isso era o fato de que parece que o memcache está desenhando a partir de sua própria chave: pares de valor para as senhas de usuário em vez de diretamente do banco de dados. Quero dizer, com o cache ativado, os usuários podem entrar. Sem ele, muitos usuários são forçados a redefinir suas senhas.
Alguém tem alguma idéia para mim sobre como entender efetivamente o que está acontecendo com o memcache neste caso e como corrigi-lo para que o banco de dados seja gravado de maneira apropriada e, portanto, as informações de senha não sejam mantidas apenas no cache? Para meu pensamento, é uma bomba-relógio. Tudo o que precisaria é de um comando flush_all para tornar a vida muito dolorosa para a maioria dos meus usuários.
Estamos no Nginx com o MySQL no RDS. WordPress 3.4.2.