«Это проблема с индексом, каждый раз, когда вы обновляете данные (продукт, запас) из базы данных, вам необходимо вручную переопределить Magento».
Это верно для Community Edition, а не для Enterprise Edition. Кроме того, при переходе на AWS могут возникнуть дополнительные проблемы. После 4 месяцев устранения неполадок на унаследованном сервере, перенесенных в AWS, я нашел ряд проблем/решений.
Проблемы с ЭЭ Индексация Enterprise Edition является асинхронной для многих индексов. Кроме того, не все индексы EE настроены в типичном месте. В меню «Администратор» выберите «Система»> «Конфигурация». На панели слева в разделе «Дополнительно» выберите «Управление индексами». http://docs.magento.com/m1/ee/user_guide/system-operations/index-configuration.html
Даже если у меня установлено значение «обновить при сохранении», он часто не обновляется при сохранении.
AsyncIndexing был нестабилен в версиях до 1.14.3.x. Обновление! Частичный процесс мог прерываться таким образом, чтобы сделать невозможным его индексацию. Один из способов это произойдет, если вы используете PHP для веб-сайта [обычно через PHPFPM] с другим идентификатором пользователя и группой, то вы запустите cronjobs [shell access]. Индексирование зависит от создания файла для «блокировки» процесса - файл может быть написан или удален только пользователем, который его создает.
Я нашел, что по соображениям производительности лучше всего установить ВСЕ индексы для «обновления вручную». Не планируйте периодический процесс переиндексации, это бесполезно из-за индексации async. Просто убедитесь, что ваш cron работает, и все должно быть хорошо.
Процесс AsyncIndex использует триггеры MySQL ... которые имеют проблему при попытке перенести базу данных magento с одного сервера на другой. Как они создаются изначально, они могут ТОЛЬКО использоваться пользователем базы данных, когда триггеры, которые сначала создавались.Если вы измените пользователя базы данных для нового сервера, триггеры не будут мигрировать. Хуже того, почти нет никаких признаков того, что это произошло, и все, кроме индексации, отлично работает, так как вы можете сказать?
Наконец, «переиндексация всех» не всегда переиндексирует все. Благодаря различные должности в Интернете, я создал скрипт, чтобы сделать Magento думаю, что все продукты были обновлены, а индекс должен быть восстановлен: https://gist.github.com/gamort/5dc5e16bdec00a8bb3b922fc463af17c
AWS вопросы Использование AWS Elasticache Redis имеет скрытый Гоча - зона по умолчанию, в которой она запущена, может отличаться от зоны вашего сервера. В моем случае сервер находился в USEAST-1a, а Redis по умолчанию - USEAST-1b. Это привело к случайным тайм-аутам при поиске данных из кеша. Хотя код сайта обычно восстанавливается, код индексирования не работает. Это приводит к тому, что процесс индекса cron находится в неисправном состоянии.
Практически так же важно заплатить тривиальную сумму за ГБ для передачи данных из зоны 1a в 1b. Но когда ваш кеш работает, эта «тривиальная» сумма может составлять много! У нас была постоянная плата за передачу данных по внутризоновой передаче в размере $ 10 +/day [$ 500- $ 600 в месяц! Запустите новый сервер redis в своей реальной зоне, используйте redis cli на своем веб-сервере, чтобы убедиться, что вы можете подключиться [у нас были проблемы с настройкой брандмауэра], а затем ТОЛЬКО обновить вашу конфигурацию.
Сервер AWS RDS также имеет скрытый доступ [надеюсь, что вы еще не перегружены]. Миграция базы данных с другого сервера на Amazon RDS имеет проблемы, когда было крайне незначительное изменение в том, что MySQL считает допустимым SQL для определенной функции ... которую Magento EE просто использует. :-). Я закончил установку новой копии Magento EE и используя Navicat для синхронизации структур базы данных.
Solr issues Достаточно сказать, что есть проблемы Solr. В основном из-за схемы, но я также обнаружил, что очистка базы данных solr и возможность ее реиндекса помогли.
Magento Rewrite/Форма вопросы Эта проблема возникает при обновлении до 1.14.3 - что, конечно, вы должны сделать, так как он фиксирует так много вопросов индексации. Версия 1.14.3.x добавила ключи формы к нескольким формам, включая форму регистрации клиента. Поэтому, если вы создали свои собственные шаблоны phtml для входа в систему, они не будут работать! Вы должны добавить это поле ключа формы к своей настройке. Не большое дело, хотя, поскольку вы задокументировали, какой файл шаблона вы скопировали изначально?
В целом, я бы оценил переход через контрольный список для перехода на 20 часов и, возможно, до 80 в зависимости от того, с какими проблемами вы столкнулись. И в конце концов, поскольку исправления в основном выполняются заданиями cron, которые не так легко видны, владельцу веб-сайта будет сложно сказать, как они выиграли от всей этой работы. В моем случае исчезновение продуктов уже было проблемой уже более года, прежде чем мы унаследовали сайт, на котором клиент понимал трудности.
спасибо за подробный ответ. Вопрос был в пурпуровом индексаторе. Я изменил все на «Обновить по расписанию» и создал задание cron, которое запускается каждый час. который позаботился обо всех проблемах. для AWS у меня было все в одном регионе Орегона. Поскольку старые серверы также были в AWS, но новый регион мигрировал, чтобы использовать EFS с несколькими EC2 :) – Zeedia