DBではなくメモリに多くのユーザーパスワードを保持するMemcache / Elasticache
AWSに2つのサーバーがあります。 1つはライブプロダクションサーバー（マルチサイトWordPress数百のサイトと約5,000ユーザーのインストール））で、もう1つはテストサーバー用に構成されているprodのクローンです。ライブサーバー4つのアレイサーバーとElasticLoad Balancerがあり、AWSの大規模なRDSに接続されています。昨日まで、キャッシュはAPCとWordPressプラグインをあちこちで処理していると素朴に思っていました。しかし、いいえ。ここの誰かがAWSのElastiCacheをライブサーバーに追加したことがわかりました。基本的に、ElastiCacheはクラウドにいないユーザーのためのmemcacheです。
とにかく、2日前にテストサーバーでキャッシュを有効にしようとしましたが、非常に奇妙なバグが発生しました（リダイレクトがライブサイトのメイン管理ダッシュボードに不思議に表示され、その後テストサーバーに移動しました）。そのため、バグがキャッシュシステムに関連している可能性が高いことに気付いたら、キャッシュを無効にしました。結局のところ、テストサーバーでキャッシュを有効にすると、ライブサーバーが使用していたのと同じElasticacheサーバーが使用されました（テストはライブのクローンであったため）。そのため、object-cache.phpファイルを削除/名前変更したときに無効にしました。
これを無効にするとリダイレクトの問題は解決しましたが、突然、5,000人のユーザーの多く（すべてではない）が個々のサイトにログインできなくなりました。何らかの理由で、データベースにある値がかなりの割合のユーザーに対して機能していなかったため、代わりにパスワードをリセットする必要がありました。明らかに、これは5,000人のユーザーが混在する巨大なものです。そこで、ライブインスタンスでキャッシュを再度有効にし、代わりにWP構成の変更でキャッシュされたリダイレクトを修正することにしました（define（ 'RELOCATE'、true）;を構成に追加して、リダイレクトを強制します。オーバーライドされるテストサーバー）。
Memcacheで気づいたことの1つは、ライブサーバーの代わりにテストサーバーのドメインでwp_optionsテーブルを更新し続けたことです。実際、クエリを実行してテストドメインの文字列を検索し、それをライブドメインに更新するたびに、それは引き続き実行されます。数分ごとに、キャッシュによって元に戻されます。怖い。しかし、今のところ、構成を変更するとオーバーライドが強制されるようです。これらすべてについて本当に懸念しているのは、memcacheがデータベースから直接ではなく、ユーザーパスワードの独自のキーと値のペアから取得しているように見えるという事実でした。つまり、キャッシュを有効にすると、ユーザーは侵入できます。キャッシュを有効にしないと、多くのユーザーがパスワードのリセットを余儀なくされます。
この場合、memcacheで何が起こっているのかを効果的に理解する方法と、データベースが適切に書き込まれ、パスワード情報がキャッシュに保持されるだけではないように修正する方法について、誰かが私にアイデアを持っていますか？私の考えでは、それは時限爆弾です。ほとんどのユーザーの生活を非常に苦痛にするために必要なのは、1つのflush_allコマンドだけです。
RDSでMySQLを使用してNginxを使用しています。 WordPress 3.4.2。
キャッシュは、テストインスタンスからのデータとセッション情報で上書きされました。 memcachedクライアントを使用してキャッシュをクリアします。キャッシュクラスターを再起動すると、それも実行される可能性があります。パスワードをリセットするとセッションもリセットされるため、それが可能な解決策でした。
そうは言っても、セキュリティグループの設定が間違っている可能性があります。テストインスタンスは、ElastiCacheクラスターに接続できなかったはずです。 Memcachedには認証がないため、キャッシュサーバーにアクセスできる場合は、データにアクセスできます。のすべてのアドレスを許可するようにセキュリティグループが設定されていないことを確認してください。