Magento Re- Indexing Issue

Question

I am facing one issue in Magento. I am having one Magento store with multi website functionality which containing approx 4500 products. I want to re-indexing product.

I had import 4500 product by csv through magento default functionality. after importing product the changes is not showing on front side so i went to index management and i found there are two indexes are in processing status

1 Product Attributes 2 Product Flat Data

I had already done following steps:

1 try to re-index it from admin side system->index management

2 try to do manually by calling php script

require_once 'app/Mage.php';
umask( 0 );
Mage :: app( "default" );
$process = Mage::getSingleton('index/indexer')->getProcessByCode('catalog_product_flat');
$process->reindexAll();

OR

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

Also change the var/locks folder permission to 777 and also rename that folder and also try to delete the .lock file which was created in this lock folder but not got the solution.

I am not having SSH rights. So is there any other solution which will help me to solve re-indexing problem.

Answer 1

I ran into the same issue, when creating new customer group I was unable to reindex prices.

Found the solution here http://www.magikcommerce.com/blog/how-to-resolve-magento-reindexing-errors-in-your-magento-store/

Here the procedure:

1. Locate var/locks directory and remove all files under this directory. This will clear all the locks for re-indexing to take place again.

2. Now, login to your MysQSL/phpMyAdmin to run the following MySQL query (Ensure that your have taken full backup before committing this MySQL query)

   DELETE cpop.* FROM catalog_product_option_price AS cpop INNER JOIN catalog_product_option AS cpo ON cpo.option_id = cpop.option_id WHERE cpo.type = 'checkbox' OR cpo.type = 'radio' OR cpo.type = 'drop_down';

   DELETE cpotp.* FROM catalog_product_option_type_price AS cpotp
   INNER JOIN catalog_product_option_type_value AS cpotv
   ON cpotv.option_type_id = cpotp.option_type_id
   INNER JOIN catalog_product_option AS cpo
   ON cpotv.option_id = cpo.option_id
   WHERE
   cpo.type <> 'checkbox' AND
   cpo.type <> 'radio' AND
   cpo.type <> 'drop_down';
   

3. Log back in to your Magento Admin panel and go to System tab > Index Management hit index again and you will notice no such errors will appear again. You can follow these same steps again if re-indexing stops in future to resolve Magento ReIndexing issues.

Answer 2

I was not able to reindex catalog_product_flat index process. After spending a day and trying several solutions on the Internet. i was able to fix the issue. Below is the steps.

1. Create a clone of the Magento Db which is facing the indexing issue.
2. Dump the database into the newly created db.
3. truncate the table catalog_product_flat_1 for single store and for multiple store there will be multiple table catalog_product_flat_* where * is the store id. Here truncate all that table.
4. point the mangento running instance to the newly created database and configure the databse, so that site is functioning normally.
5. Now run the command php document_root/shell/indexer.php --reindex catalog_product_flat or try reindexing from Admin. php document_root/shell/indexer.php --reindexall for reindexing all the process.

Answer 3

The errors from the indexer will be caught and not logged by default. The typical workaround is to use the CLI re-index tool; which will be very verbose with any errors.

Eg.

php shell/indexer.php --reindex ...

But given you don't have SSH access - you can either look at the indexer.php file to see how they generate the errors, or you could just launch a shell_exec or exec from a web-based PHP script that would emulate the CLI.

Answer 4

NOTE: While the below answer has, in my experience, been relevant to this type of issue, it does not appear to be the cause of the situation currently experienced by the asker

Processing means one of two things:

• The indexes may actually still be runnning, in which case, sit back and wait for them to finish. Magento indexing can take a very long time (for 4500 products, "hours" is possible, depending on the server).

• An indexer process may have died, leaving stale locks behind. Meanwhile, the dead indexer may have been run by a different user. The most common case is cron being incorrectly configured to run the indexer as root, or a normal user account, rather than as the same user as is used by the website (eg: apache or www).

All that Processing really means is "Magento failed to acquire a lock for these indexer jobs". The first case is trivial and uninteresting. Wait a couple of hours, and if the same indexers are still listed as Processing, then you may have the second case.

Check the permissions of the lock files, found under var/locks in your magento root. Are they owned by the same user as the web server is running as? If not, and you are absolutely certain that the indexes are no longer running, it is safe to delete the locks. The next step is to find out why the locks had the wrong permissions in the first place. That is a conversation which might be better had with your host, if you don't have ssh access.

Answer 5

Reason

There are references to inexisting/deleted products in catalog_product_flat_% tables.

Solution

Try to truncate ´catalog_product_flat_%´ tables (catalog_product_flat_1, catalog_product_flat_2, catalog_product_flat_3 etc.) in MySQL console or via phpMyAdmin:

mysql > truncate table ´catalog_product_flat_1´;
mysql > truncate table ´catalog_product_flat_2´;
mysql > truncate table ´catalog_product_flat_3´;

Then reindex.