Il existe certaines situations dans lesquelles le plugin WooCommerce est mis à jour mais la mise à jour de la base de données du plugin échoue.
Cet échec de la mise à jour de la base de données est généralement causé par le délai d'attente de PHP, en particulier sur l'environnement d'hébergement partagé, puisque PHP ne dispose que de 60 secondes pour s'exécuter via une requête Web.
La non-concordance de version entre la version de la base de données WooCommerce et celle du plugin WooCommerce peut être à l'origine de problèmes.
Mise à jour de la base WooCommerce en ligne de commande
Pour résoudre ces problèmes, nous pouvons mettre à jour la base de données WooCommerce via la ligne de commande, en utilisant wp-cli.
1. Connectez-vous au serveur en SSH.
2. Naviguez jusqu'à la racine du site via SSH et exécutez la commande de mise à jour de WooCommerce:
wp wc update
Pour une grosse base de données, cela peut prendre un certain temps. Voici le résultat que vous devriez obtenir une fois le processus de mise à jour de la base de données terminé :
wp wc update
Calling update function: wc_update_350_db_version
Success: 2 updates complete. Database version is 3.5.0
3. Vérifiez dans WooCommerce > Status que la version de la base de données correspond bien à la version du plugin WooCommerce.
Vous lisez actuellement cet article depuis le nouveau serveur de SkyMinds, baptisé ORION.
De mail à ORION
Le serveur précédent a été le théâtre d'une multitude de tutoriels consacrés à la série Monter un serveur dédié de A à Z, tournait sous Debian (6, 7, 8, et 9) mais était un peu limité en termes de ressources (Intel Core2 Quad Q8300 @ 2.50GHz, 4 Go de RAM, 750 Go de disque). Tant qu'il n'y avait qu'un seul site à gérer, cela convenait mais avec près d'une dizaine de sites, on touchait les limites.
ORION est bien plus confortable : Intel Xeon W3530 @ 2.80GHz, 32 Go de RAM, 2 To de disque en RAID). De quoi pouvoir monter en charge tranquillement :)
Du changement dans notre stack
Qui dit nouveau serveur, dit refonte de la stack. Vu que nous partons d'un environnement vierge, autant partir du bon pied et utiliser toutes les dernières innovations. Le serveur précédent datait de 2012 et, même s'il tournait parfaitement, il a connu pas mal de mises à jour (parfois pas très stables).
J'ai donc décidé de changer d'OS pour ORION : même si j'adore travailler sous Debian, je me suis dit que j'allais tenter Ubuntu Server 18.04 LTS. Certains tutoriels ne sont pas exactement équivalents entre Debian et Ubuntu Server donc cela promet quelques nouveaux tutoriels !
Objectif performance
Le but du nouveau serveur est d'être un peu plus à l'aise au niveau des ressources, surtout si les sites lancés récemment prennent de l'ampleur. Cela donne également un peu plus d'oxygène au serveur de bases de données.
L'autre objectif est un objectif de performance : monter un serveur dédié de manière simple et efficace, en privilégiant la sécurité et la rapidité des sites hébergés.
Voilà, c'est tout pour la note de service. Les tutoriels sont en cours d'écriture, donc bientôt disponibles sur le site !
J'ai récemment monté un nouveau serveur qui utilise MySQL 8 et après quelques jours d'utilisation, je me suis rendu compte que l'espace disque avait considérablement augmenté.
La cause ? Une multitude de fichiers logs binaires dans le répertoire d'exécution de MySQL 8 : il y en avait pour plus de 260 Go !
Les fichiers logs binaires enregistrent toutes les requêtes qui ont été effectuées par le serveur de bases de données. Inutile de dire qu'il est assez improbable que vous cherchiez à savoir quelles requêtes ont été lancées le mois dernier!
Désactivation des logs binaires
Sous MySQL 8, voici comment désactiver les logs binaires : éditez le fichier de configuration de MySQL:
nano /etc/mysql/mysql.conf.d/mysqld.cnf
et ajoutez cette ligne sous [mysqld] :
skip-log-bin
Vous pouvez également vous connecter au serveur MySQL en ligne de commande:
mysql -u root -p
et lancer la commande suivante dans l'invite de commande MySQL:
SET sql_log_bin = 0;
PURGE BINARY LOGS BEFORE '2019-03-31';
Relancez ensuite le serveur MySQL:
service mysql restart
Il ne vous reste plus qu'à vous rendre dans le dossier d'exécution de MySQL - /etc/mysql par défaut, sauf si vous l'avez modifié - et supprimer les fichiers binlog*.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use. To find out more, including how to control cookies, see here: Cookie Policy
