データベースの変更は、ストアフロントには反映されません

この記事では、適用されるエンティティ更新の遅延や中断を回避するためのソリューションを提供します。 これには、変更ログテーブルのサイズが大きくなりすぎるのを防ぐ方法や、MySQL テーブルのトリガーを設定する方法が含まれます。

影響を受ける製品とバージョン：

問題

データベースで加えた変更がストアフロントに反映されないか、エンティティの更新の適用に大きな遅延があります。 影響を受ける可能性のあるエンティティには、製品、カテゴリ、価格、在庫、カタログルール、販売ルール、ターゲットルールが含まれます。

原因：

インデクサーが スケジュールに従って更新するように設定されている場合、変更ログが大きすぎる、または MySQLトリガーが設定されていない 1 つ以上のテーブルが原因で問題が発生している可能性があります。

変更ログテーブルのサイズ超過

変更ログテーブルは、indexer_update_all_views cron ジョブが複数回正常に完了されなかった場合、そのサイズが大きくなります。

変更ログテーブルは、エンティティに対する変更が追跡されるデータベーステーブルです。 変更が適用されない限り、レコードは変更ログテーブルに保存されます。変更は、indexer_update_all_views cron ジョブによって実行されます。 Adobe Commerce データベースには複数の変更ログテーブルがあり、INDEXER_TABLE_NAME + '_cl'というパターンに従って名前が付けられます（例：catalog_category_product_cl、catalog_product_category_cl）。 データベースでの変更の追跡方法について詳しくは、開発者向けドキュメントの インデックス作成の概要/Mview に関する記事を参照してください。

MySQL データベーストリガーが設定されていない

エンティティ（product、category、target rule など）を追加または変更した後で、対応する変更ログ・テーブルにレコードが追加されていない場合、データベース・トリガーが設定されていないことが疑われます。

解決策

変更ログテーブルのサイズが超過するのを防ぐ

indexer_update_all_views cron ジョブが常に正常に完了することを確認します。

次の SQL クエリを使用して、indexer_update_all_views cron ジョブで失敗したすべてのインスタンスを取得できます。

select * from cron_schedule where job_code = "indexer_update_all_views" and status
  <> "success" and status <> "pending";

または、indexer_update_all_views のエントリを検索して、ログでそのステータスを確認できます。

MySQL テーブルトリガーを再設定

不足している MySQL テーブルトリガーを設定するには、インデクサーモードを再設定する必要があります。

次のコマンドを使用して、この操作を実行します。

php bin/magento indexer:set-mode {realtime|schedule} [indexerName]

関連資料