Améliorations #22
Sauvegarde et restauration par parties
0%
Description
Les fonctions de sauvegarde et de restauration (y compris restauration d'urgence) exécutent des scripts d'une durée parfois très longue (suivant le contenu de la base). Or un serveur PHP "standard" est généralement paramétré pour stopper les scripts au-delà de 300 secondes. Cela aboutit à un échec des fonctions de sauvegarde et de restauration. Or il n'est pas toujours possible de modifier le paramètre de durée maximum d'un script (par exemple sur un serveur mutualisé).
La seule solution de contournement actuellement connue est de réaliser un export / import de la base en dehors de l'outil PMB, directement en MySQL, ce qui n'est pas envisageable pour un utilisateur lambda de PMB.
Il serait donc intéressant de réaliser une évolution visant à mettre en oeuvre la technique d'exécution "par parties" : un script "père" exécute N fois un script "fils" qui réalise une petite partie de l'opération. Au passage, une barre de progression de l'opération pourra utilement être affichée.
Plus largement : identifier tous les scripts "longs" de PMB et leur appliquer ce traitement.
Historique
#1 Mis à jour par PMB Services il y a plus de 11 ans
- % réalisé changé de 0 à 100
Cette possibilité est déjà présente dans PMB. C'est le but des groupes de tables et des jeux de sauvegarde.
Pour éclater la sauvegarde par parties, il suffit de créer des groupes de tables. Le jeux exécute la sauvegarde des groupes les uns après les autres pour évite le timeout.
#2 Mis à jour par Anonyme il y a environ 11 ans
Bonjour,
C'est effectivement un contournement :
- pas très pratique
- qui à l'usage ne fonctionne pas avec les grandes tables d'index (par exemple notices_global_index qui prend les deux tiers de mon fichier de sauvegarde...)
Cordialement.
#3 Mis à jour par Anonyme il y a environ 11 ans
- % réalisé changé de 100 à 0
#4 Mis à jour par PMB Services il y a environ 11 ans
La demande est légitime. Mais voici quelques arguments pour tempérer l'urgence !
- Les tables notices_mots_global_index et notices_fields_global_index ne sont pas nécessaires dans la sauvegarde. Elles peuvent être reconstruites.
- Les tables qui nécessitent un temps de sauvegarde > 300s ne sont pas dans des bases pour des utilisateurs "lambda" mais souvent pour des centres qui doivent mettre en place une politique de sauvegarde fiable et automatisée car le nombre de notices est important et ils ont déjà un système informatique géré.
- D'une manière générale nous appliquons un traitement incrémentiel tant que c'est possible (imports / exports / traitement des paniers / vérification des URLs / mise à jour de la base / Nettoyage + Ré-indexation / Calcul des statistiques / Calcul des relances et j'en oublie sûrement). Il existe quand même des micro-opérations qui nécessitent un certain temps et ne sont pas réductibles à des sous tâches. S'il existe des endroits qui posent problème, je suis preneur :-)
- Au delà d'un certain volume, l'hébergement mutualisé basique n'est plus suffisant, c'est une contrainte assez générale et classique des logiciels web. Dès que les volumes augmentent, le coût du serveur devient de plus en plus négligeable par rapport au budget de la bibliothèque.
Je plaide donc pour un 50% ?
#5 Mis à jour par Anonyme il y a environ 11 ans
Bonjour,
Je maintiens le 0% sur "réalisé" par contre j'accorde bien volontiers une mention "pas très urgent" (mais je n'ai pas trouvé d'attribut "urgence" sur ce forum).
OK avec "Au delà d'un certain volume, l'hébergement mutualisé basique n'est plus suffisant", j'ai effectivement fait des tests sur des sites persos gratuits free et sfr (désolé pour eux pour la mauvaise pub) et c'est effectivement désastreux (et pas que pour la sauvegarde). Je suis actuellement chez un hébergeur a priori sérieux (OVH) auquel je paye mon hébergement et donc une qualité de services, mais je ne suis pas assez argenté pour me payer un serveur dédié. Je me contente donc d'un serveur mutualisé, qui ne me semble cependant pas si basique que ça.
Cependant, il me semble bien que les réindexations se réalisent par parties (dites-moi si je me trompe) : les développeurs de PMB (au moins ceux de cette partie-là) ont donc bien perçu la nécessité de pallier l'impossibilité de paramétrer la durée max d'un script sur un serveur...
Phil.
#6 Mis à jour par Anonyme il y a presque 10 ans
- Fichier restaure.zip restaure.zip ajouté
Bonjour,
Voici 2 fichiers réalisant la restauration par parties. Remplacent les fichiers de même nom dans le répertoire admin/sauvegarde
Utilisation : taper dans le navigateur [...]/pmb/admin/sauvegarde/restaure.php?filename=full_2013_01_05.sav&critical=1
Cela fonctionne et permet de restaurer une sauvegarde sans problème de "max_execution_time".
Il conviendrait maintenant d'appeler ce script dans le menu "admin" dédié de l'IHM, d'améliorer l'ergonomie... et éventuellement de faire l'équivalent pour la sauvegarde (qui a certes moins de soucis que la restauration).
Cordialement.
#7 Mis à jour par Eric ROBERT il y a presque 10 ans
Petite correction du départ "Or un serveur PHP "standard" est généralement paramétré pour stopper les scripts au-delà de 300 secondes." NON, le standard c'est 30 secondes pas 300.
Correction de code : pas de ";" à la fin des requêtes dans le script PHP.
Qui est le contributeur ?