我们有 Magento EE 1.14.0.1。最近我们搬到了新的 AWS EC2 服务器和 ElasticCache Redis 服务器。然后一些随机产品开始在前端消失。它们存在于后端并正确配置（可见、启用、库存等....）。只有在您将产品保存到后端后，它才会再次显示在前端，即使没有刷新任何缓存。
这个问题是否与 Redis 缓存有关？
如果是怎么解决呢？
如果有任何意见可以指导我找到解决方案，我们将不胜感激。
谢谢
更新：我将索引管理下的所有内容标记为保存时更新。所以我将其恢复为按计划更新。我认为这解决了这个问题。但我仍然想保持我的商店库存是最新的。
【问题讨论】：
“这是一个索引问题，每次从数据库更新数据（产品、库存）时，都必须手动重新索引 Magento。”
对于社区版是这样，而不是企业版。此外，迁移到 AWS 时可能会出现一些额外的问题。在对迁移到 AWS 的继承服务器进行了 4 个月的故障排除后，我发现了许多问题/解决方案。
EE 问题 Enterprise Edition 索引对于许多索引是异步的。此外，并非所有 EE 索引都配置在典型位置。 在管理员菜单上，选择系统 > 配置。在左侧面板的高级下，选择索引管理。 http://docs.magento.com/m1/ee/user_guide/system-operations/index-configuration.html
根据我的经验，即使设置为“保存时更新”，它也经常不会在保存时更新。
AsyncIndexing 在 1.14.3.x 之前的版本中不稳定。 升级！部分过程可能会以某种方式中断，从而使索引无法继续进行。发生这种情况的一种方法是，如果您使用不同的用户 ID 和组为网站运行 PHP[通常通过 PHPFPM]，然后运行 cronjobs[shell 访问]。索引取决于创建文件以“锁定”进程 - 该文件只能由创建它的用户写入/删除。
我发现出于性能原因，最好将所有索引设置为“手动更新”。不要安排定期重新索引所有进程，由于异步索引，它是无用的。只需确保您的 cron 正在运行并且一切正常。
AsyncIndex 进程使用 MySQL 触发器...在尝试将 magento 数据库从一台服务器迁移到另一台服务器时会出现问题。最初创建它们的方式，它们只能由首次创建触发器时的数据库用户使用。如果您更改新服务器的数据库用户，触发器将不会迁移。更糟糕的是，几乎没有迹象表明发生了这种情况，而且除了索引之外的所有内容都运行良好，所以你怎么知道？
最后，“全部重新索引”并不总是全部重新索引。感谢互联网上的各种帖子，我创建了一个 shell 脚本，让 Magento 认为所有产品都已更新并且需要重建索引： https://gist.github.com/gamort/5dc5e16bdec00a8bb3b922fc463af17c
AWS 问题 使用 AWS Elasticache Redis 有一个隐藏的问题 - 它启动的默认区域可能与您的服务器区域不同。就我而言，服务器在 USEAST-1a 中，而 Redis 默认为 USEAST-1b。这导致在从缓存中查找数据时偶尔会出现超时。虽然网站代码通常可以恢复，但索引代码却不能。这会导致索引 cron 进程处于中断状态。
几乎同样重要的是，您只需为从 1a 区到 1b 区的数据传输支付少量的每 GB 费用。但是当你的缓存工作时，这个“微不足道”的数量可能会很大！我们有 10 美元以上/天 [每月 500-600 美元] 的区域内数据传输费！在你的实际区域中启动一个新的 redis 服务器，使用你的 web 服务器上的 redis cli 确保你可以连接[我们有防火墙配置问题]，然后才更新你的配置。
AWS RDS 服务器也有一个隐藏的陷阱[希望您不要太不知所措]。将数据库从另一台服务器迁移到 Amazon RDS 存在问题，即 MySQL 认为特定功能的有效 SQL 的内容发生了极其微小的变化……Magento EE 恰好使用了该功能。 :-) 。我最终安装了一个新的 Magento EE 副本并使用 Navicat 同步数据库结构。
Solr 问题 可以说，也存在 Solr 问题。主要是由于架构，但我也发现擦除 solr 数据库并让它重新索引很有帮助。
Magento 重写/表单问题 当您升级到 1.14.3 时会出现此问题 - 您当然应该这样做，因为它修复了很多索引问题。版本 1.14.3.x 为许多表单添加了表单键，包括客户注册表单。因此，如果您为登录创建了自己的自定义 phtml 模板，它们将无法正常工作！您需要将该表单键字段添加到您的自定义中。不过没什么大不了的，因为您记录了最初是从哪个模板文件复制的，对吗？
总而言之，我估计完成迁移清单需要 20 个小时，根据您遇到的问题，可能长达 80 个小时。归根结底，由于修复主要是在不容易看到的 cron 作业中，因此网站所有者将很难说出他们如何从所有这些工作中受益。就我而言，在我们继承客户理解困难的网站之前，消失的产品已经成为一年多的问题。
【讨论】：
这是一个索引问题，每次从数据库更新数据（产品、库存）时，都必须手动重新索引 Magento。如果您不这样做，您的索引数据将损坏，并且您将丢失产品请求列表上的 SQL 连接。
【讨论】：