Conversion d’une grosse base de donné - PHP BB2 vs PHP BB3

[Eliaqim]

A une taille environ d’un demi-million de messages. Pensez vous que je vais rencontrer des problèmes de conversion de la base de donné de phpbb2 a phpbb3. De plus sur phpbb2 nombreux sont les langues étrangère qui ont été cité dans les messages. Un demi-million serait trop gros ou pas?

[SeO]

Y'a pas de raisons que ce soit autre chose que long, vu qu'a priori le forum doit être hébergé sur un serveur suffisamment costaud.

Faut essayer. Je pense que tu peux même tenter l'aventure en ligne en première intention, de préférence sur une autre base de donnée que celle de phpBB2 pour le côté pratique. Le risque c'est le timout, phpBB2 ne sera pas affecté, à part peut être un peu ralenti pendant la conversion.

Si ça passe vraiment pas en ligne, faudra le faire en local, ça fait des imports de grosse bases en plus ...

[skieur]

Si tu a des erreurs 500 n'hésite pas à le faire en local avec wamp

[Eliaqim]

J'ai fait un test avec une petite base de donné.

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, nospam@ and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Continuer la conversion

Contexte:"Toutes les étapes de pré-conversion sont terminées. Vous pouvez commencer le processus de conversion. Notez que vous pouvez avoir à faire et ajuster plusieurs choses manuellement. Après la conversion, vérifiez particulièrement les permissions assignées, reconstruisez votre index de recherche si nécessaire, et assurez-vous que les fichiers ont été correctement copiés, par exemple, les avatars et les smileys."

Sur le serveur cela ne fonctionne pas, et en local j'ai vista donc... J’ai utilisé Easyphp sur xp voila des années. Mais je suit intriguée par le message "500" "Internal Server Error" il s’agit peut-être d’une mauvaise synchronisation entre les serveurs, j’ai aucune autres idées. Je vais faire des test avec, et installer, wampserver comme citer plus haut.

[skieur]

Je pense que c'est plus le nombre de requêtes demandés aux serveurs que la taille de la base de donnée qui compte.

A vérifier mais bof, il y d'autres choses à faire.

[gowap]

Voir http://www.phpbb-seo.com/forums/le-foru ... html#27699

[Eliaqim]

phpMyadmin
"Aucune données n'a été reçu en vue de l'importation. Aucun nom de fichier n'a été fourni, ou encore la taille du fichier a dépassé la limite permise par votre configuration de PHP. Voir FAQ 1.16"

forum.ubuntu-fr.org

Question ; vu sur le web et a propos de "FAQ 1.16":
"Je vois dans phpMyadmin/importer ceci : Taille maximum: 2 048Kio"
"Le fichier fait 4 Mo. Mais je sais pas [quoi]* je dois changer cette ligne."

Réponse:
pour modifier la taille des fichiers en upload sous PHP, il faut modifier le php.ini (situé sous /etc/php[version]/apache[version]/php.ini)

trouver la section : ; File Uploads ;
Et modifier la variable : upload_max_filesize =

Source de l'information: ici

phpmyadmin.net

Question ; 1.16 Je ne peux pas transférer de gros fichiers d'exportation (problèmes de mémoire, HTTP ou de temporisation - timeout).

Réponse :
"À partir de la version 2.7.0, le moteur d'importation a été ré-écrit et ces problèmes ne devraient plus arriver. Si possible, mettez à jour votre phpMyAdmin avec la dernière version pour tirer parti des nouvelles fonctionnalités d'importation.

Les premières choses à vérifier (ou à demander à votre fournisseur d'accès de vérifier) sont les valeurs upload_max_filesize, memory_limit et post_max_size dans le fichier de configuration php.ini.
L'ensemble de ces trois paramètres limitent la taille maximale des données qui peuvent être soumises par PHP. Un utilisateur a également dit que post_max_size et memory_limit doivent être plus grandes que upload_max_filesize.

Il existe plusieurs moyens de contournement si votre upload est trop gros ou si votre hébergeur ne souhaite pas modifier les paramètres :

Regardez la fonctionnalité $cfg['UploadDir']. Ceci permet d'uploader un fichier vers un serveur via scp, ftp ou votre méthode de transfert de fichier préférée. PhpMyAdmin est alors capable d'importer les fichiers à partir du répertoire temporaire. Plus d'onformations sont disponibles dans la section Configuration

En utilisant un utilitaire (tel que BigDump) pour découper le fichier avant de l'uploader. Nous ne gérons pas ceci ni aucune application tierce, mais nous savons que des utilisateurs ont réussi à le faire.

Si vous avez un accès au shell (ligne de commande), utilisez MySQL pour importer les fichiers directement. Vous pouvez faire ceci en utilisant la commande « source » dans MySQL : source nomfichier.sql."

Source de l'information: ici

Le nombre de requêtes demandés aux serveurs

Je pense que c'est plus le nombre de requêtes demandés aux serveurs que la taille de la base de donnée qui compte.

A vérifier mais bof, il y d'autres choses à faire.





Si tu ouvre le fichier /install/install_convert.php tu tombes sur les lignes suivantes en début de fichier (lignes 59 et plus) :


Code: Tout sélectionner

   // Batch size, can be adjusted by the conversion file
   // For big boards a value of 6000 seems to be optimal
   var $batch_size = 2000;
   // Number of rows to be inserted at once (extended insert) if supported
   // For installations having enough memory a value of 60 may be good.
   var $num_wait_rows = 20;


Cela permet de jouer sur le nombre de posts convertis en un cycle sql (2000 par défaut).
Tu peux essayer de baisser les valeurs.
Fais une recherche sur phpbb.com (ou autre) avec "batch size", je suis persuadé que ce genre de sujet a déja été abordé et cela te permettra peu etre de ne pas passer par des étapes en local.


Il n'y a aucun changement avec de plus petit nombre.

Source de l'information: ici

Cela na rien donné et je n'ai rien fait avec BigDump qui soit a première vue en anglais!

[SeO]

Laisse tomber bigdump => mysqldumper est hyper hachement mieux et plus robuste (pas encore réussi à le faire planter, testé jusqu'à 300mo de db d'un coup ).

[skieur]

Personellelment j'ai exporté la base, traité en local, séparé avec sqldumpsplit et renvoyé sur le phpbb3.

Mais je vais maintenat tester mysqldumper , encore que avec la sauvegarde de la base dans le panneau admin je ne sais pas si c'est vraiment utile.


A plus.

[Eliaqim]

Laisse tomber bigdump => mysqldumper est hyper hachement mieux et plus robuste (pas encore réussi à le faire planter, testé jusqu'à 300mo de db d'un coup ).

Je vais vous dire, bien franchement, que j’ai un fichier .sql sur mon desktop. Je n’ai pas d’idée quoi faire avec ce fichier et ou le déplacer. Je suis en local sur vista et j’utilise pour la première foi Wampserver + mysqldumper (comme proposé par Seo), d’installé dans le répertoire www/name/ de Wampserver. Donc j’ai bien sur mon desktop une base de donné d’un petit forum de 7 mo, pour usage de test phpbb2 vs phpbb3. Je veux qu’il existe sur ce serveur. Je devrais faire quoi plus en détailles. J’imagine que les étapes sont très simples.

[SeO]

Et bien, tu le fait avec mysqldumper, c'est tout l'intérêt, tu upload ta db en une fois dans mysqldumper/work/backups/

Tu sélectionnes ta db, tu choisis "restauration", puis ta db uploadé, puis le bon charset et hop, tu le laisse faire

[Eliaqim]

"tu upload ta db" dans le sens de copie coller dans "mysqldumper/work/backups/" car il existe une limite de taille de fichier "Taille maximale du fichier: 2M" "Si votre fichier Dump est plus grand que la taille mentionnée plus haut, vous devez alors télécharger vers le serveur dans le répertoire avec votre programme FTP." . Aller ont va rire un bon coup

[SeO]

Bah oui, tu upload en ftp, donc y'a pas de limites de tailles (à part la taille du HD bien sûr)

[Eliaqim]

"tu upload en ftp" Pour du local et avec mon logiciel ftp? J’ai déplacer tout bonnement ma bd dans le répertoire "mysqldumper/work/backups/" et j'ai pas vu l'utilité.

[SeO]

je me doute bien, je parlais d'upload pour la partie import en ligne, pas en local.