Вопрос

Этот вопрос какое-то время оставался для меня без ответа, и я хотел бы получить от кого-нибудь окончательный ответ о том, как это работает.

Сценарий:

Запустив Magento 1.14.2.1, я настроил все индексаторы на работу по расписанию и запускаю Magento cron, который запускается enterprise_refresh_index всякий раз, когда что-либо необходимо частично (или полностью?) проиндексировать.

До обновления до этой версии я использовал 1.13.1 и не использовал cron.У меня были включены индексаторы сохранять, и всякий раз, когда мне нужно было принудительно запустить какой-либо индексатор, я делал это либо через shell/indexer.php или используя следующий пример кода:

// Example of indexers passed in:
$indexers = ['catalog_product_flat', 'catalog_category_flat'];

foreach ($indexers as $code) {
    $process = Mage::getSingleton('index/indexer')
                   ->getProcessByCode($code)
                   ->reindexEverything();
}

Ранее...

Раньше это работало нормально с точки зрения того, что индексаторы запускались немедленно, когда я этого хочу, и чтобы различные необходимые изменения относительно быстро распространялись на интерфейс и т. д.

Очевидно, мы столкнулись с проблемами тупиковой блокировки/блокировки таблиц и конфликтом индексаторов друг с другом, когда у нас было несколько администраторов, сохраняющих продукты и т. д. одновременно, поэтому мы перешли к новой «лучшей практике» использования Magento cron для обработки всего этого. расписание.

Мои вопросы:

  1. Как заменить старый стиль принудительного переиндексирования продукта (php shell/indexer.php --reindex catalog_product_flat) с эквивалентом сейчас через запланированное задание cron?Все, что я вижу, это то, что ты можешь бежать enterprise_refresh_index задание cron, но это справляется все индексаторы верно - нет умения выделять определенные части?
  2. Имеет ли вообще смысл делать это еще раз?Под этим я имею в виду, что, выполнив предыдущую команду, Magento по-прежнему будет индексировать только то, что ему нужно, в плоской области продукта каталога, а при запуске запланированного задания он сделает то же самое, но объединит все индексаторы в один?Если это так, то ничего страшного – просто это довольно сложно понять.

Фон:

Я задал этот вопрос при поддержке Magento EE.Они вернулись, чтобы сказать, что это выходит за рамки соглашений о поддержке, но все еще получили ответ от одного из разработчиков Magento и ответили мне, сказав, что «изменения в базе данных обнаруживаются с помощью триггеров и созданы записи Changelog». Я понимаю, что отсюда запланированный индексатор решает, что необходимо сделать на основе этих записей изменений.

Раньше я предполагал, что если мне нужно переиндексировать плоские таблицы продуктов (все продукты, все), я сделаю это из командной строки, как в предыдущем примере.Как мне добиться того же самого сейчас, если он будет переиндексировать только те, которые, как он знает, должны быть сделаны через журналы изменений?Есть ли способ переиндексировать все плоских данных продукта, не перехватывая с ними все остальные индексаторы через enterprise_refresh_index?

Я не думаю, что это актуально, но мы используем модуль AOE_Scheduler, чтобы лучше понять, что делает cron.


Я знаю, что это долго.Пожалуйста, дайте мне знать, если я могу подвести итог немного лучше.Мне не удалось получить однозначный ответ, и некоторые пользователи с правами администратора не уверены, что Magento cron каждый раз эффективно переиндексирует все.Когда делается такое заявление, я обычно переиндексирую все неструктурированные данные продукта из CLI, но больше не могу этого делать, потому что это вызывает конфликты с запланированным индексатором, и начинается ад.

Это было полезно?

Решение

public function refreshIndex(Mage_Cron_Model_Schedule $schedule)
{
    /** @var $helper Enterprise_Index_Helper_Data */
    $helper = Mage::helper('enterprise_index');

    /** @var $lock Enterprise_Index_Model_Lock */
    $lock   = Enterprise_Index_Model_Lock::getInstance();

    if ($lock->setLock(self::REINDEX_FULL_LOCK)) {

        /**
         * Workaround for fatals and memory crashes: Invalidating indexers that are in progress
         * Successful lock setting is considered that no other full reindex processes are running
         */
        $this->_invalidateInProgressIndexers();

        $client = Mage::getModel('enterprise_mview/client');
        try {

            //full re-index
            $inactiveIndexes = $this->_getInactiveIndexersByPriority();
            $rebuiltIndexes = array();
            foreach ($inactiveIndexes as $inactiveIndexer) {
                $tableName  = (string)$inactiveIndexer->index_table;
                $actionName = (string)$inactiveIndexer->action_model->all;
                $client->init($tableName);
                if ($actionName) {
                    $client->execute($actionName);
                    $rebuiltIndexes[] = $tableName;
                }
            }

            //re-index by changelog
            $indexers = $helper->getIndexers(true);
            foreach ($indexers as $indexerName => $indexerData) {
                $indexTable = (string)$indexerData->index_table;
                $actionName = (string)$indexerData->action_model->changelog;
                $client->init($indexTable);
                if (isset($actionName) && !in_array($indexTable, $rebuiltIndexes)) {
                    $client->execute($actionName);
                }
            }

        } catch (Exception $e) {
            $lock->releaseLock(self::REINDEX_FULL_LOCK);
            throw $e;
        }

        $lock->releaseLock(self::REINDEX_FULL_LOCK);
    }

    return $this;
}

Это выполняется «всегда» при каждом выполнении cron.Он выполняет полную переиндексацию тех индексов, которые необходимы, и обрабатывает журнал изменений для тех, которые этого не делают.

Кроме того, вы по-прежнему можете запускать сценарии оболочки CLI, но они не будут учитывать частичный журнал изменений и будут слепо выполнять полную переиндексацию.

Если у вас возникают взаимные блокировки, возможно, вы захотите установить для всех индексаторов значение Manual и настройте альтернативные процессы для восстановления индекса в непиковое время (когда администраторы отсутствуют).Только Цены на продукцию и Статус запасов должно быть установлено значение «Обновление при сохранении».

Также имейте в виду, что при статусе частичной переиндексации в index_process таблица больше не используется, а рассчитывается по enterprise_mview_metadata.

Отключение некоторых внутренних модулей, таких как Mage_Rss также может помочь повлиять на частоту признания индексов недействительными.

Дальнейшее чтение:

Другие советы

Кстати, недавно я наткнулся на AOE_EeIndexerStats модуль от AOEpeople на GitHub — на первый взгляд кажется, что он позволит вам контролировать определенные части индексаторов или целые индексаторы, которые все описаны в разделе enterprise_refresh_index.Потенциально это может быть эквивалентом предыдущего процесса, где вы могли бы нацелиться на catalog_product_flat индекс самостоятельно.

Он также должен быть доступен в коде как таковой:

$client = Mage::getModel('enterprise_mview/client'); /* @var $client Enterprise_Mview_Model_Client */
$client->initByTableName($tablename);
$metadata = $client->getMetadata();
$metadata->setInvalidStatus();
$metadata->save();
Лицензировано под: CC-BY-SA с атрибуция
Не связан с magento.stackexchange
scroll top