WikiOpenTruc:BD Mediawiki : Différence entre versions

Version actuelle datée du 20 octobre 2015 à 09:59

Maintenance des tables

• BD en MySQL
• https://www.mediawiki.org/wiki/Category:MediaWiki_database_tables LA doc de référence
• https://www.mediawiki.org/wiki/Manual:Text_table

• http://phpmyadmin.ovh.net/

• WikiOpenTruc:PhpMyAdmin

• The l10n_cache table. Its content can be deleted and excluded from backups as it will be regenerated when needed. https://www.mediawiki.org/wiki/Manual:L10n_cache_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. https://www.mediawiki.org/wiki/Manual:Objectcache_table

• Je vais plutôt employer adminer http://www.adminer.org/

Sauvegardes

• a priori, le mieux semble être via mysqldump en ligne de commande (avec putty) ou dans un php.
• phpMyAdmin ne semble absolument pas fiable pour les sauvegardes. Jamais 2 fois la même taille ! Et phpMyAdmin a une limite de 16Mo pour l'import/export.

• https://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki

• penser à sauvegarder aussi les images, pdfs, etc

• BD, a priori, avec adminer.
• https://wordpress.org/support/topic/correct-settings-to-dumpexport-wp-database-in-adminer quasi 0 infos
• http://demoscripts.info/28432833/how-to-export-database-with-adminer.html des infos utiles
• http://renren.io/questions/1373438/how-to-export-part-of-a-table-as-sql-in-adminer
• https://www.shellandco.net/adminer-database-management-single-php-file/
• http://contrib.spip.net/Editer-votre-base-en-ligne-avec-Adminer sur l'install d'adminer

Import BD

• http://www.commentcamarche.net/contents/694-importer-et-exporter-des-donnees-sous-mysql

• https://forum.ovh.com/showthread.php/72041-je-n-arrive-pas-a-importer-ma-bdd-sql?highlight=php+putty

Fichier passé par un employé d'OVH
<?PHP
error_reporting(E_ALL); // Activer le rapport d'erreurs PHP

$db_charset = "latin1"; /* mettre utf8 ou latin1 */

$db_server         = "xxxxxx"; // Nom du serveur MySQL.  ex. mysql5-26.perso
$db_name           = "xxxxxx"; // Nom de la base de données.  ex. mabase
$db_username       = "xxxxxx"; // Nom de la base de données.  ex. mabase
$db_password       = "xxxxxx"; // Mot de passe de la base de données.

$cmd_mysql = "mysql";

$archive_SQL      = "Sauve_Base.SQL";

if (!is_file($archive_SQL))   echo "<font color=red>Le fichier <b>".$archive_SQL."</b> n'existe pas </font> <br> \n";

echo " Restauration de la base <font color=red><b>$db_name</b></font> par <b>mysql</b> depuis le fichier <b>$archive_SQL</b> <br> \n";
$commande = "$cmd_mysql --host=$db_server  --user=$db_username --password=$db_password $db_name  < $archive_SQL";
$CR_exec = system($commande); 
?> 

Upgrade uplib MW1.19->MW1.25.1

• souci à l'update. La taille de la BD semble poser problème pour sa modification.

https://www.mediawiki.org/wiki/Manual:Upgrading/fr#Web_browser

If your database is already big and in high production usage, then you should not be using the Web updater, e.g. because the update process

will time out when the maximum_execution_time is reached. In that case you should use update.php from the command-line interface (not from the web). What exactly is "too big" depends on your server (e.g. on its performance, the load and on how long the maximum execution time of PHP allows the script to run). If your wiki is too big for the web updater and your hosting provider does not allow command-line access, then you need to migrate your wiki to another hosting account, preferably to one that does have shell access.

Opentruc pesait 72Mo au total, et c'est passé. Uplib pèse ~200Mo au total, soit presque le triple. Mais ça semble ne plus passer.

Or, la plus grosse table (de loin) est mwi_text dont la structure mediawiki semble ne pas avoir subi de modification depuis la version 1.9. Donc, une idée serait de sauvegarder cette table, de l'effacer de la BD pour la ramener à une taille raisonnable. Puis de faire l'update de la structure ... et puis de réimporter la table.

Je dispose déjà de plusieurs dumps de la BD et de la table. Ainsi que d'une nouvelle BD qui réplique l'ancienne. Donc a priori, je peux toujours revenir à un état antérieur correct.

Je pense qu'il faut travailler sur la vieille BD.

Question : est-ce que d'effacer 90% de la table mwi_text aura un impact sur les autres tables ? a priori non. Mais est-ce sûr ?

Scénario 1

• ouvrir la vieille BD avec adminer
• effacer le contenu de la table mwi_text
• reprendre l'update MW1.19 -> MW1.25
• il faut que l'update se contente de réajuster la structure de la BD, et rien de plus.
• voir si l'update MW aura fonctionné
  • et merde, toujours une page blanche !

• si ça marchait, réimporter la table mwi_text sauvegardée

Vu que :

• j'ai identifié que la page blanche était provoquée par une erreur dans LocalSettings.php,
• l'import mysql semble bien fonctionner

je vais retenter ce scénario.

re-page blanche ... en fait c'est une extension, appelée, et que je n'avais pas mise dans /extension

donc, ça roule comme pour les autres wikis,

étape 3 (bienvenue sur MediaWiki!) passée

étape 4, connexion BD ok

étape 5, màj l'install existante (ie màj de la BD), màj ok

a priori, c'est fini.

Reste donc à réimporter mwi_text ... cette étape ne semble pas fonctionner. (visiblement, ça va bien trop vite versus le volume à importer).

Dans je vais reessayer avec la BD complète.

Faut relancer et faire "redémarrer l'installation"

je rearrive à l'étape 5, màj install existante, ie BD. màj OK.

a priori, c'est fini.

... mais y aura sûrement plein de détails à rerégler.

... ça semble fonctionner

les pages statistiques et version sont conformes

Scénario 2

Sous PUTTY

• usr/local/bin/php.ORIG.5_3 update.php

Scénario non réalisé, car le scénario simple a fonctionné.

Remarques

En fait, avec uplib, on se retrouve à tenter 3 upgrades en simultané :

• upgrade uplib MW1.19 -> MW1.25.1
• upgrade BD uplib MW1.19 -> MW1.25.1
• upgrade BD uplib MySQL5.1 -> MySQL5.5
• + des questions d'import/export BD pas limpides

Il faut procéder de manière ordonnée. Le 1° truc, c'est de ne faire les 1° upgrades que sous MySQL5.1, puisque cela avait fonctionné pour entrepierres et opentruc. Pour entrepierres et opentruc, après réimport dans les nouvelles BD, les nombres de pages étaient identiques aux anciens, semblant indiquer que les exports/imports s'étaient bien passés.

14/10/2015 : J'effectue un reimport du vieux contenu (BDDump_13102015C.sql/133Mo) dans la vieille BD (MySQL5.1). phpMyAdmin me dit total=210.7Mo(191.2Mo data). cela correspond aux chiffres quand ça marchait. mwi_text = 12506 lignes, 172.6Mo, cela correspond aussi aux chiffres quand ça marchait. Donc, a priori, on peut espérer ne pas avoir perdu de data.
... et cependant, uplib MW1.19.0 ne se raccorde pas avec cette BD. Page blanche ?! L'absence de messages est pénible.

Je reessaye avec BDDump_11102015.sql/132Mo (last modif=11102015 08:46) Idem, page blanche.

Bon, en fait j'ai trouvé l'erreur. J'avais laissé des instructions MW1.25.1 en fin de LocalSettings.php, wfLoadSkin( 'CologneBlue' ); etc ... et c'est ça qui plantait tout.

OUUUUF !

Je reessaye avec le dernier dump, BDDump_13102015.sql/133Mo (last modif=13102015 07:26) ... et ça marche.

Donc, excellente nouvelle, les imports/exports (direct sous mysql) fonctionnent.

• 14/10/2015 : phpMyAdmin dit que 340976-2 (opentruc) pèse 72.1Mo. Et son dump SQL pèse 72Mo. C'est cohérent
• 14/10/2015 : phpMyAdmin dit que 340976-5 (entrepierres) pèse 22.5Mo. Mais son dump SQL fait 10.4Mo. ... Mais le reimport fait bien 22.5Mo, donc ça semble ok.
• 14/10/2015 : phpMyAdmin dit que 340976-6 pèse 210.7Mo. Mais tous les dumps SQL font 130Mo maximum. ... et le reimport fait bien dans les 200Mo. Donc a priori, c'est ok.

14/10/2015 : uplib MW1.19 :

• ne tourne pas avec la BD entrepierres MW1.25.1 MySQL 5.1. a priori, ce n'est pas anormal.
• ne tourne pas avec la BD opentruc MW1.25.1 MySQL 5.1. a priori, ce n'est pas anormal.

J'avais réussi à lancer uplib raccordé sur la BD opentruc. Oui, mais quelle version uplib et quelle version BD ? 1.19 ou 1.25.1 ?

Upgrade uplib BD MySQL5.1->MySQL5.5

A priori, c'est juste un dump de la BD version 1.25.1 + import dans la nouvelle BD MySQL5.5

Effectivement, ça fonctionne. ... mais à la 1° édition, il y a un souci sur la page d'accueil, la colonne de gauche se superpose sur le contenu, et le contenu n'est affiché que partiellement ? Par contre les pages individuelles semblent ok.

• le point bizarre est que, a priori, ça ressemble à un problème de skin, donc coté soft ... mais que c'est déclenché par la connexion à la nouvelle BD sous MySQL5.5 ?

• opentruc n'exhibe pas ce souci

• la page d'accueil est incomplète aussi bien à l'affichage que coté code. Avec un début de tableau, sans le reste. Le souci provient peut-être/sans doute de là. En effet, j'ai testé en créant une page avec ce code incomplet dans la BD MySQL5.1, et ça produit le même résultat. C'est donc bien la page incomplète qui provoque le souci.
  • Question : est-ce moi qui ait merdé lors d'une édition ? ou la BD qui serait incomplète ? Je pense que je vais refaire un import (mais au préalable, je vais simplement faire un copier/coller de la page d'accueil propre).
  • l'historique indique que j'ai effectué une édition avec -18900 caractères le 15/10/2015. C'est absolument pas volontaire, donc a priori, c'est bien moi qui aurait merdé (... c'est pas la 1° fois que cela arrive).

• La désactivation des extensions ne change rien (donc a priori, ce n'est pas le souci). Et la dernière version de https://www.mediawiki.org/wiki/Extension:AddThis date de 2012. Donc pas de changement depuis que je l'ai installée en 2013.

• le fichier UPGRADE ne donne pas d'indices

• Le répertoire skins s'est considérablement allégé. On passe de 9 répertoires en 1.19 à 4 répertoires. Voir si le souci ne vient pas de là. Non, a priori, ce n'est pas ça.

Conclusion : a priori l'upgrade MySQL5.1->5.5 est un truc sans autre souci qu'un export/import correct, ie impérativement via des instructions mysql en ligne de commande.