Pb Taille BD : Différence entre versions

Version du 26 juillet 2014 à 17:24

Souci sur uplib, complètement coincé, alors je bosse ici.

A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script Query: REPLACE INTO `mwi_objectcache` (keyname,value,exptime) VALUES ('340976-6-mwi_:messages:fr:lock','˴2��\0','20140726151038') Function: SqlBagOStuff::set Error: 1142 INSERT command denied to user '340976-6'@'10.0.115.20' for table 'mwi_objectcache' (sql43.modules)

Simultanément, j'ai reçu un mail d'OVH :

Actuellement sur votre hébergement khi.fr, vous avez une base de données xxxxxx installée sur le serveur xxxxx

Nous vous informons que l'état opérationel de base de donnée a changé d'état et est en "SELECT ONLY". Ceci veut dire que vous pouvez continuer à faire les opérations SELECT et DELETE mais vous ne pouvez plus effectuer d'opérations INSERT ou UPDATE.

Le changement d'état est dû à la taille de votre base de données qui n'est pas conforme avec l'offre à laquelle vous avez souscrite. En effet, si votre base de donnée dépasse la taille recommandée, le serveur xxxxx ne pourra pas fonctionner de manière optimale pour l'ensemble des bases qu'il héberge.

Nous vous invitons à effectuer une purge de votre base de données afin de repasser en dessous de la taille recommandée ou de souscrire à une option via votre manager.

Nous vous remercions de votre rapide intervention. Cordialement,

La BD fait 225Mo au lieu de 200Mo autorisés. OVH a bloqué l'écriture.

• https://www.mediawiki.org/wiki/Category:MediaWiki_database_tables
• https://www.mediawiki.org/wiki/Manual:Text_table
• http://phpmyadmin.ovh.net/

Le phpMyAdmin d'ovh est plus récent que le mien propre. Et un peu plus commode.

En 1° je fais une sauvegarde de la BD. (NB : je me demande un peu comment phpMyAdmin détermine quoi sauver dans l'ensemble des tables, vu que la sauvegarde SQL fait 6Mo ... et que la base fait 200Mo)

Purge manuelle de la BD

J'essaie de trouver quoi effacer dans la BD sans tout casser. Sachant que faut quand même virer qqs Mos.

Les plus grosses tables

Table 	Action 	Lignes 	Type 	Interclassement 	Taille Décroissant 	Perte
mwi_objectcache	~17 405	InnoDB	utf8_general_ci	105,4 Mio	-
mwi_text	~4 645	InnoDB	utf8_general_ci	100,5 Mio	-
mwi_l10n_cache  ~11 617	InnoDB	utf8_general_ci	4,2 Mio	-
mwi_searchindex 495	MyISAM	latin1_swedish_ci	3,5 Mio	-
mwi_logging	~6 291	InnoDB	utf8_general_ci	3,3 Mio	-
mwi_externallinks~4 025	InnoDB	utf8_general_ci	2,5 Mio	-
mwi_revision	~6 175	InnoDB	utf8_general_ci	2,5 Mio	-
mwi_recentchanges~1 938	InnoDB	utf8_general_ci	976 Kio	-

Parmi ces tables, seules les tables xxx_cache sont indiquées comme effaçables. Et les tables suivantes font moins de 300ko. ... C'est donc pas comme si j'avais un grand choix sur quoi effacer ...

à noter que phpMyAdmin propose de "vider" les tables. C'est sans doute moins radical que de "supprimer".

l10n_cache table

The l10n_cache table. Its content can be deleted and excluded from backups as it will be regenerated when needed. LocalisationCache.php's LCStore_DB class's public function get() looks up the lc_value by the lc_lang and lc_key.

Je tente le coup sur l10n_cache table :

Vous êtes sur le point de VIDER une table au complet ! Voulez-vous vraiment exécuter «TRUNCATE mwi_l10n_cache» ?

ça marche, et la BD repasse à 218Mo (bizarre, j'aurais pensé 221Mo plutôt)

Par contre, uplib est toujours inaccessible, et le message d'erreur = panique complète.

En fait, j'ai beau avoir réduit la BD, si l'accès en écriture y est bloqué, ça continue logiquement à coincer.

Objectcache table

Objectcache table is used for a few generic cache operations if not using Memcached. Its content can be deleted and excluded from backups as it will be regenerated when needed.

Vous êtes sur le point de VIDER une table au complet ! Voulez-vous vraiment exécuter «TRUNCATE mwi_objectcache» ?

ça marche, et la BD repasse à 113.1 Mo

uplib est toujours inaccessible (mais a priori c'est hélas normal tant qu'ovh n'aura pas déverrouillé la BD), mais au moins la BD est déjà repassé sous les 200Mo autorisés, et donc a priori est éligible au déverrouillage.

Lancement update.php

Une autre idée serait de suivre le conseil d'un des messages d'erreur :

A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script

• http://uplib.fr/w/maintenance/update.php

Error 403 - Access forbidden

sans trop de surprise.

Faut lancer ça autrement.

En fait, ça marchera de toutes façons pas, puisque la BD est verrouillée.