This has started to happen to me a few times on Enterprise and I wondering if anyone has experienced the same issue. I have noticed the "Catalog Search Index" is listed as "Processing" in the admin. I do the usual steps of removing any stray lock files in "var/locks" and it still remains.

If I look at the index_process I can see that "catalogsearch_fulltext" has the "pending" status; however, if I look at the enterprise_mview_metadata I see that "catalogsearch_fulltext_cl" as a status of "3" or "working" which I determined by logging of the mysql query that is ran when the Index Management page is displayed.

So why the disconnect between these two tables? index_process says its not running, but enterprise_mview_metadata says it is running (status 3 = working).

It's my understanding the enterprise_mview_metadata tables handles the materialized views and triggers that in are in EE. I think there might be a bug in in somewhere where if cleans the tables.

I see in "app/code/core/Enterprise/Index/Model/Cron.php" there is a function called scheduledCleanup() which has the following comments:

Clean changelog tables listed in enterprise_mview/metadata table. Cleanup would be executed in case the "index_clean_schedule" is set to "1"

Has anybody experienced this issue? Maybe something to do with a search index that is aborted prematurely and the status not getting reset in: app/code/core/Enterprise/CatalogSearch/Model/Index/Action/Fulltext/Refresh.php

Edit: Just so everyone is aware. I can manually set the search indexer back to the green "Ready" status by the following MySQL; however, what I'm trying to accomplish is to understand how the situation I encountered can occur.

UPDATE `enterprise_mview_metadata` 
SET `status` = 1 
WHERE `changelog_name` = 'catalogsearch_fulltext_cl'

Edit: I'm using SOLR for search if that helps.

2 Answers 2


With partial re-indexing status in index_process table is not used anymore but calculated from enterprise_mview_metadata.

  • Thanks. After looking at the query performed I see they are joining the two tables together on indexer code. Probably some legacy join if enterprise_mview_metadata is the only table needed. It still begs to question what could cause the "status" column in enterprise_mview_metadata to remain 3 for changelog_name "catalogsearch_fulltext_cl". My theory is somewhere I had an aborted search index due to a MySQL connection drop. Commented Aug 28, 2014 at 12:34
  • Looks like Enterprise_Mview_Model_Action_Changelog_Clear takes care of clearing that table. Commented Aug 28, 2014 at 13:03

EE 1.14 brings partial reindex support for catalog search. With that being said, partial index status isn't visible in Magento admin, in other word the process table. Update required column flashes if manual full reindex is required and status column changes to running when Magento is running full index automatically using cron. Partial reindex implemented trough mview is neither of these, so even if it's working in background, this doesn't reflect on Magento admin. Good thing in my opinion, cause it's working very often.

More about it in kb entry:


  • Thanks Marko. I'm familiar with this. I haven't actually implemented partial reindexing. I still have my indexers set to "Update on Save" and run a nightly cronjob. Initially when we were on we saw issues with deadlocks in the admin with multiple people making saves at the same time when partial indexing was turned on. Since then we haven't turned it back on. Commented Aug 28, 2014 at 12:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.