Ошибка при индексировании в Magento

Несколько способов для решения этой проблемы:

Для начало попробуем  через консоль в ручном режиме проиндексировать базу:

down vote

First, try to set the index mode to manual: php indexer.php --mode-manual catalog_product_attribute php indexer.php --mode-manual catalog_product_price php indexer.php --mode-manual catalog_url php indexer.php --mode-manual catalog_product_flat php indexer.php --mode-manual catalog_category_flat php indexer.php --mode-manual catalog_category_product php indexer.php --mode-manual catalogsearch_fulltext php indexer.php --mode-manual cataloginventory_stock php indexer.php --mode-manual tag_summary Then, try to reindex all indexes: php indexer.php reindexall And set the mode to realtime again: php indexer.php --mode-realtime catalog_product_attribute php indexer.php --mode-realtime catalog_product_price php indexer.php --mode-realtime catalog_url php indexer.php --mode-realtime catalog_product_flat php indexer.php --mode-realtime catalog_category_flat php indexer.php --mode-realtime catalog_category_product php indexer.php --mode-realtime catalogsearch_fulltext php indexer.php --mode-realtime cataloginventory_stock php indexer.php --mode-realtime tag_summary

Вариант первый:

The Problem

After performing an upgrade to version 1.4.1.0 my index management and catalog search stopped working.
The Alert:
“One or more of the Indexes are not up to date: Catalog Search Index. Click here to go to Index Management and rebuild required indexes.”
The Error:
“Cannot initialize the indexer process”
The Screenshot:

Whats going on?

A table in MySQL has a limitation of 65535 bytes of overall row length. It may severely limit the number of columns in a table when it has varchar/char columns. In Magento starting from 1.3 the products catalog in the “flat” mode suffers from this limitation depending on the number and combination of the product attributes that participate in the flat product index. Source: SUP-MySQLLimitationsontheFlatCatalogProduct-29Jul10-0343PM-17
The workaround that stood out was setting “Used in Product Listing” = No:

Apparently, when I originally set up the store I was under the impression that this field always has to be set to Yes. Of course I want this attribute to be used in my product listing. Whats the point of creating an attribute that will not be used in the product listing, right? Well, no. This field controls if the attribute will be used in the “grid” or “list” view when showing multiple products per page. In my opinion you only need certain fields set to yes for those views, and its already preset when you set up magento for the first time. Fields like, price, special price, name and short description. Not EVERY attribute!

Solution

Take a look at the catalog_eav_attribute and eav_attribute tables. Update the used_in_product_listing field to 0 for all user defined fields that are set to 1. Before running this, use a SELECT clause and see what fields its pulling out. Also, run on a test environment first!!

update `catalog_eav_attribute` as cea left join eav_attribute as ea on cea.attribute_id = ea.attribute_id set cea.used_in_product_listing = 0 where cea.used_in_product_listing = 1 and is_user_defined = 1

…and Fixed!

With a working search…

Another solution

I was trying to find the thread where I found the original PDF to give credit to the person who led me in this direction and ended up stumbling across another solution: http://www.sonassi.com/knowledge-base/magento-knowledge-base/mysql-limitations-on-the-flat-catalogue-in-magento/. If my solution does not help, maybe Sonassis solution will.

Источник

Второй вариант:

MySQL Limitations on the Flat Catalogue in Magento

Posted on August 24, 2010 by Benjamin

We recently came across this problem with a customer who had painstakingly created every attribute possible for all his products. The result, a brilliantly user-friendly store, the downside, flat-catalogue product won’t work!
The error you are likely to see in Magento is as vague as

Can’t initialize indexer process.

A table in MySQL has a limitation of 65535 bytes of overall row length, when you present a multitude of attributes (specifically drop-down/multiple select/text/image), they are allocated a 255 character limit, as per MySQL’s varchar. In Magento starting from 1.3 the products catalog in the “flat” mode suffers from this limitation depending on the number and combination of the product attributes that participate in the flat product index.
Depending on what our client wants to do, there will likely be an extension to bypass this fault and allow some intelligence to modify the SQL statement and the resulting flat table to allow more than the ~85 text field/multiple select/image limitation.
A quick workaround (but not necessarily ideal) is to hack (read: extend) some core functions and override the declarations.
In Mage_Catalog_Model_Resource_Eav_Mysql4_Product_Flat_Indexer

01

# ~530

02	if (!$this->_isFlatTableExists($store)) {

03	$sql = "CREATE TABLE {$tableNameQuote} (n";

04	foreach ($columns as $field => $fieldProp) {

05	+      if ($fieldProp['type'] == "varchar(255)")

06	+        $fieldProp['type'] = "varchar(64)";

07	$sql .= sprintf("  %s,n",

08	$this->_sqlColunmDefinition($field, $fieldProp));

09

...

10

# ~633

11	foreach ($addIndexes as $indexName => $indexProp) {

12	$sql .= sprintf(' ADD %s,',

13	$this->_sqlIndexDefinition($indexName, $indexProp));

14

}

15	$sql = rtrim($sql, ",");

16	+  $sql = str_replace("varchar(255)","varchar(64)",$sql);

17	$this->_getWriteAdapter()->query($sql);

In the example above, I just changed the 255 to 65 globally for testing purposes, it would be a perfect solution if your attribute values are less than 64 characters, otherwise, you’ll need to be clever with the assignment of varchar length and whether to assign text/blob instead.
Read the white paper on the fault SUP-MySQLLimitationsontheFlatCatalog(Product)-29Jul10-0343PM-17

Источник

Третий вариант:

Еще один вариант заключается в использовании инструмента

Magento Database Repair Tool

1. Now run http://url-of-your-server/path-to-folder/magento-db-repair-tool-1.0.php
2. Enter access credentials to “database2” as “corrupted” database and to “database3” as “reference” database
3. Set table prefixes, if applicable
4. Press “Continue” and you will see result screen where you will see what was done to the “corrupted” database.

Explanation of the report:

1. If nothing was changed, then there is no need to fix your database
2. Only table charset was changed — usually there is no need to worry about it, especially if these tables don’t have text data
3. Table engine was changed from MyIsam to InnoDb — major issue. Needs developer for investigation
4. Added missing foreign key or field (or even a table!) — major/fatal issue. Ask a developer for help.

If you are satisfied with database repair report and need to fix your live database, you can either switch your installation to the “database2” (because it was repaired), or perform the repair directly on the live database.