4

I am using Magento CE 1.6.2 and I have a problem with my reindexer ( the url_rewrite )

php shell/indexer.php --reindex catalog_url
Catalog URL Rewrites index process unknown error:
exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '33432700_1343855802-0-1' for key 'UNQ_CORE_URL_REWRITE_ID_PATH_IS_SYSTEM_STORE_ID'' in /home/website/public_html/lib/Zend/Db/Statement/Pdo.php:228

When I truncate the core_url_rewrite... and hit the indexer via the backend for the first time, everything is fine, and my url rewrites are stored in the core_url_rewrites... But if I start the indexer a second time (without flushing the table), I get an error of duplicate key.

Here is a screen shot of my table: https://www.dropbox.com/s/6v9uawp5v437w3h/seo_Magewroks.png

note: UNQ_CORE_URL_REWRITE_ID_PATH_IS_SYSTEM_STORE_ID is an index key

How can I find the source of the problem?

4

6 に答える 6

5

これで問題が解決するはずです。

コアファイルをコピーします：/app/code/core/Mage/Catalog/Model/Resource/Url.php宛先：/app/code/local/Mage/Catalog/Model/Resource/Url.php

この関数を見つける：

public function saveRewriteHistory($rewriteData)
{
    $rewriteData = new Varien_Object($rewriteData);
    // check if rewrite exists with save request_path
    $rewrite = $this->getRewriteByRequestPath($rewriteData->getRequestPath(), $rewriteData->getStoreId());

    if ($rewrite === false) {
        // create permanent redirect
        $this->_getWriteAdapter()->insert($this->getMainTable(), $rewriteData->getData());
    }

    return $this;

}

次のように置き換えます。

protected $_processedRewrites = array();   // add this to your class vars on top

public function saveRewriteHistory($rewriteData)
{
    $rewriteData = new Varien_Object($rewriteData);
    // check if rewrite exists with save request_path
    $rewrite = $this->getRewriteByRequestPath($rewriteData->getRequestPath(), $rewriteData->getStoreId());
    $data = $rewriteData->getData();

    $current = $data["id_path"]."_".$data["is_system"]."_".$data["store_id"];
    if ($rewrite === false && !in_array($current, $this->_processedRewrites)) {
        $this->_processedRewrites[] = $current;
        // create permanent redirect
        $this->_getWriteAdapter()->insert($this->getMainTable(), $rewriteData->getData());
    }

    return $this;
}

問題は、関数がDBをチェックして、挿入する前にcore_url_rewritesにリライトが存在するかどうかを確認するためです。そして、これは問題ありません。ただし、次の属性でチェックを行います：request_path、is_system、store_id

私たちの問題は、いくつかの行がid_pathを複製しているが、request_pathが異なることでした...それは奇妙で、なぜそれが想定されていないのかわかりません。

ただし、この置換関数を使用すると、id_pathが以前に処理されたかどうかもチェックされ、処理された場合は挿入されません。それは問題を解決します。

しかし、それでも、問題の原因はわかりません

于 2012-08-02T19:58:58.313 に答える
3

追加の解決策:-

core_url_rewriteテーブルを切り詰めると、従来の URL キー変更の伝播レコードがすべて失われます。「 is_system 」 1としてマークされたすべてのレコードを削除すると、これらの従来の URL リダイレクトが維持されることがわかりました。クエリを使用してください:-

DELETE FROM `core_url_rewrite` WHERE `is_system` = 1;

これは、作成した URL 変更の伝播または特注のリダイレクトを維持しながら、テーブルを切り捨てるのと同じ影響があります。

アラン・ストームが説明しているように:-

is_systemプロパティは、より正確には is_canonical_rewrite_for_category_or_product_category_combo という名前になる場合があります。つまり、is_systemは、Magento によって作成されたシステム レベルの書き換えであり、現在特定のエンティティの「メイン」URL を表している行を認識するために Magento が設定するブール値フラグです (リダイレクトの書き換えとは対照的に、これもシステムによって作成されますが、is_systemフラグが false に設定されています)。アラン・ストーム - http://alanstorm.com/

さらに、破損を製品またはカテゴリ レコードのいずれかに絞り込める場合は、次を使用できます。

カテゴリのリダイレクトを維持する:-

DELETE FROM `core_url_rewrite` WHERE `is_system` = 1 AND `category_id` IS NOT NULL;

製品のリダイレクトを維持する:-

DELETE FROM `core_url_rewrite` WHERE `is_system` = 1 AND `product_id` IS NOT NULL;

全体として、is_system 1 としてマークされたすべてのレコードは、製品またはカテゴリ データから Magento によって作成されたものであり、再作成できることに注意してください。is_system 0とマークされたレコードはどこにも存在せず、単に core_url_rewrite を切り捨てると、他のサイトからの「行き止まり」のレガシー リンクが永久に失われます。

影響のあるもう 1 つの問題は、Magneto がインデックスを再作成するときに作成しようとしている URL リダイレクトの量です。次の拡張機能を使用する製品が大量にある場合は、インデックス作成時間を短縮し、core_url_rewrite テーブルのレコード数を減らすことができます:- http://www.magentocommerce.com/magento-connect/dn-d-patch- index-url-1.html

Dn'D パッチ インデックス URL 拡張機能は、個別に表示される有効な製品のレコードのみを作成するように URL インデックスを制限します。これは非常にうまく機能します。

これがいくらか役立つことを願っています！

于 2014-05-02T14:50:09.533 に答える
2

最初は機能しますが、その後の再インデックスで失敗するのは少し珍しいようです。InnoDB を使用していて、MySQL の設定が正しいことは確かですか? innodb キャッシュが十分に大きいことを確認し、MySQL 自体が何らかの種類のエラーを吐き出しているかどうかを確認します。Magento は InnoDB のトランザクション クエリを利用します。MySQL がこのような大規模なトランザクションから準備されたクエリを格納するためのメモリまたはスペースを使い果たしている場合、問題が発生する可能性があります。

テーブルが最初に構築されるときに、最初の再インデックスで重複キーがキャッチされるため、取得しているエラーは誤解を招くものです。これが単純なデータの問題 (SKU の重複やカテゴリの不適切な階層など) である場合、インデックスは最初の試行で失敗します。

アプリケーションの MySQL ユーザーが、必要に応じてテーブルをフラッシュするのに十分な権限を持っていることを確認することもできます。Magento はテーブルを壊したいと思うでしょう。それができない場合は、とにかく再構築を試み、重複キー エラーが発生する可能性があります。

tailまた、あなたのファイルを試してみてexception.log、スタック トレースを取得してここに投稿できるかどうかを確認します。また、MySQL ライブラリのデバッグ ロギングを有効にしてみてください ( 103 行目のデフォルト値を$_debugtoに変更することもできます -- また、trueに変更することもできます)。を調べて へのパスを見つけます。true/lib/Varien/Db/Adapter/Pdo/Mysql.php$_logAllQueries$_logCallStack$_debugFiletail

于 2012-08-02T17:21:47.853 に答える
1

私は、db ユーザーが適切な権限を持っていることを発見しました。コア コードがローカルに移動されるかどうかに関係なく、コア コードを変更するのは好きではありません。

このエラーは、1.4 から 1.6 へのアップグレード後にコマンド ラインでインデックスを再作成した後に発生しました。

php indexer.php -reindex catalog_url
An error occurred while saving the URL rewrite

は、ログ内の次の例外とペアになっていました:-

exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'category/360-1-6' for key 'UNQ_CORE_URL_REWRITE_ID_PATH_IS_SYSTEM_STORE_ID'' in httpdocs/lib/Zend/Db/Statement/Pdo.php:228

mysql を介して次のクエリを実行して、問題の記録を特定しました (クエリが例外にどのように関連しているかに注意してください)。これは、名前が変更されたカテゴリに関連して発生しました...

QUERY: select * from core_url_rewrite where id_path =  "category/360";

これはカテゴリ URL の書き換えであり、product_id レコードは NULL ではなく 0 であることに注意してください。これが問題であると思われます。この問題が発生している場合は、これが同じかどうかを確認してみてください。続く：

QUERY: select * from core_url_rewrite where product_id=0;

上記のクエリを実行すると、問題のあるレコードが 1 つ返されました。

私が見つけた解決策は、問題の記録を削除することでした...

現在、catalog_url reindex は問題なく動作します。

以下のクエリを実行すると、product_id が NULL の新しいレコードが返され、新しい URI パスが示されます。古い URI では、本来のリダイレクトではなく、404 が返されます。

QUERY: select * from core_url_rewrite where id_path =  "category/360";

この問題は、おそらくアップグレード後の単一のデータ レコードの問題だと思います。URL.php の変更または core_url_rewrite の切り捨てが正しいことに同意しません。

それ以来、完全な再インデックスの一環として、catalog_url のインデックスを 2 回、3 回目は再構築しました。すべて返されました: カタログ URL 書き換えインデックスが正常に再構築されました

あなたの状況はおそらく異なるかもしれませんが、これは問題を特定して修正する方法を説明するのに少し役立ちます。

于 2012-09-02T14:04:21.100 に答える
0

私たちのサイトで何が原因なのかはわかりませんが、修正は簡単でした. 古い URL の更新を気にしない場合 (製品の URL が常に現在のままである、または履歴を失うことを気にしない場合など)、core_url_rewriteテーブルを切り詰めてから、インデックスを再作成します。

于 2014-08-22T20:54:45.863 に答える