Voir la source de Pb Taille BD

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)
à noter que en fait, il y a 2 options de sauvegarde : rapide (que j'utilise) et personnalisée, où on choisit les tables etc.


<br>

==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.

<pre>
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	-

</pre>

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.



<br>

==Upgrade de l'hébergement==

Etant donné le rythme de croissance d'uplib et de la fréquentation, j'opte aussi pour passer à l'offre d'hébergement supérieure : pro.

* http://guides.ovh.com/BasculerMonOffre

Normalement rien ne change, mais
<i>La modification peut prendre quelques heures pour que tout soit opérationnel sur le nouvel hébergement.</i>

J'ai eu notification du changement à 11h15.
Mais, c'est samedi et à 19h uplib est toujours inaccessible.

Si la manip de déverrouillage de la BD demande une intervention humaine, probable, ça sera planté jusqu'à lundi.


<br>

== 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.

<br>