WikiUpLib:BD Mediawiki : Différence entre versions

De WikiUpLib
Aller à : navigation, rechercher
(Sauvegarde de la BD)
 
(9 révisions intermédiaires par le même utilisateur non affichées)
Ligne 63 : Ligne 63 :
 
<br>
 
<br>
  
==Sauvegarde de la BD==
+
==Sauvegarde : Export de la BD==
  
à noter que normalement, avec l'offre PRO et au-dessus, on peut accéder à son espace ftp en SSH, ie exemple avec PUTTY. http://guides.ovh.com/UtilisationPutty
+
* à noter que, normalement, avec l'offre PRO et au-dessus, on peut accéder à son espace ftp en SSH, ie exemple avec PUTTY.  
 +
** http://guides.ovh.com/UtilisationPutty
 +
** https://forum.ovh.com/showthread.php/100985-Pas-de-connexion-SSH-avec-PUTTY-vers-ftp-cluster007-ovh-net?highlight=putty
 +
 
 +
On peut effectivement se connecter via Putty ... mais j'ai du m'y reprendre 10 fois.
 +
En effet, il faut aller très très vite pour taper le login et le mdp.
 +
 
 +
NB : 12/10/2015 La table mwi_searchindex de entrepierres est crashed, d'où refus de sauvegarder.
 +
Faut réparer d'abord.
  
 
* https://www.ovh.com/fr/g1394.exportation-bases-de-donnees
 
* https://www.ovh.com/fr/g1394.exportation-bases-de-donnees
Ligne 78 : Ligne 86 :
 
?>
 
?>
 
</pre>
 
</pre>
 +
 +
Cela fonctionne effectivement (c'est instantané, même pour une BD > 100Mo) avec opentruc et uplib.
 +
Reste à voir si on peut aussi réimporter de la même manière ?
 +
 +
mysqldump -u YourUser -p YourDatabaseName > wantedsqlfile.sql
 +
 +
 +
* Remarque 1 : Si jamais votre base est trop volumineuse, vous pouvez faire un dump* table par table en ajoutant l'option "--tables nom_de_la_table" à la fin pour avoir cette commande :
 +
<code>
 +
mysqldump --host=serveur_sql --user=nom_de_la_base --password=mot_de_passe nom_de_la_base --tables nom_de_la_table > nom_de_la_base.sql
 +
</code>
 +
 +
* Remarque 2 : Vous pouvez aussi compresser ce fichier pour mieux le télécharger sur votre ordinateur (par FTP ou par le web).
 +
Pour compresser le fichier, exécutez la commande gzip ce qui créera le fichier par l'extension .sql.gz :
 +
<code>system("gzip nom_de_la_base.sql");</code>
  
 
<br>
 
<br>
 +
 +
===Misc===
 +
* 12/10/2015, avec phpMyAdmin, entrepierres
 +
** optimize ne fonctionne pas sur la table mwi_text
 +
** défragmenter génère 0 gain
 +
 +
<br>
 +
  
 
===phpMyAdmin===
 
===phpMyAdmin===
 +
 +
* Les sauvegardes sous phpMyAdmin semblent quasi-systématiquement fantaisistes. Pour une même sauvegarde effectuée 3 fois ... il y a 3 fichiers de 1Mo, 2Mo et 2.6Mo. Sans aucun message indiquant un souci.
 +
 
* http://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki c'est bien expliqué avec phpMyAdmin
 
* http://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki c'est bien expliqué avec phpMyAdmin
  
Ligne 103 : Ligne 137 :
  
 
<br>
 
<br>
 +
 +
==Import BD ==
 +
 +
<code>mysql -u <username> -p <database name> < <dump file path> </code>
 +
 +
* https://stackoverflow.com/questions/4546778/how-can-i-import-a-database-with-mysql-from-terminal
 +
 +
<br>
 +
  
 
==Tables notables==
 
==Tables notables==

Version actuelle datée du 13 octobre 2015 à 06:26

La page de référence pour la structure d'une BD mediawiki

Concernant la taille de la table, Mediawiki ne stocke pas uniquement les dernières versions de toutes les pages, mais bien l'ensemble des changements incrémentaux de toutes les pages. ... Donc ça fait vite du volume.


Caractéristiques de la BD

10/10/2015
MediaWiki 	1.19.0
PHP 	5.4.38 (cgi-fcgi)
MySQL 	5.1.73-2+squeeze+build1+1-log

En fait, ce mediawiki a été installé via module-en-1-clic OVH, quand ça existait encore. L'install de la BD date du 15/4/2013.

Le 10/10/2015, le seul truc à peu près à jour, c'est PHP. MySQL 5.1.73 est sans doute trop vieux pour les dernières versions de phpMyAdmin (4502 et 4415).

En effet phpMyAdmin4415 me dit : phpMyAdmin - Error You should upgrade to MySQL 5.5.0 or later.

NB : La version MySQL est la même pour opentruc.fr et entrepierres.net qui sont aussi des modules-1-clic. OVH doit s'abstenir de mettre à jour le serveur pour ces vieilles BDs 1 clic, histoire de pousser les clients qui ont des BDs encore opérationnelles à les transférer dans un autre espace ... payant.

NB : Sauf erreur, les BDs module-1-clic ne sont pas accessibles/visibles/gérables depuis le manager OVH. (ça aide aussi à pousser le client où il faut).

NB : mediawiki 1.25 est compatible avec MySQL 5.0.3 or higher. Donc pas (encore) de souci de ce coté là.


Taille de la BD

10/10/2015 :

Pages de contenu	345
Pages                 1 014
Fichers importés	464
Modifications de pages depuis l’installation de WikiUpLib	12 719
Nombre moyen de modifications par page	12,54

Par ailleurs, phpMyAdmin indique 12469 lignes pour mwi_text (et 172,6Mo).
On pourrait donc subodorer que chaque ligne correspond à une modification.

12.469 lignes <-> 172.000 ko
12,469 lignes <-> 172 ko
1 ligne <-> 13,79 ko = 13790 octets = 13790 caractères = 138 lignes de 100 caractères
il s'agit d'une moyenne.

12.469 lignes <-> 5.000 ko
12,469 lignes <-> 5 ko = 5000 octets
1 ligne <-> 400 caractères


Sauvegarde : Export de la BD

On peut effectivement se connecter via Putty ... mais j'ai du m'y reprendre 10 fois. En effet, il faut aller très très vite pour taper le login et le mdp.

NB : 12/10/2015 La table mwi_searchindex de entrepierres est crashed, d'où refus de sauvegarder. Faut réparer d'abord.

En php (backupbase.php) :
Le code à renseigner et à compléter :
<?
echo "Votre base est en cours de sauvegarde.......";
system("mysqldump --host=serveur_sql --user=nom_de_la_base --password=mot_de_passe nom_de_la_base > nom_de_la_base.sql");
echo "C'est fini. Vous pouvez récupérer la base par FTP";
?>

Cela fonctionne effectivement (c'est instantané, même pour une BD > 100Mo) avec opentruc et uplib. Reste à voir si on peut aussi réimporter de la même manière ?

mysqldump -u YourUser -p YourDatabaseName > wantedsqlfile.sql


  • Remarque 1 : Si jamais votre base est trop volumineuse, vous pouvez faire un dump* table par table en ajoutant l'option "--tables nom_de_la_table" à la fin pour avoir cette commande :

mysqldump --host=serveur_sql --user=nom_de_la_base --password=mot_de_passe nom_de_la_base --tables nom_de_la_table > nom_de_la_base.sql

  • Remarque 2 : Vous pouvez aussi compresser ce fichier pour mieux le télécharger sur votre ordinateur (par FTP ou par le web).

Pour compresser le fichier, exécutez la commande gzip ce qui créera le fichier par l'extension .sql.gz : system("gzip nom_de_la_base.sql");


Misc

  • 12/10/2015, avec phpMyAdmin, entrepierres
    • optimize ne fonctionne pas sur la table mwi_text
    • défragmenter génère 0 gain



phpMyAdmin

  • Les sauvegardes sous phpMyAdmin semblent quasi-systématiquement fantaisistes. Pour une même sauvegarde effectuée 3 fois ... il y a 3 fichiers de 1Mo, 2Mo et 2.6Mo. Sans aucun message indiquant un souci.
  • Turn wiki to read only by adding $wgReadOnly = 'Site Maintenance'; to LocalSettings.php.
  • Open the browser to your phpadmin link, login, choose the wiki database. (Check LocalSettings.php if you're not sure). Select Export. Make sure all items under Export are highlighted, and make sure Structure is highlighted (it's important to maintain the table structure). Optionally check Add DROP TABLE to delete existing references when importing. Make sure Data is checked. Select zipped. Then click on GO and save the backup file.[1]
  • Remove $wgReadOnly = 'Site Maintenance'; from LocalSettings.php
  • Remember to also backup the file system components of the wiki that might be required, eg. images, logo, and extensions.


NB : c'est bien exporter qu'il faut faire.

Plusieurs formats d'export sont proposés, a priori il faut prendre SQL. J'ai essayé ODT, mais mon OpenOffice n'arrive pas à le lire (peut-être trop vieux). ... ça coûte rien d'exporter dans 2 ou 3 formats, au cas où.

A titre indicatif, pour une même BD : 8Mo SQL = 800ko ODT = 10 Mo TXT Donc ne pas se priver d'une sauvegarde au format ODT.

J'ai sauvegardé sans passer le site en readOnly ... sans que ça semble causer souci. Du moment que personne ne crée ou modifie de page à ce moment là, il ne doit pas y avoir de problème.


Import BD

mysql -u <username> -p <database name> < <dump file path>



Tables notables

  • https://www.mediawiki.org/wiki/Manual:Objectcache_table mwi_objectcache : peut être une grosse 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.



Crash Table

22/1/2014 Erreur de la base de données Une erreur de syntaxe de la requête dans la base de données est survenue. Ceci peut indiquer un bogue dans le logiciel. La dernière requête traitée par la base de données était : (Requête SQL cachée) depuis la fonction « SearchMySQL::searchInternal ». La base de données a renvoyé l’erreur « 145 : Table './XXX/mwi_searchindex' is marked as crashed and should be repaired (sqlXXX.modules) ».

... et j'ai exactement la même erreur, mais intermittente ??, pour l'import de fichier. Mêmes références de table et BD


Pistes de solutions

"is marked as crashed and should be repaired"

20/3/2009 : C'est bon j'ai finalement trouver la solution pour réparer la table par phpmyadmin j'ai sélectionné la table sur la liste des tables de la base et en bas à droite il y a un menu déroulant ou j'ai pu sélectionner réparer la table et cela refonctionne

C'est ça, et dans le cas courant, il est bon de faire des OPTIMIZE + REPAIR de toutes les tables réguliers ....

J'ai pas trouvé de "réparer la table", juste "recharger la table (FLUSH)" mais bon le message au-dessus date de 2009 (donc une version certainement plus ancienne de phpMyAdmin) et là il me dit :

  1. 1227 - Access denied; you need the RELOAD privilege for this operation

Bon, en fait c'est a priori pas ça qui aide à régler le problème, donc je laisse tomber ça.

En fait dans phpMyAdmin349, faut cliquer sur la table qui pose souci (colonne à gauche). Une fenêtre s'ouvre qui indique que en effet la table est crashée. Faut cliquer sur l'onglet SQL (3° onglet en haut) ça ouvre une fenêtre ligne de commande. Il y a, très obligeamment, déjà une commande dedans. Dans mon cas, j'ai tapé : REPAIR table `mwi_searchindex` puis cliqué sur exécuter ... et a priori c'est réparé.



Voir aussi