Magento 某些产品突然消失

Question

我们有 Magento EE 1.14.0.1。 最近我们迁移到了新的 AWS EC2 服务器和 ElasticCache Redis 服务器。 然后一些随机产品开始在前端消失。 它们存在于后端并正确配置（可见、启用、库存等......）。 只有在您将产品保存在后端后，即使不刷新任何缓存，它也会再次显示在前端。

• 此问题与 Redis 缓存有关吗？

• 如果它如何修复它？

任何输入将不胜感激，以指导我找到解决方案。

谢谢

更新：我将索引管理下的所有内容都标记为在保存时更新。 所以我将其恢复为按计划更新。 我认为这解决了问题。 但我仍然想保持我的商店库存是最新的。

Answer 1

“这是一个索引问题，每次从数据库更新数据（产品、库存）时，都必须手动重新索引 Magento。”

这适用于社区版，而不是企业版。 此外，迁移到 AWS 时可能会出现一些额外的问题。 在迁移到 AWS 的继承服务器上进行了 4 个月的故障排除后，我发现了许多问题/解决方案。

EE 问题企业版索引对许多索引都是异步的。 此外，并非所有 EE 索引都配置在典型位置。 在管理菜单上，选择系统 > 配置。 在左侧面板中的“高级”下，选择“索引管理”。 http://docs.magento.com/m1/ee/user_guide/system-operations/index-configuration.html

根据我的经验，即使设置为“保存时更新”，它也经常不会在保存时更新。

AsyncIndexing 在 1.14.3.x 之前的版本中不稳定。 升级！ 部分进程可能会以某种方式中断，从而无法进行索引。 发生这种情况的一种方式是，如果您使用不同的用户 ID 和组为网站运行 PHP [通常通过 PHPFPM]，那么您运行 cronjobs[shell access]。 索引取决于创建文件以“锁定”进程 - 该文件只能由创建它的用户写入/删除。

我发现出于性能原因，最好将所有索引设置为“手动更新”。 不要安排定期重新索引所有进程，由于异步索引，它是无用的。 只要确保你的 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 工作中，网站所有者将很难说出他们如何从所有这些工作中受益。 就我而言，在我们继承客户理解困难的网站之前，消失的产品已经成为一个问题一年多。

Answer 2

这是一个索引问题，每次从数据库更新数据（产品、库存）时，都必须手动重新索引 Magento。 如果不这样做，索引上的数据就会损坏，并且产品请求列表上的 SQL 连接也会丢失。