Site internet en lecture seule à cause dépassement quota taille base de données. Blog WordPress Ovh

Publié par Dr sc Olivier Dufour le

Comment dépanner un site internet blog en lecture seule à cause d’une trop grande taille de la base de données.
Comment réduire la taille d’une base de données de site internet blog trop volumineuse.
Comment diminuer la taille d’une base de données de site internet blog trop grande.
Comment trouver les lignes inutiles d’une base de données de site internet blog trop grosse.
Quoi supprimer dans une base de données OVH WordPress trop volumineuse.

Avertissement sur la taille de votre base de données.
Votre base de données n’est plus accessible qu’en lecture seule.
Quota dépassé sur votre base de données.
Cela signifie que modifications et enregistrements ne sont plus possibles, ce qui impacte certainement vos sites et applications web.

Site internet en lecture seule à cause dépassement quota taille base de données. Blog WordPress Ovh

Requête sql calculer immédiatement la taille de votre base de données (commande PhpMyAdmin Tuto)
https://youtu.be/qEW-rmnzAn8

Sources:
https://sql.sh/900-requetes-purger-bdd-wordpress
https://github.com/ampproject/amp-wp/issues/5132
https://github.com/cabrerahector/wordpress-popular-posts/issues/190
https://stackoverflow.com/questions/10422574/can-i-remove-transients-in-the-wp-options-table-of-my-wordpress-install
https://wordpress.org/support/topic/database-is-being-spammed-very-hardly-by-amp-plugin/

Requêtes que j’ai testées:

« DELETE FROM modBDD_comments
WHERE comment_approved = ‘spam’; »

DELETE FROM modBDD_commentmeta
WHERE meta_key LIKE ‘%akismet%’

DELETE pm
FROM modBDD_postmeta pm
LEFT JOIN modBDD_posts modBDD ON modBDD.ID = pm.post_id
WHERE modBDD.ID IS NULL

DELETE FROM modBDD_comments
WHERE comment_type = ‘pingback’;

DELETE FROM modBDD_options
WHERE option_name LIKE (‘transient%_feed%’)

DELETE FROM modBDD_comments WHERE comment_type= »trackback »

DELETE FROM modBDD_posts WHERE post_status = « auto-draft »

DELETE FROM modBDD_posts WHERE post_status= »trash »

DELETE FROM modBDD_term_taxonomy WHERE taxonomy = « amp_validation_error »

DELETE FROM modBDD_postmeta WHERE meta_value =  » or meta_value is null;

DELETE FROM modBDD_postmeta WHERE meta_key = ‘_amp_stylesheets’;

DELETE FROM modBDD_postmeta WHERE meta_key = ‘_themeisle_gutenberg_block_stylesheet’;

DELETE FROM modBDD_posts WHERE post_type = ‘amp_validated_url’;

DELETE FROM modBDD_posts WHERE post_status = ‘draft’;

DELETE FROM wp_options WHERE option_name LIKE (‘%_transient_%’)

DELETE FROM modBDD_options WHERE option_name LIKE « %transient% » AND option_name LIKE « %amp% »;

Tous les épisodes de la série « Gérer son site internet blog soi-même »
https://www.youtube.com/playlist?list=PL10kBYIAXlv1WGpNJ5AeAk0KaG-TWHLgZ

L’explosion violente de la taille de votre base de données causée par une attaque pirate en force?
https://youtu.be/H0O-qlhILKM

F A C E B O O K
https://www.facebook.com/solutionstechniques/

T W I T T E R
https://twitter.com/SOLUTIONS_DIY

Olivier (Montpellier)

Je lis tous les commentaires.
Les personnes injurieuses seront bannies sans préavis.

Bonjour.
Je possède un blog wordpress hébergé sur Ovh.
Le 15 août 2020, je reçois un mail d’ovh qui me dit:
Avec cette formule, vous disposez d’une base de données dont la taille allouée est de 102400.
Vous avez atteint 80% du quota autorisé, soit 360320 de l’espace actuel.
Nous vous rappelons, qu’en cas de dépassement du quota maximal alloué, votre base de données n’est plus accessible qu’en lecture seule.
Cela signifie que modifications et enregistrements ne seront plus possibles.
Et une minute plus tard, je reçois un deuxième mail, qui m’informe que j’ai dépassé les 100%.
Je précise que je n’étais même pas connecté à mon espace wordpress, à mon blog, au moment où j’ai reçu ces 2 emails.
Vous remarquerez que même les algorithmes d’OVH ont été pris de cours.
Puisqu’ils étaient censé mettre le site en lecture seule à 100 Mégaoctets.
Et qu’ils ne l’ont fait qu’à 360 Mégaoctets.
Bon voilà. Concrètement, maintenant, quand j’essaies de me connecter comme d’habitude à mon compte WordPress pour créer des articles, entretenir mon blog, je renseigne mon identifiant et mon mot de passe. Je clique sur « Se Connecter ». ça mouline. Puis il ne se passe rien du tout. Alors que là, d’habitude, ça m’emmène vers mon espace personnel pour créer des articles et administer mon blog.
Dans un premier temps, je me suis connecté à mon blog via filezilla.
J’ai supprimé des images un peu lourdes inutiles pour voir si ça m’aidait.
ça ne sert absolument à rien.
Ce n’est pas un problème de taille des fichiers du votre blog.
C’est un problème de taille de la base de données de votre blog.
Ce sont 2 choses très différentes.
La première chose à faire, c’est de vous connecter à votre compte OVH.
Et passer par votre compte OVH pour accéder à l’outil PhpMyAdmin.
J’ai montré comment accéder à votre compte OVH et à l’outil PhpMyAdmin dans un épisode précédent.
L’épisode concerné est dans la description sous la vidéo.
Je ne vais pas remontrer la même chose une deuxième fois maintenant.
Vous aurez besoin d’un mot de passe spécifique pour vous connecter à PhpMyAdmin.
J’ai passé pas mal de temps à chercher ce mot de passe dans mes vieux emails d’ovh en vain.
J’ai donc essayé une autre méthode.
J’ai cliqué sur « changer mot de passe ».
J’ai choisi un autre mot de passe.
Au bout d’environ 3 minutes, j’ai reçu un mail d’OVH.
Dans lequel on m’informait de l’effectivité du nouveau mot de passe.
J’ai ensuite pu me connecter à PhpMyAdmin.
Première chose que j’ai faites, sauvegarder ma base de données actuelle.
Comme ça, si je fais des bêtises, ce n’est pas grave, je peux la réuploader et recommencer.
Pour sauvegarder ma base de données, j’ai dû cliquer sur « Base de données ».
Cliquer sur le nom de ma base de données.
Puis cliquer sur « Exporter ».
J’ai coché la méthode « rapide » et cliqué sur « Exécuter ».
Pour information, une fois téléchargée sur mon disque dur d’ordinateur, elle pesait environ 300 Mégaoctets.
Dans un premier temps, ne comprenant pas grand chose, je suis allé directement dans la console sql.
Et j’ai exécuté des commandes issues de recommandations de sites internets sur le sujet.
Je vous mets mets ces commandes et ces sites qui m’ont été utiles dans la description, sous la vidéo.
Il m’a fallut bien évidemment, modifier les commandes que je trouvais sur ces sites internets.
En remplaçant, notamment, les bons mots par le nom de ma base de données.
Vous pouvez aussi simuler les commandes au lieu de les exécuter directement, afin de savoir si elles sont correctes ou pertinentes.
Je vous mettrai, dans la description, quelques commandes m’ayant permises de gagner un peu de place.
Mais cette technique à l’aveugle fut assez infructueuse.
J’ai à peine réussi à passer sous la barre des 345 mégaoctets.
Dans un deuxième temps, j’ai changé mon fusil d’épaule.
Dans « Structures », j’ai cliqué sur « Taille », afin de classer les dossiers de ma base de données par ordre décroissant de taille.
J’utilise le mot dossier à tort.
Je devrais plutôt, techniquement, utiliser le mot « table ».
Mais je trouve que le mot dossier est plus clair et compréhensible.
Je vais continuer donc à utiliser le mot dossier.
Cela m’a révélé par exemple, que 2 dossiers dépassaient les 100 Mo.
Vu que 100 Mo c’est déjà plus que la taille de ma base de données totale en temps normal, cela m’indiquait clairement quels dossiers contenaient les problèmes.
Donc j’ai cliqué sur chacun de ses dossiers beaucoup trop lourds.
Et j’ai cherché les problèmes par prospection visuelle.
Il faut, en priorité, chercher les lignes qui contiennent beaucoup de caractères, mais qui ont l’air complètement inutiles. Les messages d’erreurs par exemple.
Voilà par exemple, plein de lignes remplies de message d’erreur.
Et je comprends, grâce à la colonne « taxonomy », qu’il s’agit de messages d’erreur de l’extension amp.
Donc je me suis servi des commandes précédemment évoquées, pour bricoler de quoi supprimer ses lignes inutiles et lourdes.
Cet exemple m’a permi de supprimer 3200 lignes.
J’ai ainsi libéré instantanément 50 mégaoctets.
Ensuite, j’ai trouvé d’autres lignes suspectes créées par l’extension « amp ».
Comme cette extension amp n’est pas cruciale pour le fonctionnement de mon blog, et que je savais, grâce à la commande précédente, que l’extension amp, je devrais probablement désinstaller totalement, je n’avais rien à perdre à supprimer les lignes répétitives créées par cette extension.
Même chose avec ces lignes bizarres « themeisle_gutenberg_block_stylesheet »
Même chose avec ces lignes bizarres de « post_type » « amp_validated_url ».
Et donc, j’étais à présent descendu à 114 mégaoctets.
Ensuite, j’ai carrément supprimé un dossier entier « popular_post_summary » qui pesait 9 Mo.
Je me suis permis de supprimer tout ce dossier car j’ai pleinement compris ce qu’il contenait.
Et qu’il ne contenait rien d’intéressant.
C’est un dossier qui avait enregistré les 10 articles les plus populaires de mon blog, mais dans le passé. Aucun intérêt donc.
Ensuite, j’ai trouvé ces centaines de lignes.
Elles commencent toutes par « transient ».
Déjà, de ce que j’ai compris, tout ce qui commence par « transient », on peut le supprimer sans retenue.
Et en plus, on retrouve encore l’extension « amp ».
Ce sont encore des lignes générées par l’extension amp.
Donc j’ai supprimé.
Et hop! j’étais tombé sous la barre des 100 Mo.
À ce moment là, je me suis dit, c’est bon, je peux me reconnecter à mon blog via wordpress.
Et ben non, c’est pas fini!
J’avais ce message d’erreur lorsque j’essayais de me reconnecter à mon blog via wordpress.
J’ai envoyé un mail à ovh via mon espace personnel OVH.
Ovh m’a répondu rapidement en quelques heures.
En fait, le problème maintenant est dû au fait que j’ai changé le mot de passe de ma base de données.
Je me suis connecté à mon site internet avec filezilla.
J’ai cherché le fichier wp-config.php
Il est dans le dossier www.
J’ai téléchargé ce fichier wp-config.php sur le disque dur de mon ordinateur.
Je l’ai ouvert et modifié.
Sous la ligne « MySQL database Password », j’ai remplacé l’ancien mot de passe que j’avais perdu, par le nouveau.
J’ai sauvegardé.
Et j’ai renvoyé le fichier wp-config.php sur mon site internet avec filezilla pour remplacer le vieux fichier.
Et instantanément, j’ai pû me reconnecter à mon blog sur wordpress.
Et mon site internet était de nouveau fonctionnel, alors qu’il était en panne depuis plusieurs semaine à cause de ce problème de base de données en lecture seule.
Et bien évidémment, la première chose que j’ai faites, c’est rechercher l’extension « AMP ».
Je l’ai désactivée.
Puis supprimée.
J’espère que ces informations pourront vous aider à vous sortir du pétrin.
Si vous appréciez ma démarche de partage d’information, pouvez-vous mettre un pouce vers le haut s’il vous plaît, pouvez-vous mettre un « j’aime »?
Si vous aimez les solutions aux problèmes de la vie de tous les jours, je vous invite à vous abonne à cette chaîne YouTube.
Vont s’afficher à l’écran un rond et un rectangle.
Le rond vous cliquez dessus, ça vous abonne à cette chaîne YouTube gratuitement.
Le rectangle, c’est la série de tous mes tutoriels précédents sur le sujet « entretenir soi-même son blog / site internet avec WordPress et les outils satellites ».