Lorsque nous installons Magento, plusieurs tables sont créées parmi celles-ci, les tables de journal de navigation.
Ce journal est différent du journal du système, que nous avons discuté ici dans le blog sous Vérifier le journal du système. La différence est que le journal de navigation enregistre le passage de vos clients et visiteurs à travers le site.
Oui. À partir du moment où vous mettez le magasin en toute l’air, toutes les pages visitées sont enregistrées dans le journal avec les informations du type de visiteur, l’identifiant d’utilisateur enregistré, l’adresse visitée, la date/heure d’accès, le type de navigateur et le système d’exploitation, ip, etc.
Et quel est le problème?
Étant donné que ce journal de navigation est continu, des problèmes peuvent se produire lorsque vous effectuez une importation de produit, mettez à jour les données dans les tableaux, parfois même un bouton arrière (back) du navigateur client. Générer une erreur d’intégrité:
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry…
C’est-à-dire, le système essaie d’enregistrer un enregistrement où les données existent déjà.
Un autre problème serait précisément la taille de votre base de données qui ne cesse de croître. Pour chaque jour (depuis le lancement), toutes les informations de navigation des utilisateurs sont stockées.
De toute évidence, cette information est importante pour enquêter sur un problème ou une tentative d’intrusion, etc. Mais une fois que vous faites une backup de cette information, cet historique peut être supprimé, réduisant ainsi le volume de données dans vos tableaux et la taille de votre prochaine backup.
Paramètres de log avancés
Pour éviter ce type de problème et même une surcharge de données, il est intéressant d’activer le calendrier de nettoyage du journal du système. Pour accéder à ceci:
Système > Configuration > AVANCÉ > Système [Nettoyage de log]
Examinons nos options de configuration:
Save Log, Days – Indique le nombre minimum de jours dans lesquels les informations doivent être stockées dans les tableaux. Toute information au-dessus de cette période n’a plus besoin d’être stockée – probablement parce que vous avez déjà effectué une backup.
Enable Log Clean – Par défaut, il est marqué “Non“, passez à “Oui” si vous souhaitez effacer les tables automatiquement.
Start time – Vous pouvez entrer une heure, une minute et une seconde. L’important ici est d’informer un temps de visite à faible débit car le processus consomme les ressources du serveur.
Astuce! Essayez de suivre les premiers processus pour trouver le temps de durée moyen – afin que vous puissiez mieux mesurer le temps de planification.
Frequency – À quelle fréquence effectuerez-vous le nettoyage. Cela peut correspondre à la fréquence de backup. Au début, vous pouvez commencer par des backup mensuelles, et avec l’augmentation du volume de données et leur importance financière, vous augmentez la fréquence pendant des semaines ou des jours.
Configuration du nettoyage du journal
Les 3 derniers (trois) champs se réfèrent à l’email d’erreur. Chaque fois qu’il y a un échec dans le nettoyage programmé des données, une alerte sera déclenchée pour le courrier électronique averti, en utilisant les références et les modèles informés sur le système.
Solution d’urgence
Parfois, l’erreur peut nous empêcher d’accéder au système. Et notre seule alternative est d’attaquer la base de données. Donc, lorsque le système a un problème avec les tables de journal qui ne peuvent être résolues par backend, nous devrions utiliser un SGBD pour exécuter la sauvegarde script:
SET FOREIGN_KEY_CHECKS=0; TRUNCATE `log_customer`; TRUNCATE `log_quote`; TRUNCATE `log_summary`; TRUNCATE `log_url`; TRUNCATE `log_url_info`; TRUNCATE `log_visitor`; TRUNCATE `log_visitor_info`; TRUNCATE `log_visitor_online`; ALTER TABLE `log_customer` AUTO_INCREMENT=1; ALTER TABLE `log_quote` AUTO_INCREMENT=1; ALTER TABLE `log_summary` AUTO_INCREMENT=1; ALTER TABLE `log_url` AUTO_INCREMENT=1; ALTER TABLE `log_url_info` AUTO_INCREMENT=1; ALTER TABLE `log_visitor` AUTO_INCREMENT=1; ALTER TABLE `log_visitor_info` AUTO_INCREMENT=1; ALTER TABLE `log_visitor_online` AUTO_INCREMENT=1; SET FOREIGN_KEY_CHECKS=1;
Fondamentalement, toutes les tables de journal sont moins log_summary_type. Nous avons utilisé la commande truncate pour zéro les enregistrements de journalisation, éliminant ainsi le problème de la clé en double.
Le script fonctionne sur toutes les versions de Magento 1.x.
Succès!
