PMB 7.3.7 + restauration de base (http error 500)

Biblio_Les_Marronniers

Bonjour,

Après avoir récupéré une vieille installation (PMB 3.1) sur serveur distant (OVH), je viens de faire les mises à jour jusqu'à PMB 7.3.7 (PHP7.3). Tout s'est bien déroulé, jusqu'à ce que ma base de données dépasse les 200 MB auxquels j'avais droit (je partais de 50MB sur mon PMB 3.1).

Résultat: installation inutilisable.

J'ai donc
- commandé une nouvelle base, plus grande (je n'arrivais pas à modifier la limite de l'ancienne)
- réinstallé PMB 7.3.7 dans un autre dossier
- démarré cette nouvelle instance, lié ma nouvelle base de donnée

J'aimerais maintenant restaurer le contenu de l'ancienne base (issue de PMB 5.0.12, parfaitement à jour).
Je me suis rendu à l'adresse http://monsite/pmb/admin/sauvegarde/emergency/emergency.php, comme expliqué dans un tutoriel d'Anne-Marie Cubat, j'ai sélectionné mon fichier *.sav, attendu qu'il charge et lancé la restauration, mais je me retrouve avec ce message:

Cette page ne fonctionne pas

Impossible de traiter cette demande via http://monsite/ à l'heure actuelle.

HTTP ERROR 500

Quelqu'un a-t-il une idée de solution ?

camille.brouzes

Je propose un contournement : utiliser bigdump. https://www.ozerov.de/bigdump/

C'est un script php, dans le fichier duquel il faut préciser les paramètres de la BDD. Vous pouvez placer le fichier dans le dossier pmb par exemple, et vous placez au même endroit votre fichier de sauvegarde, en changeant juste l'extension .sav en .sql .

Vous pouvez regarder ce tuto à partir du III: https://pmbnormandie.wordpress.com/2019/05/28/installation-de-pmb-et-de-la-base-mont-saint-michel-dans-un-hebergement-en-ligne-exemple-chez-o2switch/

Puis en vous reconnectant à PMB vous faites les étapes de montée de version. En croisant les doigts.

Biblio_Les_Marronniers

Merci pour cette réponse!

Avant de la voir, je l'ai malheureusement vue trop tard: j'ai eu l'idée de passer par le gestionnaire de bases d'OVH plutôt que par PMB et venais de lancer l'importation de mon fichier SQL... C'était le 31 mars à la première heure. D'après le gestionnaire OVH, la base de donnée est encore en train d'être importée (j'obtiens une alerte "Invalid status: importing" lorsque je tente de recalculer son quota).

Comme le temps me paraissais long, j'ai malgré tout tenté cette après-midi une connexion:
PMB FONCTIONNE et se connecte à la base!
Génial!
MAIS...
...mais les caractères accentués ont été remplacés par des suites de caractères de type "é".

J'en déduis que j'ai dû me planter dans le passage du latin1 à l'utf8.
Je pensais pourtant avoir bien préparé le terrain:
- j'avais ouvert la base avec sublime text
- j'avais remplacé toutes les mentions latin1 par utf8 (charset)
- j'avais chassé réouvert le fichier avec encodage utf8
- j'avais chassé toutes les erreurs de type "é" et "&eacute", mais j'en avais trouvé bien peu...

Je ne vois pas d'où vient mon erreur, mais je me dis que si je l'exporte à nouveau, je devrais pouvoir le re-modifier et corriger ces erreurs... si OVH estime un jour que l'importation de ma base est achevée...

camille.brouzes

Arf c'est pénible ça. C'est peut être lié à l'outil d'import d'OVH ?

Biblio_Les_Marronniers

J’avais bien précisé UTF8 avant de lancer l’import, donc je suppose que ce problème-là vient de la façon dont j’ai converti ma base (j’étais étonné de ne pas avoir de corrections à faire).

Pour ce qui est de l’import qui n’en finit pas, je contacterai OVH lundi si je n’arrive pas à recalculer le quota (pour l’instant, toute tentative d’import de base, que ce soit via le gestionnaire OVH, via SQL ou via big dump est avortée...)

Biblio_Les_Marronniers

J'avais réussi à régler le problème de l'import de base, mais les recherches ne fonctionnaient plus, que ce soit dans le catalogue ou dans l'OPAC. Je suis donc reparti de mon PMB 3.1, afin de travailler sur une base saine.

L'import de la base d'origine et les update jusqu'à PMB 4.2 se sont passées sans gros problème (une dizaines de lecteurs doublons et vides à supprimer pour que Bigdump puisse finir l'import sans erreur).

Là, j'ai converti ma base en utf8 (Replace all "latin1" >> "utf8" + Save with encoding UTF-8) et je l'ai réimportée dans PMB 4.2. L'import de la base modifiée s'est passé sans difficulté et je n'ai pas  de problème apparent:

• Les accents, cédilles, etc. sont corrects. 
• Les recherches dans le catalogue et l'OPAC fonctionnent

Cependant, après réindexation et nouvelle sauvegarde de la base, j'ai voulu l'analyser pour voir si elle était réellement en utf8. J'ai 371 occurences pour "latin1" et 45 pour utf8.

Est-ce normal???

camille.brouzes

Mmhh. quand tu dis avoir importé la deuxième dois, tu as utilisé quoi ? L'outil import de PMB ?

Je me demande...je crois ma rappeler d'un truc qui nous avait amené à utiliser bigdump, et notamment que l'outil import rebasculer des trucs en latin-1...

Mais je me trompe peut être. Perso, j'ai utilisé PHPmyadmin pour basculer toutes mes tables en UTF-8. dans les dernières versions, il me semble que tu peux le faire pour la base entière, mais à un moment je l'ai fait table par table. Je te conseille de le faire. Si dans PHPmyadmin, toutes les tables sont en interclassement utf-8, ça devrait être bon.

Biblio_Les_Marronniers

J'ai utilisé Bigdump pour l'import, mais je pense avoir compris mon erreur: j'ai réinséré la base en gardant mon dossier d'installation qui avait suivi l'évolution PMB3.1>3.4>4.2.

Ce matin, j'ai donc créé une nouvelle base et un nouveau dossier, inséré la base avec Bigdump et réinstallé un PMB "neuf" à l'aide du script d'installation (tables/install.php). La tendance s'est inversée: j'obtiens environ 500 occurrences pour utf8 et 50 pour latin1 avec PMB5.0.12... qui fonctionne parfaitement!

Comme j'ai eu une alerte lors de la mise à jour de la base lors du passage à PMB5, je suis en train de faire une copie complète de mon dossier d'installation PMB5 avant de passer à PMB7... 

Voici les erreurs en question:

• alter table scan_request_status workflow add primary key >> Error may be fatal: Multiple primary key detected
• alter table tu_oeuvres_links add primary key >> Error may be fatal: Multiple primary key detected

Je vais donc me renseigner sur ces tables et leur utilité...

cedgoo

Bonjour,

pour des tables en latin1 et en utf8 après une mise jour, le problème vient de l'interclassement général de la base : toutes les tables peuvent être en utf8, si l'interclassement de la base est resté en latin1, les nouvelles tables créées avec la mise à jour le seront en latin1 (je me suis moi-même fait avoir bêtement avec une mise à jour d'une base MSM).