我在AWS中有两台服务器.一个是实时生产服务器(具有数百个站点和大约5,000个用户的多站点WordPress安装),另一个是为测试服务器配置的prod的克隆.实时服务器有四个阵列服务器,一个Elastic Load Balancer,并连接到AWS中的大型RDS.直到昨天,我天真地认为我们的缓存是通过APC和WordPress插件来处理的.但不是.原来这里有人将AWS的ElastiCache添加到我们的实时服务器.从本质上讲,ElastiCache是那些不在云端的人的内存缓存.
无论如何,我们两天前尝试在我们的测试服务器上启用缓存,它引入了一个非常奇怪的错误(在我们的实时网站的主管理仪表板上神秘地出现了重定向,然后转到我们的测试服务器).所以一旦我们意识到这个bug很可能与我们不知道的缓存系统有关,我们就禁用了缓存.事实证明,当我们在测试服务器上启用缓存时,它使用了我们的实时服务器使用的相同Elasticache服务器(因为测试是live的克隆).因此,当我们删除/重命名object-cache.php文件时,我们禁用了它.
禁用它解决了我们的重定向问题,但突然之间,我们的5,000个用户中的许多(不是全部)无法再登录其各自的网站.出于某种原因,我们数据库中的值不适用于很大比例的用户,迫使他们不得不重置密码.显然,这是一个巨大的混合中有5,000名用户.所以我们在我们的实例上重新启用了缓存,并决定使用WP配置更改修复我们的缓存重定向(我们在配置中添加了define(‘RELOCATE’,true);强制重定向到我们的测试服务器被重写).
我们注意到memcache的一个原因是它不断更新我们的wp_options表,用测试服务器的域代替我们的实时服务器.实际上,每当我运行查询以查找测试域的字符串并将其更新到实时域时,它仍然会执行此操作.每隔几分钟,缓存就会改变它.害怕.但看起来我们的配置更改现在强制覆盖.所有这一切真正令人担忧的事实是,似乎memcache正在从它自己的密钥中获取：用户密码的值对而不是直接来自数据库.我的意思是启用了缓存,用户可以进入.没有它,许多用户被迫重置他们的密码.
有没有人对我有什么想法,如何有效地了解在这种情况下memcache正在发生什么,以及如何修复它,以便数据库得到适当的写入,因此密码信息不只是在缓存中保存？我认为这是一颗滴答作响的定时炸弹.所需要的只是一个flush_all命令,让大多数用户的生活变得非常非常痛苦.
我们在RDS上使用MySQL的Nginx. WordPress 3.4.2.
也就是说,您的安全组可能设置错误.您的测试实例应该始终无法连接到ElastiCache群集. Memcached没有身份验证,因此如果您可以访问缓存服务器,则可以访问数据.检查并确保您的安全组未设置为允许每个地址.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。