Les modifications apportées à la base de données ne sont pas répercutées sur le storefront.
Cet article fournit des solutions pour éviter les retards ou les interruptions dans l’application des mises à jour des entités. Cela inclut la manière d’éviter que les tables de logs ne soient surdimensionnées et la configuration des déclencheurs de table MySQL.
Produits et versions concernés :
- Adobe Commerce sur l’infrastructure cloud 2.2.x, 2.3.x
- Adobe Commerce on-premise 2.2.x, 2.3.x
Problème
Les modifications que vous effectuez dans la base de données ne sont pas répercutées sur le storefront, ou l’application des mises à jour des entités est considérablement retardée. Les entités susceptibles d’être affectées sont les produits, les catégories, les prix, l’inventaire, les règles de catalogue, les règles de vente et les règles de ciblage.
Cause
Si vos indexeurs sont configurés pour une mise à jour par planning, le problème peut être dû à une ou plusieurs tables dont les logs de modification sont trop volumineux ou à des déclencheurs MySQL non configurés.
Tables de logs de modifications surdimensionnées
Les tables de journal des modifications deviennent aussi volumineuses si la tâche cron indexer_update_all_views
n’est pas terminée plusieurs fois avec succès.
Les tables de journal des modifications sont les tables de base de données dans lesquelles les modifications apportées aux entités sont suivies. Un enregistrement est stocké dans une table de journal des modifications tant que la modification n’est pas appliquée, ce qui est effectué par la tâche cron indexer_update_all_views
. Il existe plusieurs tables de journal des modifications dans une base de données Adobe Commerce. Elles sont nommées selon le modèle suivant : INDEXER_TABLE_NAME + '_cl', par exemple catalog_category_product_cl
, catalog_product_category_cl
. Vous trouverez plus d’informations sur le suivi des modifications dans la base de données dans l’article Présentation de l’indexation > Aperçu de notre documentation destinée aux développeurs.
MySQL déclencheurs de base de données non configurés
Vous pensez que les déclencheurs de base de données ne sont pas configurés si, après l’ajout ou la modification d’une entité (produit, catégorie, règle de ciblage, etc.), aucun enregistrement n’est ajouté à la table du journal des modifications correspondante.
Solution
Éviter que les tables de journal ne soient surchargées
Assurez-vous que la tâche cron indexer_update_all_views
est toujours terminée.
Vous pouvez utiliser la requête SQL suivante pour obtenir toutes les instances ayant échoué de la tâche cron indexer_update_all_views
:
select * from cron_schedule where job_code = "indexer_update_all_views" and status
<> "success" and status <> "pending";
Vous pouvez également vérifier son état dans les journaux en recherchant les entrées indexer_update_all_views
:
<install_directory>/var/log/cron.log
- pour les versions 2.3.1+ et 2.2.8+<install_directory>/var/log/system.log
- pour les versions antérieures
Réinitialiser les déclencheurs de table MySQL
Pour configurer les déclencheurs de table MySQL manquants, vous devez redéfinir le mode indexeur :
- Basculez vers "Activé à l’enregistrement".
- Revenez à "En programmation".
Utilisez la commande suivante pour effectuer cette opération.
php bin/magento indexer:set-mode {realtime|schedule} [indexerName]
Lecture connexe
- MySQL les tables sont trop volumineuses dans notre base de connaissances de support
- Indexation : Mview dans notre documentation destinée aux développeurs
- Bonnes pratiques pour la modification des tables de base de données dans le manuel de mise en oeuvre de Commerce