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 des modifications ne soient surdimensionnées et la manière de configurer les déclencheurs de table MySQL.

Description description

Environnements

Problème

Les modifications apportées à la base de données ne sont pas répercutées sur le storefront, ou l’application des mises à jour d’entités est considérablement retardée. Les entités susceptibles d'être affectées sont les produits, les catégories, les prix, les stocks, les règles de catalogue, les règles de vente et les règles de cible.

Cause

Si vos indexeurs sont configurés pour effectuer une mise à jour par planning, le problème peut être dû au fait qu'une ou plusieurs tables avec des journaux de modifications trop volumineux ou que des déclencheurs MySQL ne sont pas configurés.

Tables de logs des modifications surdimensionnées

Les tables de journaux des modifications deviennent si volumineuses si la tâche indexer_update_all_views cron n’est pas terminée avec succès à plusieurs reprises.

Les tables de logs des modifications sont les tables de la base de données dans lesquelles les modifications apportées aux entités sont suivies. Un enregistrement est stocké dans une table des logs des modifications tant que la modification n'est pas appliquée, ce qui est effectué par la tâche cron indexer_update_all_views. Une base de données Adobe Commerce contient plusieurs tables de logs des modifications. Elles sont nommées selon le modèle suivant : INDEXER_TABLE_NAME + ‘_cl’, par exemple catalog_category_product_cl, catalog_product_category_cl. Pour plus d’informations sur le suivi des modifications dans la base de données, consultez l’article Indexation aperçu > Mview dans notre documentation destinée aux développeurs et développeuses.

Déclencheurs de base de données MySQL non configurés

Il est probable que les déclencheurs de base de données ne soient pas configurés si, après l'ajout ou la modification d'une entité (produit, catégorie, règle cible, etc.), aucun enregistrement n'est ajouté à la table des logs de modifications correspondante.

Résolution resolution

Avertissement : nous vous recommandons vivement de créer une sauvegarde de la base de données avant d'effectuer toute manipulation et de les éviter pendant les périodes de chargement élevé du site.

Éviter que les tables de logs des modifications ne soient surdimensionnées

Assurez-vous que la tâche cron indexer_update_all_views est toujours terminée avec succès.

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 statut dans les journaux en recherchant les entrées indexer_update_all_views :

Réinitialiser les déclencheurs de table MySQL

Pour configurer les déclencheurs de table MySQL manquants, vous devez réinitialiser le mode indexeur :

Utilisez la commande suivante pour effectuer cette opération.

Avertissement : Avant de changer de mode d'indexeur, nous vous recommandons de placer votre site web en mode maintenance et de désactiver les tâches cron pour éviter les verrous de base de données.

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

Info : les triggers de base de données liés aux indexeurs sont ajoutés lorsque le mode d’indexeur est défini sur planifier et supprimés lorsque le mode d’indexeur est défini sur temps réel. Si les déclencheurs sont absents de votre base de données alors que les indexeurs sont définis pour la planification, définissez-les en temps réel, puis redéfinissez-les pour la planification. Cette opération réinitialise les déclencheurs.

Lecture connexe