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.
Sommaire
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.
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.
Normalement rien ne change, mais La modification peut prendre quelques heures pour que tout soit opérationnel sur le nouvel hébergement.
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.
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
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.
